Introduction
Visibility Hub provides tracking data updates for specific transports by managing when, where, and to what extent this information is visible to various stakeholders such as shippers and carriers.
As per this standard, vehicle tracking data - such as GPS positions or stop arrival/departure events sent from an inhouse system - are considered in general between the first and the last stop of a transport:
Tracking start time
Transporeon Visibility begins tracking a transport before the vehicle reaches its first stop, providing an ETA (estimated time of arrival) from the beginning of the journey.
The tracking start time marks the beginning of the tracking period. It is calculated dynamically by adding a buffer before the first stop's timeslot. This buffer typically ranges from one to several hours, depending on the distance between the first and last stops.
ℹ️ This is done because we need to know when to consider the GPS pings (which are often available continuously, even 24/7) for the transport to which the vehicle is allocated.
The system generally uses provisioned tracking data (typically GPS pings from vehicles connected to Transporeon Visibility) for a transport from this calculated start time until the tracking ends.
However, there are special cases for tracking data from external sources (such as interface connections from an in-house system):
Events: These include stop arrival/departure events or external ETAs. The system uses these events up to several working days before the tracking start time.
GPS data: When posted directly to a transport, this data is used immediately upon receipt, bypassing the tracking start time.
ℹ️ If the first stop's timeslot lacks accuracy and the actual arrival occurs before the tracking start time, Transporeon Visibility can still capture the stop visit. It does this by scanning potential previous days' stop visits. This logic is applied with a buffer period after the first stop's timeslot ends.
The calculated start time can be overridden during vehicle allocation. For details have a look here.
Tracking end time
The tracking end time depends on whether all stops of the transports got tracked or not:
All stops tracked
When all stops of a transport are tracked, the tracking concludes at the last stop. How this ending is triggered depends on whether the system detects the vehicle's departure from the final stop:
Departure detected: Tracking ends when the vehicle departs the last stop—specifically, when it exits the last stop's geofence (see here for more details about geofencing in Transporeon Visibility)
Departure not detected: Tracking ends after a buffer period that the system adds while waiting for a potential departure.
Some stops remain untracked
Sometimes tracking isn't perfect and certain stops can't be tracked:
Issues with GPS data submission or unallocated additional vehicles involved in transport can prevent Visibility Hub from tracking the last stop.
To address these situations and avoid incorrectly showing transports as "currently being tracked" when "delivery has already occurred," Visibility Hub automatically ends tracking after the latest timeslot ends, plus a buffer period.
The "tracking end time" buffer is dynamically calculated for each transport based on various factors including transport distance, timeslots, weekends, and the type of tracking data received. This buffer typically ranges from one to several working days.
Our aim is to continue tracking a transport as long as it's likely to receive updates—such as during severe delays—while ending tracking afterward to accurately reflect the actual execution state.
You can learn more about the different transport states and premature tracking end cancellation reasons in this article.