General
Building Real-Time Location Tracking for Last-Mile Delivery: Architecture, Tradeoffs, and Engineering Decisions
Aug 20, 2026
14 mins read

Key Takeaways
- Last-mile tracking is a different engineering problem from freight tracking, not a higher-frequency version of it. Fidelity requirements, error tolerance, and workflow state all differ by an order of magnitude.
- Raw GNSS coordinates are not in a usable state. Map matching, accuracy gating, and fused positioning sit between the chip and anything an operations team should see.
- ETA is a machine learning problem with a routing foundation. Network travel time is the easy part; dwell and last-meter time are where the error lives.
- Geofence false triggers are the most common production defect in last-mile tracking, and they are solved with hysteresis and accuracy gating rather than with better GPS.
- The questions that separate a production platform from a demo are about offline behavior, event ordering, and start-of-shift load, not about map aesthetics.
Why last-mile tracking is harder than freight tracking
Freight visibility platforms operate on carrier milestones, EDI feeds, and sparse position pings across long hauls. A shipment moving 800 miles tolerates a thirty-minute reporting gap because the state has not meaningfully changed.
Last-mile inverts every one of those assumptions.
Concurrency is high and geographically dense. Hundreds or thousands of drivers operating simultaneously inside a metro, frequently within a few city blocks of each other, which affects both ingestion design and the spatial indexing discussed later.
Update frequency is measured in seconds. Position at ten to thirty second intervals rather than every half hour, because a vehicle in urban traffic changes meaningful state continuously.
Positional error is worse exactly where density is highest. Consumer GNSS achieves roughly three to five meters horizontal accuracy under open sky and degrades substantially in urban canyons, where signal multipath from tall buildings reflects and delays the satellite signal. Errors of tens of meters in dense downtown cores are normal, not exceptional.
Workflow state matters as much as coordinates. En route, arrived, parked, walking, at door, and completed are distinct states with different operational meanings, and none is derivable from latitude and longitude alone.
Error tolerance is minutes, not hours. A delivery window measured in hours makes a five-minute ETA error material, where the same error is invisible on a multi-day freight movement.
The consequence for architecture is that carrier-grade tracking cannot be adapted to last-mile by increasing the polling rate. The pipeline below exists because each layer solves a problem freight tracking does not have.
Also Read: The Real-Time Decision Surface: A Framework for US CTOs Evaluating AI Logistics Orchestration
The location pipeline, from GNSS chip to dispatcher view
Five layers, each with a design decision that determines what the layer above can do.
On-device positioning. The GNSS receiver produces a fix with an associated accuracy estimate. Modern devices do not use it raw: platform location services fuse GNSS with WiFi and cell-tower positioning and with inertial sensors for dead reckoning when satellite signal drops, which is what keeps a position moving through a tunnel or a parking structure. The engineering consequence is that every fix arrives with a confidence radius, and that radius is a first-class input rather than metadata. A fix with a fifty-meter accuracy estimate should not trigger an arrival event regardless of where its coordinates fall.
Transmission: push versus poll. Polling at a fixed interval is predictable and simple to reason about, and it burns battery and cellular data reporting a stationary vehicle. Event-driven push transmits on movement threshold or state change, which is far more efficient and requires reliable state detection on the device, since a device that misclassifies stationary will go silent. Most production systems land on adaptive cadence: high frequency while moving, reduced while stationary, and immediate transmission on state transitions such as arrival or departure. Battery optimization behavior on mobile operating systems, which aggressively suspends background activity, is the practical constraint that shapes this decision more than theory does.
Ingestion. Thousands of concurrent driver streams producing several events per minute is a sustained write load with strict ordering requirements per driver and no ordering requirement across drivers. An append-only event log partitioned by driver identifier gives per-partition ordering and horizontal scale together. Two properties matter in production: backpressure handling, so a downstream slowdown does not drop events, and idempotent ingestion with a deduplication key, because replayed events from reconnecting devices are normal rather than exceptional.
Processing: map matching. A raw coordinate in a dense city block can place a driver on a parallel street thirty meters away, which produces wrong ETAs and spurious geofence events. Map matching snaps observed positions to the most probable sequence of road segments, typically using a hidden Markov model where emission probability reflects the distance from observation to candidate road and transition probability reflects the plausibility of the route between consecutive candidates, decoded with Viterbi. Matching the sequence rather than each point independently is what makes it robust: a single bad fix is outvoted by the trajectory around it.
Storage. Two access patterns, two stores. Current position is a small, extremely hot key-value read serving the dispatcher view and every ETA recalculation. Location history is an append-heavy time-series workload queried by driver and time range for reconstruction, dispute resolution, and model training. Serving both from one store means one of them is badly served.
Diagram note for design: device layer producing fused fixes with accuracy radius, feeding an adaptive transmission layer, into a partitioned event log, into map matching and state derivation, splitting to a hot current-state store and a time-series history store, with a feedback arrow from state changes back into ETA recalculation.
ETA: a machine learning problem with a routing foundation
Network travel time is the solved part of this problem, and it is the smaller part.
Base travel time. A routing engine over the road network, whether a commercial service or an open-source engine such as OSRM or Valhalla, returns segment-level traversal time with historical and live traffic. The academic evidence supports using live conditions: research published in Operational Research found dynamic vehicle routing with real-time traffic information significantly reduces total trip duration compared with static, a-priori routing models. Traffic variability is also material in absolute terms, with INRIX finding US drivers lost 49 hours to congestion in 2025, and congestion rising in 88 percent of the 290 cities analyzed.
Dwell time. How long a driver spends at a stop varies by building type, floor, access difficulty, order composition, time of day, and the individual driver. A fixed constant is the single largest source of ETA error in most implementations. This needs a model trained on observed service times, with location identity as a feature, because the same address behaves consistently and differently from its neighbor.
Last-meter time. The part invisible to a routing engine, and it dominates. Urban Freight Lab research at the University of Washington, based on more than 1,800 real deliveries, found urban commercial vehicles spend around 80 percent of daily operating time parked, with most of a driver’s time spent outside the vehicle walking the final stretch. Cargo-cycle drivers spent roughly 60 percent of time parking and walking against 40 percent driving. An ETA model that treats arrival at the curb as arrival at the door is modeling the minority of the shift.
Cascading error. Errors compound along a sequence. A three-minute underestimate at stop two is a fifteen-minute error at stop seven if nothing corrects it, which means per-stop accuracy matters less than whether the sequence is re-estimated as it executes.
Recalculation triggers. Position updates, state transitions, and route deviations should each trigger re-estimation of downstream stops. A static ETA set at route start is stale by the third stop, and communicating it to customers is worse than communicating nothing because it manufactures a broken promise.
Also Read: How AI Route Optimization Actually Works: A Technical Guide for Enterprise Logistics Leaders
Geofencing: implementation and failure modes
Geofences generate arrival events, notification triggers, and SLA timestamps, which makes their failure modes disproportionately visible.
Geometry. Circular geofences are a distance comparison against a centroid, computationally trivial and adequate for point addresses. Polygon geofences trace an actual footprint and matter for large, irregular, or multi-entrance sites such as campuses, malls, and industrial parks. Point-in-polygon by ray casting is O(n) in vertex count per evaluation.
Evaluation at scale. The naive approach evaluates every active driver against every geofence, which is a product that grows unpleasantly. Production systems index geofences spatially, using an R-tree or a hierarchical cell system such as geohash, S2, or H3, to reduce candidates to a small set before running exact geometry. Bounding-box prefilter before ray casting is the standard optimization.
False triggers. This is the most common production defect in last-mile tracking. A stationary driver at a delivery point produces fixes that jitter by several meters, and if the stop sits near a geofence boundary the system reports repeated entries and exits, each firing a customer notification. Three mitigations, usually combined:
- Accuracy gating. Discard or downweight fixes whose reported accuracy radius exceeds a threshold, since a fifty-meter fix cannot resolve a thirty-meter geofence.
- Debouncing. Require N consecutive in-zone readings, or a minimum dwell inside the boundary, before firing an entry event.
- Hysteresis. Use a larger exit radius than entry radius, so leaving requires more evidence than arriving. This alone removes most oscillation.
The last fifty meters. GNSS degrades or fails inside buildings, so the final segment of most urban deliveries is unobserved. Practical approaches include treating driver-confirmed arrival as the authoritative event with geofence entry as corroboration, capturing proof of delivery with a timestamp and image as the completion record, and where economics justify it, floor-level or beacon-based positioning. Any system claiming reliable automated indoor arrival detection at scale from GNSS alone should be examined closely.
Also Read: Why Real-Time Visibility Fails: The Data-Quality Problem Behind the Dashboard
Scalability and reliability
Four questions separate production systems from demonstrations.
Horizontal scale. Stateless processing over a partitioned event stream scales by adding consumers. Per-driver state, which map matching and ETA recalculation both require, has to live somewhere, and the design choice is between an external state store with fast lookups or partition-local state with the durability and rebalancing complications that brings. Either is defensible; the absence of an explicit answer is not.
Connectivity loss. A driver in a tunnel, a basement loading dock, or a rural dead zone will be offline for minutes. The device must buffer fixes locally with monotonic timestamps and replay on reconnection, and ingestion must be idempotent and tolerant of out-of-order arrival. This is where event time and processing time have to be handled separately: a fix generated at 14:12 and received at 14:19 is evidence about 14:12, and treating it as current position teleports the driver backwards.
Latency budget. End-to-end delay from device fix to visible state in the dispatcher view is worth specifying explicitly and measuring under load rather than at rest. The relevant question for a buyer is what the number is at peak concurrency and what happens to it when a downstream component degrades.
Start-of-shift load. The daily peak is not evenly distributed. Hundreds of drivers beginning routes within the same fifteen-minute window generate a simultaneous surge of route activation, initial position reporting, and ETA computation. Systems provisioned for average load fail at 07:00 rather than gradually.
This layer determines whether visibility supports action or only reporting. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time.
Where Locus fits
Locus, the world’s first Decision-Intelligent, Agentic TMS, sits above this pipeline as the decision layer that consumes it. The Fireworks Routing Engine generates plans in under five minutes at enterprise volumes and plans up to 100,000 routes simultaneously against 250+ real-world constraints. Within DiSCO, position and state events are sense inputs on a continuous Sense, Decide, Execute, Learn cycle, so a deviation or delay triggers recalculation rather than an alert.
Two deployments give integration-layer figures rather than marketing ones. A US home care provider runs Locus alongside a clinical decision support system and an electronic health record, with appointment changes propagating across all three in under 10 seconds and integration reliability above 99 percent, meaning under 1 percent failure across the three systems. A leading ASEAN apparel retailer generates carrier labels in under 500 milliseconds at packing, with every carrier’s status harmonized into one standard set before it reaches the retailer’s OMS and WMS.
Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards.
Also Read: How Easy Is It to Integrate Locus APIs? An Architectural Framework for Enterprise Logistics in 2026
Ten technical questions for any tracking vendor
- What is the location update cadence per driver, is it adaptive by state, and is it configurable per operation?
- Do you perform map matching, what algorithm class, and against which road network?
- How is the ETA model trained, and which features beyond network travel time does it use? Specifically, is dwell time modeled per location?
- What is end-to-end latency from device fix to dispatcher-visible state, measured at peak concurrency rather than at rest?
- How does the device behave offline, how long can it buffer, and how do you handle out-of-order events on replay?
- Are ingestion endpoints idempotent, and what is the deduplication key?
- How do you prevent geofence false triggers? Ask specifically about accuracy gating, debouncing, and hysteresis.
- Do you support polygon geofences, and how are candidates spatially indexed at scale?
- How is arrival determined when GNSS is unavailable indoors, and which signal is authoritative?
- What happens at start of shift when several hundred drivers activate routes within the same window?
Question three and question seven are the most diagnostic. A vendor that models dwell per location and can describe its debounce strategy has run this in production. One that answers both with “our AI handles it” has not.
Frequently Asked Questions (FAQs)
How does real-time location tracking work in last-mile delivery?
A device produces a fused position estimate from GNSS, network positioning, and inertial sensors, each with an accuracy radius. Fixes are transmitted on an adaptive cadence, ingested into a partitioned event log for per-driver ordering, map-matched to the road network to remove positional noise, and written to both a hot current-state store and a time-series history store. State changes then trigger ETA recalculation and geofence evaluation.
Why is GPS inaccurate in cities and how do tracking systems handle it?
Consumer GNSS achieves roughly three to five meters under open sky and degrades in urban canyons because signals reflect off tall buildings before reaching the receiver, adding path length and producing errors of tens of meters. Systems compensate with sensor fusion, by treating the reported accuracy radius as a gating input rather than metadata, and by map matching the trajectory to the road network so a single poor fix is corrected by the sequence around it.
What is map matching and why does last-mile tracking need it?
Map matching snaps observed positions to the most probable sequence of road segments, commonly with a hidden Markov model decoded by Viterbi, where emission probability reflects observation-to-road distance and transition probability reflects route plausibility between consecutive candidates. Without it, a coordinate in a dense block can place a driver on a parallel street, which corrupts ETAs and produces spurious geofence events.
Why are delivery ETAs inaccurate and what improves them?
Because network travel time is the easy component and dwell plus last-meter time dominate the actual stop. Urban Freight Lab research found commercial vehicles spend around 80 percent of operating time parked, with most of the driver’s shift spent outside the vehicle. Accuracy improves with a dwell model trained per location rather than a fixed constant, and with continuous recalculation, since a three-minute error at stop two compounds to roughly fifteen minutes by stop seven if uncorrected.
What causes false geofence triggers and how are they prevented?
GNSS jitter at a stationary stop moves the reported position by several meters, so a stop near a boundary produces repeated entry and exit events, each potentially firing a customer notification. The mitigations are accuracy gating to discard low-confidence fixes, debouncing to require consecutive in-zone readings or minimum dwell before firing, and hysteresis using a larger exit radius than entry radius so departure requires more evidence than arrival.
What should engineering leads ask a last-mile tracking vendor?
Ten questions covering update cadence and configurability, map matching approach and road network, ETA model features and whether dwell is modeled per location, end-to-end latency at peak rather than at rest, offline buffering and out-of-order replay, ingestion idempotency, geofence false-trigger mitigation, polygon support and spatial indexing, indoor arrival determination, and behavior at start-of-shift load concentration.
Anas is a product marketer at Locus who enjoys turning complex logistics problems into simple, clear stories. Outside of work, he’s usually unwinding with a book or catching a good movie or series.
Related Tags:
General
Why Carrier Tracking Isn’t Enough: The Case for a Purpose-Built Last-Mile Visibility Platform
Carrier portals report on the carrier's timeline for the carrier's purposes. What last-mile operations actually need from visibility, three moments where the difference decides the outcome, and how to evaluate a platform.
Read more
General
Your Route Optimization is a Customer Retention Decision (And You’re Not Measuring it That Way)
The sequencing, ETA window, and re-routing decisions your dispatch platform makes every morning produce customer retention outcomes nobody measures. Three mechanisms, and a framework for connecting the data.
Read moreInsights Worth Your Time
Building Real-Time Location Tracking for Last-Mile Delivery: Architecture, Tradeoffs, and Engineering Decisions