Matching

Roles: Super Admin

In the Matching section in the management settings of a product, you can configure core matching behavior.

Matching algorithm

This setting determines which matching algorithm the product uses.

Default matching

Use Default matching to run the standard matching algorithm. This option supports both address-based and station-based matching.

No matching

Use No matching if the product should never return a matching result. If this option is selected, ioki Platform always cancels the ride with the reason No vehicle available.

Planning list builder strategy

This setting controls how ioki Platform generates candidate planning lists during detached matching.

The following options are available.

Exhaustive fingerprint builder

This strategy generates the full set of candidate planning lists in one batch at the beginning of the matching process.

Use this option when you want matching to consider the whole search space immediately.

Time progressive chunk builder

This strategy generates candidate seeds once and then exposes them in time-oriented batches. Planning lists that are closer to the requested time are evaluated earlier, while candidates that are further away are deferred to later rounds.

This can reduce unnecessary work and improve performance because matching can stop once a sufficiently good solution has been found in an earlier batch.

For more detail on how this strategy interacts with matching rounds and passenger-facing offers, see Extended search space.

Control Center also contains a testing-only option called Chunk Builder (ONLY FOR TESTING). This option exists for internal testing and is not intended as a regular production setting.

Planning model overrides adapter

This setting lets ioki Platform apply custom adjustments to the internal planning models before matching evaluates candidate solutions.

The selected adapter is loaded at the start of a matching run. It can adjust the planning data that matching uses for the ride, product, matching configurations, vehicles, and public transport alternatives.

Use this setting when a product needs matching behavior that cannot be expressed with the standard matching settings alone.

For example, a custom adapter can:

  • adjust scoring inputs such as walking penalties
  • apply different matching behavior for certain user groups
  • prepare planning data differently before scoring starts

If None is selected, no custom planning model overrides are applied.

If needed, custom planning model overrides adapters can be developed for specific business requirements and then made available in Control Center.

An adapter could check eligibility group membership and increases the walking penalty for members of a specific group. This makes solutions with passenger walking time score worse for those users.

Requires fixed stations for pickup/dropoff

With this setting, matching can be restricted to fixed stations for pickup, dropoff, or both.

If on-demand solutions are used as feeders for suburban trains, train stations can be set as fixed stations for matching. Passengers can then book rides to and from these train stations, with the other end of the journey chosen freely.

Driver blacklisting enabled

If an offered ride is actively rejected by a driver, the same vehicle planning is blacklisted for five minutes, allowing the passenger to receive other offers. If the driver-related settings option Driver client automatically accepts ride requests is activated, drivers cannot actively reject rides.

Driver blacklisting enabled can be considered a safeguard. For example, a user is matched with Driver 1, and Driver 1 actively rejects the request because they are preoccupied or otherwise do not want to accept it. If a new ride request is created and the system matches the same user again with Driver 1, the chance of another rejection is high. To prevent this, the system remembers driver rejections and avoids matching users with the same driver for a period of time.

Reverse-geocoding enabled

Geocoding maps an address to latitude and longitude coordinates. Reverse geocoding does the opposite by deriving an address from coordinates. If this option is enabled, the request sent by ioki Passenger App is checked again for the address via the chosen routing adapter, even though the address is already included in the app request. In the past, this helped when the address was formatted in a different language. These problems are now mostly solved by the passenger clients. Note that the initial idea behind this option was a different feature that has not yet been released: sometimes the closest possible pickup point for an address does not correspond to the requested address. In that scenario, this feature would have been used to update the address for driver routing.

This feature should be enabled only in exceptional circumstances because of its side effect: occasionally, the potential pick-up or drop-off point for an address may not align with the requested address. For instance, the requested address might be “Alte Welle 1”, but reverse geocoding may return “Alte Welle 8” instead.

Reverse-geocoding works only with the routing provider HERE.

Ignore vehicles without current position in matching

If this setting is enabled, the Task List Finder ignores vehicle plannings if the last known vehicle position for the corresponding vehicle is older than ten minutes.

This filter is applied if all of the following are true:

  • this setting is enabled
  • the ride is ad hoc (not prebooked)
  • the task list is active

Concurrent negotiations per vehicle enabled

If this setting is on, simultaneous ride requests to the same task list are enabled (in the Task List Finder). If this setting is off, simultaneous ride requests to the same task list are blocked. This means that only one passenger at a time can see a distinct vehicle, and a new negotiation can only begin if that passenger cancels.

Filter overlapping rides

Prevents a passenger from booking rides that overlap in time with other rides already booked by the same user. At the end of the matching algorithm, each candidate solution is checked to ensure that its calculated pickup time and calculated drop-off time do not overlap with the calculated times of existing rides. This check does not account for negotiation times, meaning overlaps may still occur if the journey is recalculated later. To mitigate this risk, ioki Platform applies an additional 10-minute buffer to the calculated times.

This only filters rides that really overlap in time. It does not do anything like a sanity check for, for example, preceding rides. If a user books Ride 1 which ends at 2:00pm, and Ride 2 which starts at 2:01pm but starts 20km away—which obviously cannot work out—this is not filtered. Furthermore, this is a post matching filter, meaning it’s applied after the matching algorithm. This has consequences: If a user has already booked a ride that is planned to end at 2:00pm, it might still be possible to request a ride that starts 1:30pm. Since the algorithm generates multiple internal solutions, there might be solutions which deviate 45 minutes. So the filter may filter all variants that collide and still give results that suggest the user to start 2:15pm.

Preprocess ride requests with snapping stations

Maps the requested point always to a station (in the initialization of the ride, that is, before or during matching) if the requested point is within the station’s predefined catchment area. This is only a behavioral setting, not a feature flag. Snapping before matching starts has the effect that, for example, blacklisted travel combinations or unserved areas might be ignored, as the matching algorithm considers that the request comes from a station.

Preprocess ride requests with snapping user locations

When this setting is enabled, ioki Platform checks the requested origin and destination during ride creation and links each point to the nearest saved user location of the same user if it is within 25 m.

Unlike station snapping, this setting does not replace the requested coordinates or address. It only stores the related user location so later rules can use it.

If Preprocess ride requests with snapping stations is also enabled and a requested point is snapped to a station first, no user location is linked for that point.

This is mainly relevant for:

If more than one saved user location is within 25 m, the nearest one is linked.

The linked user location does not need to be validated. Validation matters only for the downstream rules that explicitly check for validated user locations.