Table of contents
Intro
If tracking can't be completed, Visibility Hub provides an indication of what might have gone wrong. We have grouped similar and most common issues into so called Tracking Cancelled reasons, that are in focus on this page.
This article
lists all of the Tracking Cancelled reasons
describes how Visibility Hub ended up with a specific reason and
provides recommendations on what you can do to make tracking successful going forward.
Transport state transition
The following flowchart shows the different actions that trigger a transport state transition as well as which Tracking Cancelled reason is potentially applied [click to enlarge].
In certain situations, a transport can already be in Cancelled state when Visibility Hub receives
Vehicle allocation
Arrival/departure and similar events via an interface connection
GPS data from the allocated vehicle or from an interface connection
Transport update (e.g. time slots were updated or a stop got added/modified)
In this case, Visibility Hub changes the transport state back to Tracking/Completed respectively.
Tracking Cancelled reasons
List of all tracking cancelled reasons:
Click one the tracking cancelled reason to jump to the description.
No vehicle/tracking data received
Visibility Hub didn't receive any vehicle information or tracking data in order to initiate the tracking. Such a transport will stay in Untracked state until it's moved into Cancelled state.
Depending on how the carrier chose to provide visibility (for more details on that, have a look at the connection options here), different actions need to be taken to resolve the situation:
Telematics integration of carrier's own vehicles: Vehicle(s) that is (are) executing the transport need to be allocated. Provided that the vehicle's telematics data is being transmitted successfully, the situation should be resolved.
Telematics integration of subcarrier vehicles: Similar to (1) above, either the carrier or the subcarrier owning the vehicle needs to allocate the vehicle to get the tracking initiated.
Inhouse system connection of the carrier: Visibility data (like GPS pings or arrival/departure - and similar - events) need to be sent via the interface this carrier has set up between their inhouse system and Visibility Hub.
If you're a shipper and you don't know how your carrier chose to provide visibility, you can reach out to them and ask them to review this overview about the Visibility Hub connection possibilities.
Tracking data missing for allocated vehicle
Vehicle information was provided (through one of the sources mentioned above), but no tracking data of this vehicle was received.
For vehicles integrated from a carrier or subcarrier via GPS (telematics) integration (scenario 1 & 2 above), the vehicle owner needs to check with the telematics provider what causes the data transmission not to be operational.
For vehicle license plate information provided via a carrier inhouse connection (scenario 3 above), it should be checked if data was sent at all and whether it was valid or not.
Usually, the interface used to communicate with Visibility Hub provides immediate feedback in case the data sent was invalid and couldn't be used to track the transport. If you're unsure, reach out to our support.
Timeslot missing
It can happen that some stops of a transport do not have any time reference (ie. a timeslot, appointment time, from/to planned time) defined. This is fine as long as at least one stop has a time reference indicated.
If a stop that doesn't have a time reference defined couldn't be tracked (which means Visibility Hub wasn't able to confirm arrival/departure based on the tracking data provided), this tracking cancelled reason is shown.
The transport owner should define a time reference for the problematic stop(s). Note that Visibility Hub highly recommends having a time reference for all stops in a transport to have accurate ETA calculation and ETA status definitions (on time / delayed).
No vehicle movement
When GPS data is received for a vehicle on a transport, but it either stands still or only has minor movements (like manoeuvring on a warehouse yard or going back and forth from a rest area to a gas station), this cancellation reason is shown.
Depending on how GPS data is provided, the carrier should check the vehicle's telematics system configuration (or in doubt, reach out to the telematics provider) or check if there's something wrong when sending GPS data from the inhouse system.
Insufficient tracking data received
GPS tracking data was received, but it was not enough to complete tracking. Within the cancellation reason, you can see
the portion of the transport distance
the portion of the timeframe as well as
how many stops Visibility Hub managed to track with the data provided.
Visibility Hub detects this cancellation reason when one of these two conditions is met:
No loading stop has been visited and all unloading stops were visited
No vehicle has approached any unloading stop close enough
The tracking data provider (carrier, subcarrier) should check if the correct tracking data was provided and b) additional tracking data from other vehicles involved in this transport is potentially missing.
Have a look at this article for how to provide tracking data from multiple vehicles on one transport.
Tractor switch failed
Applies on the following conditions:
Multiple vehicles are involved in the transport execution
Vehicles were allocated to a transport beforehand (ie. they were planned upfront)
It was expected that the tracking should switch from one vehicle (usually a tractor) to another
When the switch from one vehicle to another is not detected, this tracking cancelled reason is shown. The most likely reason is that the switch from one vehicle to another was not detected by the means Visibility Hub supports (see this article for more details).
Mind that this cancellation reason is only shown when it's not an Insufficient tracking data received case.
Truck movement mismatch
Whenever Visibility Hub receives tracking data for a transport that does not really match the transport plan (which involves the stops and their locations), this cancellation reason is shown.
The following are examples of such scenarios:
The stops were not visited as planned
The tracked route deviated a lot from the projected one
The vehicle is going back and forth without a clear pattern in respect to the stop locations
The addresses/locations used in the system do not match with the actual stops locations.
Etc.
It means that some tracking data was received, but no matter how hard we tried, we couldn't make a meaning out of it.
Tracking cancelled manually
In this case, a user cancelled the tracking manually by clicking the stop tracking button in the application as shown below [click to enlarge]:
If the tracking was cancelled manually, it's final and therefore not possible for the transport to transition back to Tracking state, even if tracking updates are still received (see “Transport state transition” section for more details).
Address missing or malformed
Based on the address data provided, Visibility Hub wasn't able to figure out the location of the respective stop(s) in the transport. As stop locations are the basis for tracking, it wasn't possible to proceed.
The transport owner should check the address data provided on the respective stop and update it accordingly. As an alternative, geo positions can be sent directly, or a Visibility Hub Place can be created.
Have a look at this article to learn more about Visibility Hub Places.
Carrier not registered
If a transport is received where the assigned carrier isn't registered* on Visibility Hub yet, this cancellation reason is shown.
*Each carrier is asked to register and set up a tracking data connection that Visibility Hub offers. Have a look at the connection possibilities for carriers to learn more about the different options.
You can invite the carrier by using the invite functionality as part of the Visibility Control Center. Have a look atthis article to learn more.
Maximum visibility period exceeded
The time between the scheduled start and end of this transport is too long.
If Visibility Hub receives a transport where the timeframe between the earliest stop time reference (ie. timeslot) compared to the last one is longer than 90 days, tracking is not initiated and this cancellation reason is shown. For privacy reasons (e.g. to avoid showing unrelated tracking data), such transports are not allowed.
Make sure to create transports where the timeframe is less than the above mentioned period to ensure that tracking can be initiated respectively.
Data sharing issue
When there is no consent between the involved stakeholders on a transport (usually the shipper and the carrier) to exchange data, Visibility Hub does not track transports. You can resolve this situation by giving consent to share tracking data between you and your partner.
If you're a shipper, have a look at the Consent Management for Shippers article.
If you're a carrier, have a look at the Consent Management for Carriers article.