How do you build customer-facing tracking out of raw scan events?

The scan feed is not the product

Raw scans are operational telemetry. They record that a barcode was read at a sorter, that a container was loaded, that a bag was opened at a depot, and each carrier expresses those with its own codes, its own granularity and its own idea of what is worth reporting. Publishing that directly gives the customer a page that is simultaneously overwhelming and uninformative, full of movements between facilities they have never heard of.

What a customer wants answered is smaller: is it coming, roughly when, and do I need to do anything. So the first design decision is a deliberately narrow public vocabulary, on the order of half a dozen states, and a mapping from every carrier code into it. Something like accepted, in transit, arrived at the local depot, out for delivery, delivered, and needs your attention. Everything else, and there will be a lot of it, maps into one of those or is discarded from the public view while remaining in the internal event log for investigation and for claims.

That mapping is where partner onboarding lives. A new carrier's codes are used inconsistently, so the mapping is empirical work against real files, and the default for an unmapped code must be safe rather than clever: treat it as in transit, log it loudly, and let somebody classify it before it means anything customer-visible.

Silence is the normal state

The mental model that breaks tracking is a stream of frequent updates. In reality a parcel is scanned when it crosses a boundary someone bothered to instrument, which for a long-haul leg can mean nothing at all for days. A gap is not evidence of a problem, and the interface has to say something reasonable during it.

The workable approach distinguishes expected silence from unexpected silence. Each state has a distribution of how long parcels normally sit in it on that lane, learned from your own history rather than assumed. Within that distribution, the page explains why nothing is changing: it is on a long leg, the next update is due when it reaches the destination country. Beyond it, you have an exception worth raising internally before the customer notices.

The distinction to make in an interview is between quiet and lost. A parcel with no scan for a week on a lane where that is common is quiet. A parcel that missed a scan point it should certainly have hit is a candidate for lost, and it is the missing expected scan, not the elapsed time, that gives the stronger signal.

Arrival order is not chronology

Scans arrive late, duplicated and out of sequence for structural reasons. A handheld that was offline uploads a batch when it reconnects. A partner sends status in a scheduled file rather than as events. A retried submission produces the same fact twice.

So every event carries the time it happened and the time you received it, and the customer-visible status is derived from the event set in a fixed state order rather than from whichever event landed most recently. The property you are buying is that a departure scan uploaded hours late cannot move a delivered parcel back into transit. That matters more with a partner's feed than with your own scanners, because you can fix your own client and cannot fix theirs.

One case is a genuine regression and must be modelled rather than suppressed. A parcel delivered to the wrong address and recovered has really gone backwards, and that is a correction: an event superseding the earlier one, with both retained, rather than a relaxation of the monotonic rule for everything.

Notifications need separate handling, because a write can be idempotent while a message cannot. If the customer has been told the parcel is out for delivery, a later-arriving earlier event must update the internal history without sending anything. Notifications are triggered by transitions of the derived public status, never by the arrival of an event.

An arrival estimate is a distribution compressed into a sentence

An estimate is a prediction with a spread, and the spread varies enormously along the journey. At acceptance, before a multi-leg international movement, the honest interval is days wide. On the van with fifteen stops ahead it may be tight enough to name an hour. Publishing a single time in both cases uses one representation for two very different states of knowledge, and the early one will be wrong often enough to teach customers to ignore it.

So choose consciously which part of the distribution you publish. The median means you are late half the time, which reads as unreliability even though the model is unbiased. A high percentile means you are usually early, which is a better experience and a worse-looking number in a comparison. Naming that as a business decision is worth credit, because it exposes that a more accurate estimate and a better one are not the same thing. Communicating the width is then mostly language: name the day rather than the hour, or say when the estimate will sharpen. What you must not do is show a precise time with no signal that it is a guess and then quietly replace it, because the customer cannot distinguish a refinement from a delay.

What a tracking page must never do

Three behaviours destroy trust faster than any inaccuracy. Regressing a status, so that a delivered parcel appears in transit again, which reads as the parcel having been lost. Repeating a notification, so the customer is told twice that it is out for delivery. And holding a confident, stale message across a long silence, so the page insists everything is on schedule for three days after the parcel stopped moving.

All three come from the same source: treating the feed as a sequence of updates to apply rather than a set of evidence to interpret. The recorded history and the parcel's real journey are different things, and the gap between them is the ordinary condition rather than a fault, so the value the tracking system adds is detecting the divergence early and describing it in language a customer can act on.

Customers forgive a delivery that is late and do not forgive a tracking page that told them something confident and wrong, so the design target is honesty about uncertainty rather than precision.