The operations manager at a freight forwarder in Dubai asked me a straightforward question: "Why does our ocean tracking show a vessel update every ten minutes, but our air cargo tracking only updates twice a day?"

The answer isn't that one mode is better tracked than the other. It's that the underlying data sources are fundamentally different, and most tracking platforms don't reconcile those differences in a way that makes operational sense.

Vessel positions come from AIS (Automatic Identification System) broadcasts that update continuously. Flight data comes from aviation authorities who publish updates at specific intervals. Road shipments might use GPS trackers that ping every hour, or they might rely on EDI milestone messages that only fire at delivery stops.

If you show operators raw feeds from all three sources side by side, you're giving them three different narrative rhythms for what's supposed to be a single shipment journey. That's not helpful. What operators need is a unified timeline where a vessel departure, a flight delay, and a truck arrival all appear as events in the same sequence, with comparable levels of confidence and detail.

Building that unified view is harder than it sounds.

The Signal Volume Problem

Let's start with the scale of raw data involved. Terrestrial AIS receivers - the shore-based antennas that pick up vessel broadcasts - capture position updates every 2-10 seconds when a vessel is near the coast. A single vessel can generate thousands of AIS messages per day. Across a global receiver network, the total message volume exceeds 300 million AIS transmissions daily.

Not all of those messages are useful. Many are duplicates - the same position reported by multiple receivers. Some are low-quality signals with poor GPS accuracy. Some are transmitted from vessels that aren't carrying your cargo. The challenge is identifying which signals correspond to the specific vessel carrying your specific container, then filtering that stream down to the subset of position changes that actually matter to an operator making decisions.

For flight tracking, the data structure is completely different. Most air cargo tracking relies on flight status APIs from aviation data providers like FlightAware or AviationStack. These systems don't provide continuous position updates. Instead, they report scheduled departure, actual departure, estimated arrival, actual arrival, and sometimes gate information. Updates typically occur at major milestones - pushback from gate, wheels-up, landing, arrival at destination gate.

That's fine for air cargo, where the transit time is measured in hours and the shipment is either on the plane or it's not. But it creates a mismatch when you're trying to show ocean, air, and road segments of the same multi-modal journey in a single timeline. The ocean leg has minute-by-minute position updates. The air leg has four or five milestone events over the course of a flight. The road leg might have hourly GPS pings or might just have "picked up" and "delivered" EDI messages with nothing in between.

If you render all of that raw data directly into a timeline, operators get whiplash. The ocean segment looks like a detailed narrative. The air segment looks sparse. The road segment might look completely silent except for the bookends.

Normalization: Building a Canonical Event Model

The fix is normalization: translating those different data structures into a canonical set of event types that operators understand consistently across all modes.

Here's the event model we use at QueChains:

Departure: Vessel left port, flight took off, truck departed warehouse
In Transit: Periodic position updates, segment milestones
Arrival: Vessel docked, flight landed, truck arrived at destination
Delay: Estimated time changed, route deviated, stop exceeded planned duration
Exception: Customs hold, mechanical issue, weather rerouting

Every tracking source - AIS, flight APIs, GPS trackers, EDI messages - gets mapped into one of those categories. A vessel "departed" event comes from an AIS position change showing the vessel leaving the port's geofence. A flight "in transit" status comes from a FlightAware API call showing the plane airborne. A truck "arrival" event comes from an EDI "delivered" message or a GPS position entering the destination facility's geofence.

Once everything is mapped to the same event vocabulary, the timeline is consistent. Operators see "Departed" for all three modes. They see "In Transit" updates for all three modes, even though the update frequency varies. They see "Arrived" for all three modes. The data sources are different under the hood, but the operator experience is unified.

This isn't just cosmetic. Normalizing events into a consistent structure lets you build automated logic on top: send an alert when any leg's ETA changes by more than 6 hours, regardless of mode. Flag any shipment that's been "In Transit" for longer than expected based on distance and mode. Automatically notify the consignee when the final leg shows "Departed" from the last-mile hub.

You can't build that automation if every mode speaks a different event language.

Deduplication and Quality Scoring

Raw AIS feeds are noisy. A vessel near multiple terrestrial receivers will broadcast the same position to all of them. Your data pipeline will receive multiple copies of the same message, sometimes with minor discrepancies in timestamp or position precision.

If you write all of those messages directly to your shipment timeline, you'll show the same position update five times in a row. That's noise, not signal. Operators need to see one update: the most accurate one.

Our deduplication logic works like this:

Group messages by vessel and timestamp window (±30 seconds)
Score each message based on signal source quality (satellite AIS is more reliable than terrestrial in open ocean; terrestrial is more reliable near coast)
Check consistency with adjacent position updates (if a message shows a vessel 200 km away from the previous position five minutes earlier, that's likely a GPS error or transmission corruption)
Promote the highest-quality message to the canonical timeline
Archive all raw messages for audit purposes

The result: operators see one clean position update every ten minutes (or whatever interval makes sense for the voyage segment), rather than dozens of duplicate or low-quality pings per hour.

For flight tracking, deduplication is less of an issue because aviation APIs already consolidate data before you receive it. The challenge there is usually latency: flight status updates can lag reality by 10-20 minutes, especially for regional carriers in emerging markets. We handle that by showing update timestamps explicitly and allowing operators to manually refresh flight status if they need the latest information before the next automated refresh cycle runs.

For road tracking, quality issues usually come from GPS signal loss (tunnels, remote areas, urban canyons) or device battery failures. We flag gaps longer than expected based on route characteristics and mark those segments as "signal lost" rather than pretending we have continuous visibility. Operators need to know when they don't have data.

Correlating Events to Shipments

Here's the subtlety most platforms miss: a vessel position or flight status by itself is not a shipment event. It's only relevant if that vessel or flight is actually carrying your cargo.

AIS tells you where a vessel is. It doesn't tell you which containers are on board. Flight APIs tell you when a flight departed. They don't tell you which air waybills are on that flight. GPS tells you where a truck is. It doesn't tell you which shipments are loaded.

The correlation step - linking a vessel MMSI number or a flight number or a truck license plate to a specific shipment record in your system - is where most integration problems occur.

We solve this through a lookup table that maps transport identifiers (MMSI, flight number, vehicle ID) to shipment references during the booking process. When a customer books ocean freight and provides the vessel name and voyage number, we resolve that to an MMSI and start tracking that vessel. When they book air freight and provide the flight number, we start tracking that flight. When they assign a truck to a shipment, we start tracking that vehicle.

The tracking data flows into the shipment timeline only for shipments explicitly linked to that transport. If we're tracking 500 vessels because we have 500 ocean shipments in progress, an AIS update for vessel A only appears on the timeline for shipments carried by vessel A. The other 499 shipments don't see that update.

That sounds obvious, but I've seen platforms that show every vessel or flight they're tracking to every customer, regardless of relevance. The resulting timelines are filled with events for cargo the operator doesn't care about.

Frequently Asked Questions

How accurate are AIS position updates, and what causes discrepancies?

AIS position accuracy depends on the vessel's GPS receiver quality, typically within 10-50 meters under normal conditions. Discrepancies occur when GPS signals are degraded (near tall structures, in ports with obstructions), when multiple receivers report slightly different timestamps for the same position, or when the AIS transceiver itself malfunctions. Satellite AIS is generally more accurate than terrestrial in open ocean because it doesn't suffer from receiver overlap issues, but it updates less frequently (every few minutes vs. every few seconds).

Why do some flights show real-time position tracking while others only show milestone updates?

Real-time flight position tracking requires access to ADS-B (Automatic Dependent Surveillance-Broadcast) data, which not all aircraft transmit and not all regions cover with ground receivers. Most commercial passenger flights in North America, Europe, and major Asia-Pacific hubs have ADS-B coverage. Cargo flights on older aircraft or flights in remote regions often only provide milestone updates (departed, landed) from airport operational data.

What happens to tracking accuracy when a shipment switches from ocean to road in a port?

There's typically a visibility gap during port drayage - the period between vessel arrival and container pickup by the inland carrier. Vessel AIS stops updating once the container is unloaded. Road tracking doesn't start until the container is on a truck with a GPS tracker or the trucker checks in via EDI. To bridge that gap, we use port operational data (container discharge lists, gate-out timestamps) when available, or we estimate based on typical dwell time for that port and cargo type. We flag this period as "estimated" so operators know it's not live tracking.

How do you handle tracking for shipments with multiple legs operated by different carriers?

We maintain separate tracking data streams for each leg but display them as a continuous journey in the operator timeline. When leg 1 (ocean) transitions to leg 2 (road), we show a handoff event with the estimated or actual transfer time. Each leg retains its source tracking system (AIS for ocean, GPS for road), but the timeline stitches them together. If there's a delay in one leg, we propagate ETA changes downstream to subsequent legs.

Can operators access raw tracking data, or only the normalized timeline?

Both. The normalized timeline is the default operator view because it's cleaner and easier to act on. But every event in the timeline links back to the raw source data - the original AIS message, the flight API response, the GPS ping. Operators (and auditors) can drill down if they need to verify a specific update or troubleshoot a discrepancy.

How often does the tracking system update, and can we configure update frequency?

AIS-based ocean tracking updates every 10 minutes by default (configurable down to 1 minute or up to 1 hour). Flight tracking checks every 15 minutes while airborne. Road GPS tracking updates based on the tracker's configuration, typically every 30-60 minutes unless motion detection triggers more frequent updates. Customers on enterprise plans can configure update frequency per shipment type or corridor.