Relevance score

Permissions: update_product

In the Relevance score section of the tenant settings of a product, you can configure parameters used to score and rank the solutions of a ride request. This includes possible internal DRT offers as well as external public transport (PT) solutions. The relevance score is always calculated and is not tied to a feature flag.

Although it’s computed similarly to the matching score, the relevance score is completely independent of it.

Relevance scoring follows a penalty system. Since the weights are positive, lower-quality solutions result in higher scores. This is because longer waiting and travel times are multiplied by these positive weights and then summed up, penalizing less desirable solutions.

Both internal DRT and external PT solutions are scored using the same metrics:

  • Waiting time weight. Weight applied to the delay, in seconds, from the request to the solution. Default 1.0.
  • Walking time weight. Weight applied to the walking time, in seconds. Default 2.0.
  • Travel time weight. Weight applied to the non-walking travel time, in seconds. Default 1.0.
  • Overall time weight. Weight applied to the sum of walking and travel time. Default 0.0. Usually left at 0 to avoid double-counting walking and travel time.
  • Asset change weight. Weight applied to the number of transportation mode changes (excluding walks), always 0 for DRT solutions. Default 120.0. This high value discourages mode changes and intermodal solutions.
  • DRT offset. Scoring adjustment added to the final score of DRT solutions (drt_score). Default 0.0.
  • PT offset. Scoring adjustment added to the final score of PT solutions (pt_score). Default 0.0.

Each of these factors contributes to the solution’s overall relevance. The scores are then calculated as follows:

pt_score = (waiting_time_weight × waiting_time) + (walking_time_weight × walking_time) + (travel_time_weight × travel_time) + (overall_time_weight × overall_time) + (asset_change_weight × asset_change) + pt_offset

and

drt_score = (waiting_time_weight × waiting_time) + (walking_time_weight × walking_time) + (travel_time_weight × travel_time) + (overall_time_weight × overall_time) + (asset_change_weight × asset_change) + drt_offset

For arrival-based matching, waiting_time is defined as the difference between the arrival time of the solution and the arrival time requested by the passenger.

Each weighted term is rounded to the nearest whole number before the terms are added together with the offset. The offset itself is added without rounding.

Using the default weights, compare a direct DRT solution with a public transport solution that includes one mode change.

DRT solution—waiting 300 s, walking 60 s, travel 600 s, no mode change: (1.0 × 300) + (2.0 × 60) + (1.0 × 600) + (0.0 × 960) + (120.0 × 0) + 0.0 = 1020

PT solution—waiting 120 s, walking 180 s, travel 900 s, one mode change: (1.0 × 120) + (2.0 × 180) + (1.0 × 900) + (0.0 × 1080) + (120.0 × 1) + 0.0 = 1500

The DRT solution has the lower score, so it is ranked first. The mode change adds a fixed penalty of 120 to the public transport solution.

Multiple booking solutions

The relevance score plays a key role in the multiple booking solutions feature, where solutions can be sorted based on their relevance. The relevance score is used to rank solutions whenever an ordering setting is set to Relevance—this applies to the per-type orders (Order of DRT Solutions, Order of Intermodal Solutions, Order of PT Solutions) and to the Order of final solution list. Each stage that is set to Relevance orders its solutions by ascending relevance score, so the lowest-scoring (best) solutions come first.