When a tracking event is late, show uncertainty in the ETA

The latest GPS point is three hours old. A carrier hub-arrival scan is more recent, but the customer screen still displays an exact delivery time based on the old route position. The control team needs to decide whether to intervene.

Use the best relevant evidence to update the estimate, and show what remains uncertain. An ETA should explain when it was calculated, which events it uses and which unobserved dependencies could change it. A precise time without that context can be less useful than an honest range.

Identify the event before choosing the freshest timestamp

A GPS observation describes a device location at a time. A hub scan may describe a parcel, a bag, a vehicle or an administrative status. Confirm the identity and physical meaning before treating the two as interchangeable.

Store event time, provider creation time where available, receipt time, location, object identity and source. A message received now may describe an event from yesterday. The newest receipt is not necessarily the newest observation.

GS1 EPCIS provides artefacts for visibility-event exchange, while DCSA's Track and Trace standards address container-shipping event exchange. Neither makes every partner feed equally complete or suitable for a road-delivery ETA. GS1 — EPCIS and CBV artefacts DCSA — Track and Trace standards

Use source authority by milestone. A verified receiving scan can be stronger evidence of hub arrival than a distant GPS point, but it cannot establish that sorting or onward departure has finished.

Rebuild one estimate from the available evidence

This illustrative case is assessed at 12:00 Asia/Kolkata on 15 October 2026. The last GPS observation is from 09:00. A verified shipment-linked hub-arrival scan occurred at 11:00 and was received at 11:50.

The hub scan supports arrival at 11:00. It does not prove the shipment left the hub at 13:00. The 14:30–15:30 range should therefore be shown with that dependency, rather than replacing it with a confident 15:00.

If the agreed delivery deadline is 15:00, the range crosses the commitment. Mark the delivery at risk and assign a hub-status check. It is not yet evidence that the shipment is definitely late.

If the hub later confirms readiness will be 13:15, the same travel assumptions produce 14:45–15:45. Preserve the earlier estimate and its inputs so the team can explain why the prediction changed.

Avoid turning a range into an unsupported probability

The example's range comes from stated planning scenarios. It is not a 90% or 95% prediction interval. Such a probability label requires a model tested on comparable journeys and a clear definition of coverage.

A calibrated interval can still be operationally awkward. A broad range may contain the eventual delivery but provide little time to act. Evaluate both reliability and usefulness: how often the estimate covers the actual event, how wide it is and whether it triggers a decision early enough.

Do not infer certainty from the number of data sources. Several feeds may repeat the same underlying carrier scan. Preserve lineage where possible so duplicate reports do not look like independent confirmation.

Choose the action from the missing dependency

An alert should say what action can reduce uncertainty or protect the commitment. Repeatedly sending “ETA changed” without a decision owner creates noise.

Set recheck times according to the relevant dependency and service. If no update arrives by that point, escalate the missing evidence; do not keep extending the ETA automatically to preserve an on-time status.

Preserve the original promise

Keep the customer commitment separate from the latest prediction and any newly agreed appointment. A late estimate does not itself amend the promise. If the customer accepts a revised window, retain both the original and revised commitments with the approval evidence.

This separation matters for performance reporting. Measuring delivery only against the final estimate can make a poor service look accurate because the model learned the delay just before arrival.

For model evaluation, freeze predictions at defined horizons, such as the planning release or a specified number of hours before delivery. Compare those saved predictions with the actual event. Do not evaluate only the last prediction made after most uncertainty has disappeared.

Test the display and the escalation together

A manual control view can show evidence age, dependency and action owner without a complex prediction engine. A native tracking product may support source events and estimates. A custom model becomes useful when there is enough representative history and the operation can act on its output.

Test a stale GPS feed, a late hub scan, conflicting shipment identity, a missing departure and an actual event received after delivery. Confirm that late data corrects history without becoming a new future prediction.

Track missing-event rates, estimate error at fixed horizons, interval coverage where applicable and avoidable escalations. Keep feed health separate from carrier service performance; otherwise a communications failure can be mistaken for a transport delay.

For an ETA review, start with the milestone where the team most often loses reliable evidence and the decision that becomes difficult as a result.

Make uncertainty actionable

The useful ETA connects current evidence to a decision about the remaining journey. Showing the missing dependency helps the control team act sooner than an unexplained exact time does.

Next actions

1. Label event meaning, identity and age for every ETA input.
2. Separate observed milestones from expected readiness and travel assumptions.
3. Assign a recheck and owner when the range threatens a commitment.
4. Evaluate saved predictions against actual events at consistent horizons.