Understanding Tracking Events

Every shipment tracking system is built on tracking events – individual status messages that a carrier generates as soon as a shipment passes a defined point in the logistics network. For retailers, warehouse operators, and fulfillment teams, these events are far more than technical log entries: they drive customer notifications, trigger escalations, and provide the foundation for KPIs such as delivery rate or average transit time.

Understanding tracking events allows you to proactively avoid WISMO inquiries ("Where Is My Order?"), detect exceptions early, and base customer communication on reliable data. This guide explains the most important event categories, highlights differences between carriers, and provides concrete recommendations for everyday fulfillment operations.

What Is a Tracking Event?

A tracking event is a timestamped record that contains at least the following information:

• Event code or status label (e.g. "In transit", "Delivered")
• Timestamp (date and time of the scan)
• Location (parcel center, depot, delivery base – depending on carrier granularity)
• Shipment reference (tracking number, barcode if applicable)

Events are created through physical scans (barcode on the package), automated sorting systems, or manual entries in carrier systems. Not every event represents visible progress for the end customer – some messages only document electronic order transmission before the package has been physically moved.

Overview of the Most Important Event Categories

Regardless of the carrier, tracking events can be grouped into recurring categories. These categories form the basis for unified event mapping in shop systems, WMS, and shipping software.

Event Categories vs. Customer Perception

Pre-advice vs. First Physical Scan

A common fulfillment mistake: the tracking number is sent to the customer immediately after label creation – but tracking only shows "Shipment information received". The customer sees no progress and contacts support.

Recommended approach:

1. Share tracking number immediately (transparency)
2. Clarify in the email when first scan events will appear
3. Trigger "Package on its way" customer notification only after the first physical event
4. Account for carrier cut-off times and pickup schedules in communication

Carrier-Specific Event Labels

Each carrier uses its own status codes and wording. DHL, GLS, DPD, Hermes, and UPS differ in granularity, update frequency, and detail of location information. With a multi-carrier strategy, normalized event mapping is essential.

Event Mapping for Shop and WMS

For tracking events to be useful in fulfillment, they must flow from the carrier system into your ecosystem. Typical integration paths:

• API polling or webhooks – carrier pushes events in real time or the system queries regularly
• EDI/file import – batch processing, e.g. nightly status files
• Tracking aggregators – third parties normalize events from multiple carriers

Standard mapping for shop status:

1. shipped – label created, optionally only after first scan
2. in_transit – package in transit within carrier network
3. out_for_delivery – delivery likely on the same day
4. delivered – delivery confirmed
5. exception – delay, failed delivery, or address issue
6. returned – return to sender initiated

Event Sync from Carrier to Customer

Handling Unknown Events

New or rare carrier codes regularly lead to mapping gaps in practice. Unknown events should:

• be logged (raw code + timestamp)
• not automatically be interpreted as "delivered" or "error"
• be remapped in a weekly review with the shipping team

Recognizing and Handling Exception Events

Exception events are the most important triggers for proactive customer management. They signal that standard delivery has been interrupted – and the faster you respond, the lower the risk of negative reviews.

Common exception events:

• Recipient not available
• Address incomplete or not found
• Package damaged or contents lost
• Customs delay (international)
• Delivery refused
• Package ready for pickup at branch/parcel locker

Time Gaps in the Event Chain

Not every shipment provides continuous updates. Longer pauses between events are normal – especially with:

• weekend and holiday shipping
• international shipments with customs hold
• rural delivery areas with less frequent scanning

As a rule of thumb: More than 48 hours without a new event after the last transit scan warrants an internal check with the carrier. More than 72 hours without movement on domestic shipments is an escalation case.

Typical Event Sequence for Domestic Shipping

POD and Proof of Delivery as the Final Event

The last relevant event is the delivery confirmation. Many carriers additionally provide proof of delivery (POD) – such as a signature, photo of the drop-off location, or neighbor's name. This proof is crucial for claims ("Package not received").

Archive POD data for:

• disputes with customers
• insurance claims for damaged goods
• SLA proof for marketplaces
• quality analysis (e.g. frequent neighbor deliveries)

Deriving KPIs from Tracking Events

Tracking events are the raw data for central fulfillment metrics. Timestamps can be used to automatically calculate:

• Time to First Scan – time from label creation to first physical event
• Transit Time – duration from acceptance to delivery
• First Attempt Delivery Rate – share of deliveries on first attempt
• Exception Rate – share of shipments with exception events
• On-Time Delivery – delivery within promised time window

From Events to KPIs

Practical Checklist: Using Tracking Events Professionally

Setup and Mapping

• All carrier codes used documented in a mapping table
• Shop status reduced to a maximum of 6–8 normalized values
• Unknown events are logged, not ignored
• API connection or aggregator set up for real-time sync

Customer Communication

• Shipping confirmation with tracking link after label creation
• "Package on its way" only after first physical scan
• Automatic notification on "Out for delivery"
• Immediate alert on exception events with action options
• Plain language in emails, not just carrier raw status

Operational Monitoring

• Daily review of all shipments with exception status
• Escalation rule for 48h+ without event movement
• POD archiving for at least 90 days
• Monthly KPI reconciliation with carrier SLA

Quality Assurance

• Spot checks: test tracking link in customer email
• Review mapping after carrier updates (carriers change codes)
• Peak season: factor in increased scan delays

Avoiding Common Mistakes

001. "In transit" notification too early
When only pre-advice events exist, communication appears unreliable. Wait for the first physical scan or explain the waiting time transparently.

002. Exception events not connected
Many shops notify on shipping and delivery, but not on failed delivery. That's where most support tickets originate.

003. No multi-carrier mapping
Without normalization, the shop shows different text for the same progress – confusing for regular customers and poor for brand presentation.

004. Events not archived
Without historical event data, claims and carrier performance cannot be traced. Export events to your data warehouse or CRM.

005. Seeing tracking only as a customer feature
Tracking events are an operational early warning system. The support team should have dashboard access to exception shipments.

Related Topics

• Tracking and Shipment Tracking
• Tracking Number and Tracking
• Proof of Delivery and POD
• Label Creation
• Multi-Carrier Strategy

Last updated: July 6, 2026