Ask a motor insurer how much telematics data they collect: billions of GPS points, accelerometer traces, trip records, harsh-braking events. Ask what decisions it changes: a renewal discount and a dashboard nobody opens.
They built the expensive part — the collection pipeline — and use maybe 5% of it. As a data-engineering problem, that's fascinating, so let's look at why the other 95% never turns into a decision.
The pipes end in a dashboard, not a decision
The typical architecture: devices → ingestion → time-series store → BI dashboard. That last hop is where value dies. A dashboard is a human-in-the-loop bottleneck; it can only surface what someone thought to chart. The high-value uses of telematics are automated joins against other data at decision time, and a dashboard can't do that.
The highest-value use almost nobody ships
A claim comes in: "rear-ended at 8pm on the bypass." Your telematics data knows where that vehicle actually was at 8pm. That's not fraud detection by fuzzy inference — it's ground truth you already own, sitting one join away from the claims system and almost never wired up.
Why isn't it? Because the telematics store and the claims store are different systems, different teams, different latency assumptions, and nobody built the join. The data problem isn't collection. It's integration at the moment a decision is made.
The engineering reasons it stalls
- Volume framing. Billions of points sounds like a big-data problem, so teams over-invest in storage/throughput and under-invest in the joins that create value. Most decisions need an aggregate or a point-in-time lookup, not the full firehose.
- Schema-on-never. Raw telemetry lands in a lake and nobody defines the decision-ready features (trip risk score, location-at-timestamp, exposure hours). Without that layer, every use case starts from raw points and dies in scoping.
- Latency mismatch. Fraud/claims validation wants a point-in-time answer in seconds; the telematics pipeline was tuned for cheap batch ingestion. The two never meet.
What to build instead
-
A decision-ready feature layer over the raw telemetry:
location_at(vehicle_id, ts),trip_risk(trip_id),exposure_hours(policy_id, window). Compute once, reuse everywhere. - A point-in-time lookup API the claims and fraud systems can call synchronously. This single capability unlocks the "where was the car" use case.
- Stop treating it as big data. Treat it as decision data: what question does this answer, and what does it need to join against?
The insurers who win with telematics won't be the ones who collected the most points. They'll be the ones whose pipes end in a decision instead of a chart.
Full write-up:
Telematics and IoT: The Data Insurers Collect and Never Use →
Part of an ongoing series on the data foundation under insurance AI from IntelliBooks.
If you've shipped the point-in-time-location join against claims, I'd love to hear how you handled the latency mismatch.
Top comments (0)