A tracking page can say that a container has left a terminal even though the vessel remains alongside.

A parcel may appear to travel backwards after a delayed depot scan reaches the carrier’s system. Neither message necessarily identifies where the item is at that moment.

Shipment tracking is built from recorded events. Each scan describes something observed by a person, device or connected system. The customer-facing status is an interpretation of those records.

One Scan Carries Several Clocks

Consider a carton scanned as it enters a sorting hub at 09:14. A disconnected handheld may store that event, upload it at 09:47 and pass it through an integration at 10:02. A customer could see “arrived at facility” nearly an hour late.

Three times can consequently matter: when the activity occurred, when the source system recorded it and when another application received it. Sorting only by arrival time can put a late event after a genuinely newer one.

Event order and display time also remain separate when gambling winnings are withdrawn. At a casino selected through online pokies, a winning slot round is first settled and its payout added to the account balance. A withdrawal may then be requested, after which the operator can review identity, payment details and unfinished bonus wagering conditions. Only when approved funds are released should the status become processed or paid. A delayed notification cannot precede the event authorising transfer.

The logistics lesson is practical: a timestamp without a definition creates false precision. Systems need event time, time zone, source and event type before they can build a reliable history.

Milestones Describe Actions

“Loaded”, “departed” and “delivered” sound like locations, yet each describes an action or business milestone. A loaded container may still be at the terminal. A parcel marked “out for delivery” has entered a delivery run, but its exact position may be unavailable if the vehicle supplies no live location data.

A useful event record usually answers several questions:

• what object was handled, identified by a parcel, pallet or container number;
• what happened, such as gate-in, loading, discharge or delivery;
• when the activity occurred, including the time zone;
• where it occurred, using an agreed facility or location identifier;
• which business process and source produced the record.

These fields let software distinguish a physical movement from a document update. They also allow an operations team to investigate an exception without treating every tracking message as GPS evidence.

Events Can Reach Systems Out of Order

A typical shipment crosses several organisations. A warehouse system confirms picking, a carrier app records collection, a terminal reports gate movements and an ocean carrier publishes vessel events. Each participant has its own processing schedule and terminology.

The Digital Container Shipping Association says inconsistent and delayed data exchange affects milestones including loading, discharge, gate-in, gate-out, transhipment, collection and drop-off. Its Track & Trace standard uses standardised definitions, data models and APIs so stakeholders can exchange operational events consistently.

Even a common format does not guarantee perfect chronology. Devices lose coverage, integrations retry failed messages and terminals submit corrections. The receiving system needs rules for late, duplicate and amended events.

Corrections Should Not Erase History

Operational mistakes happen. A handler may scan the wrong pallet, a driver may select “delivered” before completing the stop or a carrier may revise a vessel departure time. Replacing the original record silently makes later investigation harder.

A stronger event model keeps the history and correction. It can mark a record as superseded, connect the amendment to it and identify the source, preserving an audit trail.

Teams designing the process should decide:

• whether repeated scans are duplicates or separate physical actions;
• which source takes priority when two partners report conflicting events;
• how corrections are linked to the original record;
• whether estimated and confirmed milestones are visually distinct;
• how long raw events and their provenance are retained.

These decisions belong in data governance and operating procedures. Leaving them to a dashboard developer invites inconsistent answers across customer service, warehouse and transport teams.

Location Data Needs Its Own Label

Event tracking and continuous positioning serve different purposes. A gate-out message confirms that an asset passed a defined operational point. A telematics unit can provide coordinates between such points, although coverage, reporting intervals and device condition affect freshness.

Mixing the two creates misleading certainty. If the latest GPS ping is four hours old, a map should show its age rather than presenting the marker as current. If no positioning device is attached, the system should describe the latest confirmed milestone instead of inferring a precise location.

Estimated arrival times add another layer. They are predictions calculated from route, schedule, traffic and previous performance; they are not observed events. Keeping estimates, physical events and position reports separate makes each one more useful.

Good Tracking Shows What Is Known

An effective tracking interface should show the latest confirmed activity, its time and an honest description of its meaning. Operations staff may also need the source, receipt time and corrections.

The distinction matters when a shipment appears to stall or move backwards. Often the goods have continued normally while an earlier scan arrived late. Treating status as an ordered account of events, rather than a live dot on a map, helps systems explain that discrepancy without inventing certainty.