From tracker to dispatcher: how fleet telematics data works

Every vehicle tracking product looks the same from the outside: a map with moving icons. That similarity is misleading, because the map is the last stage of a pipeline and contributes almost nothing to whether the product works. What decides that is five verbs happening upstream. Positions have to be ingested reliably, cleaned, stored economically, evaluated against rules in real time, and only then presented as something a dispatcher can act on.

Each of those verbs hides real engineering, and the two that decide project viability are the least discussed. Storage volume is pure arithmetic that anyone can do in a minute, and it routinely comes out one or two orders of magnitude above what the original design assumed. Alert volume is a product decision that determines whether humans keep reading what the system sends them, and a platform whose notifications get muted has stopped delivering value while continuing to cost money.

This guide covers the device layer and its protocol reality, the ingestion pipeline, the processing that turns coordinates into business objects, the alerting design that survives contact with a dispatcher, and a phased build plan. It is based on the tracking systems we deliver inside our logistics engineering practice.

The device layer, where the protocol reality lives

Position data arrives from three classes of device, and the choice among them is commercial as much as technical. Dedicated hardware trackers, either wired into a vehicle or battery-powered on an asset, are the fleet standard: they report over cellular, carry ignition and sensor inputs, and buffer positions through coverage gaps so a tunnel does not become a hole in the record. Driver smartphones are the cheap alternative with genuine trade-offs, since the operating system restricts background work, the battery is the driver's concern rather than yours, and the driver can simply turn the app off. Diagnostic port devices sit between the two, adding vehicle data at commodity prices.

The engineering reality of hardware trackers is protocol babel. There are hundreds of models on the market speaking dozens of protocols, most of them binary, many of them documented only partially and some of them documented incorrectly. Fields are reused between firmware versions. Undocumented message types appear in production. This is not a solvable problem, it is a permanent condition of the category, and the correct response is architectural rather than heroic.

That response is a normalization boundary. Every protocol gets an adapter whose only job is to turn that vendor's messages into one internal position message, and nothing downstream ever sees a vendor format. Whether you write adapters for the handful of devices your market actually uses or integrate an existing protocol server component, the boundary itself is the decision that matters, because it is what stops the onboarding of a new device model from becoming a change to the rules engine.

Design for garbage arriving, because it will. Duplicate packets are normal. Batches arriving out of order after a coverage gap are normal. Clock skew between the device and your server is normal. Coordinates in the wrong hemisphere, at the origin, or in the middle of an ocean all occur in production. Validation and deduplication belong at the ingestion edge, before anything downstream is permitted to trust a position.

Device strategies, and what each one makes your problem

Device class	Reliability	Unit cost	What becomes your problem
Wired hardware tracker	Highest	Highest	Installation appointments, warranties, SIM management, firmware variation across a fleet
Battery asset tracker	High while charged	Moderate	Battery replacement logistics and reporting cadence traded against battery life
Diagnostic port device	Good	Low	Vehicle compatibility variation, and devices that a driver can unplug in seconds
Driver smartphone	Lowest	None	Background execution limits, battery complaints, and a tracked party who can disable tracking
Customer-owned mixed devices	Varies	None to you	An open-ended protocol matrix that grows with every new customer you sign

The last column is the one that decides this. A device strategy is a set of ongoing operational obligations, and those obligations outlive the build by years.

The ingestion pipeline, and why the queue is load bearing

The shape that works is consistent across implementations. A set of protocol listeners terminates device connections and emits normalized position messages onto a queue. Separate consumers read from that queue: one updates a live position store keyed by device, one appends to history in batches, one feeds the rules engine. Nothing reads the device connection directly except the listener, and nothing writes to more than one store.

The queue is the single most consequential choice in this architecture, and its value is not throughput. It is decoupling and replay. When a mobile network event causes several thousand trackers to reconnect within a few seconds, each replaying its buffered positions, the ingestion edge sees a burst that may be two orders of magnitude above the steady state. With a queue, the burst is absorbed and processed at whatever rate the consumers manage. Without one, the burst reaches your database directly, and the outage that caused it becomes an outage of yours as well.

Replay is the second benefit and the one that pays for itself during incidents. When a consumer turns out to have had a bug for six hours, a queue with retained messages lets you fix the consumer and reprocess. Without retention, that data is gone, and in a system whose entire purpose is producing a defensible record of where vehicles were, losing six hours is a customer-facing problem rather than an engineering inconvenience.

One further separation is worth making explicit. The live store and the history store have opposite characteristics: the live store is small, written constantly in place, and read constantly, while history is enormous, written sequentially in batches, and read rarely. Putting both in one table serves neither well, and it is the arrangement almost every first implementation begins with.

The ingestion edge, specified

Connection handling

Concurrent connections

How many devices hold a connection simultaneously, and what happens at the limit. This sizes the listener tier and is frequently underestimated by an order of magnitude.

Reconnect burst capacity

The peak arrival rate the edge accepts without dropping, stated as a multiple of steady state rather than as a hope.

Authentication

How a device proves which device it is. Tracker protocols vary from strong identity to a plain serial number, and the weak ones need compensating controls.

Validation

Plausibility rules

Rejection of coordinates outside the operating region, implied speeds beyond physical possibility, and timestamps far from server time.

Deduplication

A stable identity per position so a replayed buffer does not double the mileage on a trip, which is the most common data quality complaint in this category.

Ordering

A defined policy for positions arriving out of sequence, since a buffered batch after a coverage gap arrives after newer live positions.

Storage tiers

Live positions

Keyed by device, overwritten in place, sized by concurrently active devices rather than total devices ever registered.

Full resolution history

Every accepted position, retained for a bounded operational window measured in weeks, partitioned by time so expiry drops whole partitions.

Downsampled history

Route shape preserved at far fewer points, retained for the analysis horizon measured in months.

Trip aggregates

Distance, duration, stops, idling and events per journey, retained indefinitely, because this is what reporting actually queries.

This is what a serious proposal for a tracking platform contains. Each row is a decision that will otherwise be made implicitly by whoever writes the listener, at three in the morning, during the first network event.

The storage arithmetic that surprises every buyer

This section exists because the calculation takes sixty seconds, changes the architecture, and is almost never performed before a design is committed. It is the cheapest risk reduction available in the entire project.

Take a modest fleet of a thousand vehicles. Report every ten seconds while moving, which is a common requirement when customers ask for a live map that feels live. That is six positions per minute, 360 per hour, and across a ten hour operating day about 3,600 positions per vehicle. Multiply by a thousand vehicles and the fleet produces roughly 3.6 million positions per day. Run the same fleet with tracking continuously rather than only during operating hours and it approaches 8.6 million per day. Over a year, at the lower figure, that is above a billion rows.

None of those numbers are large for purpose-built storage. All of them are fatal to a naive relational schema with several indexes, kept in one table, queried directly for reports. And the number people forget is the read cost: a report over three months of full resolution positions for a whole fleet is scanning hundreds of millions of rows to produce a figure that could have been maintained incrementally as an aggregate.

The standard answer is tiered retention, and it works because the questions people ask have different resolutions. Nobody asks for second-by-second detail from eight months ago. They ask for the total mileage of a vehicle last quarter, which is an aggregate, or for the exact route of one journey during a dispute, which is one trip at full resolution within a recent window. Design the tiers around those two real questions rather than around keeping everything in case somebody asks.

Report cadence deserves the same scrutiny as retention, because it multiplies everything. Adaptive reporting, meaning frequent updates while moving and sparse ones while stationary, typically cuts volume substantially with no loss the dispatcher can perceive, since a parked vehicle reporting every ten seconds is generating thousands of identical positions per day. That single change is often the difference between a viable storage budget and an uncomfortable one.

Position volume, worked through

Scenario	Positions per day	Per year	Comment
100 vehicles, 30s, 10h day	About 120,000	About 44 million	Comfortable for a conventional database with sensible partitioning
1,000 vehicles, 30s, 10h day	About 1.2 million	About 438 million	Needs partitioning and a retention policy from the start
1,000 vehicles, 10s, 10h day	About 3.6 million	About 1.3 billion	Purpose-built time series storage or aggressive tiering required
1,000 vehicles, 10s, continuous	About 8.6 million	About 3.1 billion	The figure a naive design accidentally chooses by tracking around the clock
Same fleet, adaptive cadence	About 2.1 million	About 767 million	Sparse reporting while stationary, with no perceptible loss to a dispatcher
Trip aggregates only	About 4,000	About 1.5 million	What reports should actually query, maintained incrementally as trips close

The arithmetic, not a benchmark. Substitute your own fleet size and cadence. The bottom two rows show why adaptive reporting is usually the first change worth making, and why per-trip aggregates are what reporting should read.

Map matching and trip segmentation, where perceived quality comes from

Two processing steps account for most of the difference between a tracking product that feels professional and one that feels like a prototype, and neither is visible in a demonstration because both operate on messy real data rather than on a clean test route.

The first is map matching, which snaps noisy positions onto the road network. Without it, a rendered track is recognizably spaghetti: it cuts corners, wanders off the carriageway, and occasionally crosses buildings. With it, the same data draws a route that looks like the journey the driver actually made. The commercial consequence is larger than the aesthetic one, because distance computed from a matched route is defensible while distance computed from raw fixes is systematically inflated by jitter, and mileage is what customers bill and audit against.

The second is trip segmentation, which converts a continuous position stream into the objects humans reason about: journeys, stops, and idling periods. This uses ignition state where the device provides it and dwell logic where it does not. It sounds mechanical and it is where a surprising amount of product judgment lives, because the definition of a stop is a business decision. Is thirty seconds at a traffic light a stop? Is four minutes outside a customer's premises a delivery? The thresholds have to be configurable per customer, because a courier fleet and a long-haul operator do not agree on any of them.

Both steps deserve the same fixture-based testing discipline as any other quality-critical processing. Recorded real journeys, replayed through the pipeline with expected distances and expected stop counts asserted, turn segmentation quality into a test suite instead of an opinion. This is the recurring theme our backend engineering team plans around: the invisible processing is where the product quality is, so it needs the strongest tests.

Processing decisions that decide whether the data is defensible

Do this

• Distance from the matched routeMileage derived after snapping to the road network, which is defensible when a customer audits it against their own records.
• Configurable stop thresholdsDwell time and ignition rules set per customer, because a courier fleet and a long-haul operator disagree about what a stop is and both are right.
• Segmentation tested on real journeysRecorded traces replayed with expected trip counts and distances asserted, so a threshold change cannot silently alter every historical report.
• Aggregates maintained as trips closePer-trip totals computed once when the journey ends, so reporting reads thousands of rows rather than hundreds of millions.

Not this

• Distance summed between raw fixesSystematically inflated by jitter, including for parked vehicles, which is the single most common source of a customer disputing your numbers.
• One hard-coded stop definitionA fixed threshold that suits the first customer and misrepresents every subsequent one, with no way to correct it per account.
• Segmentation verified by looking at a mapQuality assessed by eye on a few journeys, which cannot detect a regression and cannot be run in a build pipeline.
• Reports querying full resolution historyA monthly utilization report scanning a quarter of raw positions, which is slow at launch and impossible at scale.

Each right-hand item produces a system that works on a clean test route and generates support tickets on real journeys. The mileage row is the one that becomes a billing dispute.

Alert design, or how a working platform gets muted

Tracking data becomes operational value through rules: a vehicle entered or left an area, exceeded a speed threshold, idled beyond a limit, deviated from a route, moved outside working hours, or moved when it should not have moved at all. The rules engine evaluates incoming positions against the active rules for each device, which at fleet scale means spatially indexing the fence set rather than looping over every polygon for every position.

The engineering there is tractable. The product risk is not, and it is the most common way these platforms fail in daily use. A system that emails a dispatcher on every geofence event trains that dispatcher to ignore its email within about a month. After that, the platform is still ingesting perfectly, still evaluating rules correctly, still costing money, and delivering nothing, because the human at the end of the chain has stopped reading. Nobody files a defect for this, and it does not appear in any monitoring.

The mitigations are all design decisions rather than technology. Hysteresis and dwell confirmation on every fence, exactly as in any geofencing system, so a vehicle parked on a boundary cannot generate a stream of arrivals and departures. Severity tiers with genuinely different delivery channels, so that something requiring immediate action interrupts a person while something merely informational accumulates. Digest summaries for the informational tier. And per-recipient routing, so the alert about a night movement reaches whoever is actually on shift rather than the fleet manager's inbox at four in the morning.

The alerting configuration interface deserves to be treated as a first-class part of the product rather than an administrative screen, because it is where fleet managers spend their time once the novelty of the live map has worn off. A manager who can tune their own notification thresholds keeps using the system. A manager who has to raise a support request to change a speed threshold mutes the notifications instead.

Driver behavior scoring, covering harsh braking, acceleration, cornering and speeding, is a frequent requirement with a fairness obligation attached. Sensor-derived events need calibration per vehicle class, since a loaded truck and a small van do not produce comparable readings for the same driving, and drivers will challenge scores that affect their pay or standing. Keep the underlying evidence, meaning the track segment and the sensor trace, attached to every scored event, so a challenge can be answered with data rather than with an assertion.

The ladder that keeps alerts worth reading

1. 1

   Confirm before firingKills boundary flapping

   Hysteresis with a larger exit radius than entry, plus dwell time before an entry counts. A vehicle parked on a fence edge is the single largest source of pointless alerts in these systems.

2. 2

   Assign a severity honestlyThree tiers, not ten

   Something requiring action now, something worth knowing today, and something worth having in a report. If everything is urgent, the tiering has failed and the user will re-tier it themselves by ignoring you.

3. 3

   Route to the person on shiftPer-recipient rules

   A night movement alert reaches whoever is working, not the manager who is asleep. Alerts sent to people who cannot act on them are the fastest route to a muted channel.

4. 4

   Digest the informational tierOne message, many events

   A daily summary of idling, minor speed events and routine arrivals, which is read because it is one message rather than forty.

5. 5

   Let the manager tune it themselvesConfiguration is product

   Thresholds, recipients and channels editable without a support request, because a manager who cannot adjust the noise will remove it entirely instead.

6. 6

   Attach the evidenceEspecially for scoring

   Every alert and every behavior score links to the track segment and sensor data behind it, so a challenge is settled with data rather than with an argument about whether the system is trustworthy.

Each rung removes noise before a human is interrupted. Skipping any of them tends to produce the same outcome, which is a platform whose notifications are filtered into a folder nobody opens.

A build plan sequenced along the data flow

Sequence the work in the direction the data travels, because each stage can be verified with real devices before the next depends on it. The first phase supports one or two device models end to end: listener, normalization, live store, history, and a live map, running with a genuine pilot fleet rather than a simulator. That is a shippable product for a small operator and it produces the feedback that keeps everything after it honest.

The second phase adds the rules engine, alerts, and the specific reports the pilot users asked for, which will differ from the reports you expected. The third adds more protocols, driver behavior scoring, maintenance triggers and the outbound API. Keeping these as separate phases matters because each one is independently valuable, and because the pilot fleet between phases is the only reliable source of information about which features are actually used.

Two commercial decisions belong at the start rather than in the middle. The device strategy: bundling hardware makes installation, warranties and connectivity management your business, while supporting customer-owned devices makes the protocol matrix your business, and both are ongoing costs rather than project costs. And mapping economics: commercial map, matching and geocoding services price per request, and a tracking platform makes a great many requests, so the choice between commercial services and self-hosted open data is a meaningful operating budget line that deserves modeling at design time rather than after the first invoice.

A final note on the reporting surface. Feature lists in this market are long, and daily usage concentrates into a short list: the live map with fleet status, trip history with playback for disputes, usable geofence management, scheduled reports, maintenance triggers, and an API. Maintenance triggers driven by odometer and engine hours are frequently the cheapest return in the whole product, because a missed service is expensive and the reminder is trivial to compute. And in business-to-business tracking the API often is the product, since the customer wants positions and events inside their own transport or resource planning systems rather than in another portal. If the tracked entities are phones rather than vehicles, the client-side engineering in our guide to building a geolocation app is the complementary read.

A phased build with a pilot fleet between each stage

1. Device selection and arithmeticWeeks 1 to 2

   Choose one or two device models, obtain them, read the traffic they actually emit, and complete the storage and cadence arithmetic for the target fleet size.

   Done when Real packets captured from real hardware, and a written volume model with a retention tier plan.

2. Pipeline and live mapWeeks 3 to 9

   Listener, normalization, validation, queue, live position store, tiered history, and a live map with fleet status.

   Done when A pilot fleet visible and correct for a full week, including through at least one network disruption, with mileage matching the vehicles' own odometers.

3. Processing and reportsWeeks 8 to 13

   Map matching, trip segmentation with configurable thresholds, per-trip aggregates, and the reports the pilot users requested rather than the ones you planned.

   Done when Trip counts and distances asserted against recorded journeys in automated tests, and a report a manager reads without asking for an explanation.

4. Rules and alertsWeeks 12 to 17

   Geofence management, rule evaluation at fleet scale, severity tiers, digests, per-recipient routing, and self-service configuration.

   Done when Pilot users still reading the alerts after a month, which is the only test of this phase that means anything.

5. Scale outWeeks 16 to 22

   Additional protocols, driver behavior scoring with attached evidence, maintenance triggers, and the outbound API.

   Done when A second device model onboarded without changes outside its adapter, which proves the normalization boundary actually holds.

Indicative spans for a small dedicated team, not a quotation. The pilot fleet in phase one is what makes the rest of the plan trustworthy, because real devices behave differently from the documentation in ways nobody can predict.

Tracking people, not just vehicles, and the line that has to be drawn explicitly

A telematics platform records where a vehicle went, and a vehicle is almost always driven by an identifiable person. That makes the dataset a record of an employee's movements over time, which is among the more sensitive categories of workplace data and is treated as such in most jurisdictions. Fleet platforms are routinely designed as if the subject were the vehicle, and the gap between that assumption and the legal reality is where these projects encounter their most expensive surprises.

The practical questions are not difficult, but they must be answered before the schema is written rather than after the first complaint. Is location recorded outside working hours, and if the vehicle is taken home, what happens between the end of one shift and the start of the next? Who inside the organization can view an individual driver's history as opposed to aggregate fleet performance, and is that access recorded? How long is the full resolution trace retained, given that operational need is measured in days while accumulated data represents indefinite risk? Can a driver see the data held about them, which several regimes require, and is there a route to challenge a behavior score that affects their pay?

The engineering that follows from these answers is mostly straightforward and needs to exist from the first release. A shift boundary in the data model so that off duty periods are either not recorded or clearly separated. Role separation between operational dispatch, which needs live positions, and management reporting, which needs aggregates and rarely needs an individual trace. An access log on individual driver history views, because unlogged access is indistinguishable from surveillance to the person being tracked. And a retention schedule implemented as a scheduled job rather than an intention, with full resolution traces expiring in days, downsampled traces in months and aggregates retained indefinitely.

There is a delivery argument for this that is separate from the legal one and often more persuasive internally. Driver acceptance determines whether a telematics deployment works, because drivers who experience the system as surveillance will find ways to defeat it, and a tracker that is unplugged or shielded produces exactly the gaps that make the whole dataset untrustworthy. Deployments that explain what is recorded, restrict it to working hours, show drivers their own data and use scoring for coaching rather than punishment measurably survive. Deployments that arrive unannounced generate resistance, and the resistance shows up as data quality problems that look like device faults.

Three datasets that get commingled, and why they should not be

Dataset	Operational need	Retention	Who should see it
Live position	Dispatch and customer arrival estimates, needed for seconds to minutes	Not durable, held in memory or a short lived cache	Dispatch, and the customer for their own delivery only
Full resolution trace	Dispute resolution, incident reconstruction and debugging	Days, expired by a scheduled job rather than by intention	Operations on demand, with the access logged
Downsampled trace	Route analysis and historical comparison	Months, at reduced precision and frequency	Operations and analysis, individual identity often unnecessary
Trip and event records	Utilization, billing, maintenance triggers and reporting	Years, as a small structured artifact rather than raw fixes	Management reporting, mostly in aggregate
Behavior scores	Coaching, and safety programs	Months, with the underlying evidence attached while it exists	The driver themselves, their direct manager, and nobody else by default

The single most consequential design decision in a telematics data model. Operational need, retention pressure and sensitivity all differ across these three, and one table holding all of them satisfies none of the requirements properly.

Decisions to make before the schema is written

• Define the shift boundary in the data modelRecording location outside working hours is the most common single complaint and in some jurisdictions the most straightforward violation. Either do not record it, or store it separately with distinct access rules and a shorter retention.
• Separate dispatch access from management reportingDispatch needs live positions and no history. Management needs aggregates and rarely needs an individual trace. Collapsing these into one permission is what turns a fleet tool into a surveillance tool by accident.
• Log every view of an individual driver historyWho looked, at whom, when and for what stated reason. Unlogged access is indistinguishable from surveillance from the driver's perspective, and the log is what makes the policy credible.
• Implement retention as a scheduled job on day oneA retention policy that exists only as a document is not a retention policy. Write the expiry job in the same sprint as the ingestion path, because it is trivial then and touches years of accumulated data later.
• Build the driver facing viewLet drivers see their own trips and scores. Several regimes require it, it removes most of the objection to the system, and it surfaces data quality problems from the people best placed to notice them.
• Attach evidence to every behavior scoreA score without the underlying event is unchallengeable, which makes it unusable in any process affecting pay or employment, and correctly so.
• Write the resolution for the retention conflictWhere an authority requires multi year trip records and privacy law requires location minimization, keep the small structured trip record long and expire the raw trace early. Decide this explicitly and write it down, because it will be asked about.

Each of these is cheap to implement at the start and expensive to retrofit, because retrofitting means separating records that have already been written to one table for months.

Frequently asked questions

If you are commissioning a tracking platform for a fleet, a rental business or a logistics product and want the pipeline priced honestly, talk to AgileTech, a software engineering partner in Vietnam that builds it from the protocol adapter to the dispatcher screen.