Custom trip logic in Navixy: configure rules for each fleet

Configure Navixy’s standard trip parameters to match how a specific fleet operates, without building a separate data pipeline. Read the full story to learn how to adjust trip rules, validate the result, version the logic, and reuse it across customer implementations.

Most telematics software give you a ready-made trip entity. The platform decides when movement starts, how long a stop can last, when one trip becomes two, and which movements are too short to count. For a standard road fleet, those defaults usually work well enough. The challenge appears when a fleet operates differently.

• Construction equipment may move only 50 meters between work areas.
• A courier route may include several six-minute stops that should still belong to one delivery run.
• Another customer may care much more about moving from Warehouse A to Customer B than about the exact coordinates where the trip started and ended.

This is where configurable trip logic becomes useful. With Navixy's analytics platform IoT Query, TSPs and system integrators can take the existing trip transformation and adapt how raw telemetry is aggregated into trips. The workflow can be maintained as YAML, versioned, reused across implementations, and adjusted without rebuilding a separate data pipeline for every customer.

To demonstrate the workflow in a clearer and more transparent way, we use Transformation Builder, a visual tool for designing data transformation workflows. It helps you see how each step connects to the next, where specific rules are applied, and how the resulting trip data is produced.

How Navixy turns raw telemetry into custom trips

A GPS tracker sends coordinates, speed, timestamps, device states, and other telemetry. A trip appears only after the platform applies a set of rules to that. This distinction matters because those rules are exactly where customization happens.

In simplified form:

Raw telemetry → Movement detection → Trip boundaries → Trip validation → Business context

IoT Query starts with telemetry in the Raw data layer. The standard Trips transformation then turns those points into structured trip records with boundaries, duration, distance, and other calculated metrics. The standard transformation therefore needs a set of default rules.

For example, it uses a five-minute parking threshold, a 20-minute data-gap timeout, and minimum speed and distance criteria to help distinguish actual movement from GPS noise. These are reasonable assumptions for many fleets, but they are not universal.

If the customer's operational definition of a trip differs, you can keep the existing transformation and change only the logic that no longer fits. The resulting model is still straightforward:

Raw telemetry → Сonfigurable transformation logic → Сustom analytical dataset

The modified workflow can write the result to processed_custom_data, while the standard Navixy transformation continues running separately.

This also makes testing safer: you do not have to replace the standard trip dataset just to validate another definition.

Three use cases for custom trip logic in Navixy via IoT Query

The easiest way to see where custom trip logic becomes useful is to look at operations where standard road-fleet assumptions no longer hold.

Use case: Detect short 50 meters heavy-equipment trips

Construction fleet and heavy machinery is a good example because the limitations of standard road-fleet assumptions become visible quickly. Imagine equipment moving around a construction site. A loader may relocate 50–80 meters between work areas at low speed.

A standard trip filter can reasonably treat that as GPS noise. For this operation, however, it is a real movement the customer may want to analyze. Simply lowering the final distance threshold is not enough. The underlying points first need to be classified as movement.

For example, the Moving Status logic can be adjusted from a 3 km/h threshold to 1 km/h and allow shorter distance changes:

version: 2
name: Generate Trips (no zones)

cte_nodes:
  - id: custom_5
    type: custom
    label: Moving Status
    sources: [filter_1]
    params:
      custom_sql: |-
        SELECT *,
          CASE
            WHEN speed >= 1
              AND (distance_meters > 10 OR is_moving = 1)
              THEN 'moving'
            ELSE 'stopped'
          END AS moving_status
        FROM filter_1

This is an excerpt from the workflow rather than a complete configuration, but it shows the basic idea: trip behavior is controlled through readable configuration and SQL logic.

The final validation criteria should then follow the same definition:

HAVING COUNT(*) >= 2
   AND MAX(w.speed) >= 1
   AND ROUND(ST_Length(...)) >= 30

Here, the minimum speed moves from 3 km/h to 1 km/h, while the minimum trip distance - from 100 meters to 30. The incoming telemetry has not changed, interpretation of it has.

There is an important trade-off, though: once movement thresholds are lowered, GPS drift has a better chance of being classified as a real trip. Before scheduling the workflow in production, compare the results against a set of known equipment movements. In practice, that validation is more useful than trying to find a theoretically “correct” threshold.

Use case: Keep courier stops within one trip

Courier operations create a different challenge. A delivery route may include dozens of short stops. If one delivery takes six minutes instead of four, a seven-minute parking threshold can split what the business considers one route into two trips. In this case, there is no reason to redesign the workflow.

Increasing the parking threshold from 300 to 600 seconds may be enough to keep these stops within the same trip. If connectivity gaps are also fragmenting the route, the data-gap threshold can be adjusted in the same way.

A useful rule here is to start with the existing workflow and change the smallest number of assumptions possible. That makes the result easier to validate and maintain. It also makes the configuration much easier to explain later when someone asks why trips for this customer behave differently from the standard model.

Use case: Add business context to trips

Thresholds are only one type of customization. Coordinates themselves are rarely what a dispatcher, analyst, or customer ultimately wants to see.

A record such as: 55.7558, 37.6173 → 55.7412, 37.6231 is precise, but the operational question is more likely to be: Did the truck go from the warehouse to the customer site?

A custom workflow can match trip start and end coordinates against geofences in processed_common_data.zones_geom and add fields such as:

Field	Meaning
start_zone	Geofence containing the trip start
end_zone	Geofence containing the trip end

The resulting trip can now say: Warehouse → Customer site without requiring another BI tool or application to rebuild that context later.

At this point, the workflow is doing more than tuning trip detection. It is shaping the analytical entity around how the customer's operation actually works.

That same approach can be extended with driver information, sensor states, operational zones, or other business data available to the implementation.

Why manage custom trip workflows as YAML

The visual graph is useful when you want to understand the workflow. YAML becomes useful when there is a need to manage that workflow as an engineering asset.

Every transformation workflow can be exported as YAML. The configuration describes the nodes, parameters, connections, and schedule behind the transformation. For teams building similar solutions repeatedly, this provides four practical advantages:

1. Version the logic. Instead of somebody changing 300 to 600 in a UI and nobody remembering why three months later, the YAML can live in Git. The change becomes a normal diff with history and review.
2. Reuse a validated implementation. If you have already built trip logic for one type of construction fleet, you have a much stronger starting point for the next customer with similar operations.
3. Move workflows between implementations. The same configuration can be imported into another Navixy account instead of being reconstructed node by node.
4. Work with the configuration programmatically. Because the workflow is structured text, scripts and AI tools can inspect and modify it directly. This option is becoming particularly useful for system integrators.

How AI tools can work with YAML trip configurations

Once the transformation exists as structured text, using AI becomes much more straightforward. Instead of trying to explain a visual workflow to an assistant, you can give it the exported YAML and a concrete operational requirement.

For example:
Here is our current Trips workflow. This customer operates construction equipment that regularly moves 30–80 meters at 1–2 km/h. Which nodes and thresholds are currently preventing those movements from being classified as trips?

An AI assistant can identify the relevant nodes and suggest changes.

A workflow generator can go further and return an updated YAML file.

An autonomous agent could potentially handle more of the loop: read the configuration, modify it, execute the workflow, and compare the output against a known set of trips.

There is one important limitation. The YAML explains how the workflow works. It does not explain how the customer's operation works. Before asking an AI tool to modify trip logic, give it the operational context it needs.

Without that context, an AI tool can produce perfectly valid YAML that still encodes the wrong business logic.

That is why AI is most useful here as a way to accelerate configuration work, not as a substitute for understanding the fleet operation.

For a more technical walkthrough of these use cases, including the exact nodes and parameters involved, validation risks, scheduling considerations, YAML editing patterns, and recommendations for AI assistants and agents, see Data Analysts → Use Cases in Navixy Documentation.

How to reuse custom trip logic across customers

For a TSP or system integrator, custom trip logic becomes especially valuable when different customers operate under very different conditions. The underlying telematics data can be the same, meanwhile, analytical definition does not have to be. You also do not need to rebuild the analytics stack for every implementation.

Start with an existing transformation. Change the assumptions that matter. Validate the output against real fleet behavior. Keep the resulting YAML under version control. Reuse it when the next implementation has a similar requirement.

Trips are a convenient example, but the same principle applies to sensor aggregations, driver events, vehicle metrics, and other analytical entities. The broader opportunity is to control how raw telematics data becomes data your customer's operation can actually use.

Have a customer use case that does not fit the standard trip logic? Contact us to discuss how you can build and maintain a custom transformation in IoT Query.