The GPS Illusion
Most fleet managers believe they have "GPS tracking." They have a screen showing dots moving on a map. They can see where each vehicle is right now. When a customer calls asking where their delivery is, they can give an answer.
That's not fleet management. That's a very expensive vehicle locator.
Real fleet management means using the data your GPS devices generate to answer questions like: Why did fuel costs increase 12% last month? Which drivers are creating the most vehicle wear? Which routes are consistently running 40 minutes late? Which vehicles are spending 3 hours a day idling?
A 50-vehicle fleet with GPS devices generates approximately 720,000 location data points per day (one ping every 6 seconds per vehicle). Almost none of this data is being used to make decisions. This guide explains how to build the analytics layer that changes that.
Understanding What Your GPS Data Actually Contains
A GPS ping is more than a location. Modern telematics devices transmit:
- •Position: Latitude, longitude, altitude
- •Speed: Current speed in km/h
- •Heading: Direction of travel (0–360 degrees)
- •Ignition status: On or off
- •Engine RPM: From OBD-II port (if connected)
- •Fuel level: From OBD-II port (if connected)
- •Odometer: Cumulative distance
- •Timestamp: UTC timestamp of the reading
- •Signal quality: GPS accuracy indicator
From this raw data, you can derive an enormous amount of operational intelligence - but only if you build the right processing layer.
The Five Analytics That Drive Real Savings
1. Idle Time Analysis
Idle time - engine running, vehicle stationary - is one of the biggest hidden costs in fleet operations. A diesel engine idling consumes 0.8–1.2 litres per hour. For a 50-vehicle fleet where each vehicle idles an average of 2 hours per day, that's 80–120 litres of fuel wasted daily. At ₹90/litre, that's ₹7,200–₹10,800 per day, or ₹2.6–₹3.9 lakhs per month.
How to calculate idle time from GPS data:
An idle event is defined as: ignition ON + speed = 0 + duration > threshold (typically 5 minutes to filter out traffic stops).
For each vehicle, for each day:
idle_events = GPS pings where:
- ignition_status = ON
- speed = 0
- consecutive pings with same condition > 5 minutes
idle_time = sum of all idle_event durations
idle_fuel_cost = idle_time_hours × fuel_consumption_rate × fuel_priceWhat to do with this data:
- •Rank drivers by idle time. The top 10% of idlers are your intervention targets.
- •Identify locations where idling is highest. Loading docks, customer sites, and traffic hotspots show up clearly.
- •Set idle time alerts: if a vehicle has been idling for more than 15 minutes, send an alert to the driver's phone.
- •Track idle time trends over time. After driver coaching, idle time should decrease.
2. Harsh Driving Detection
Harsh acceleration, harsh braking, and sharp cornering are the three driving behaviours that most damage vehicles and increase fuel consumption. They're also detectable from GPS data.
Harsh acceleration: Speed increase of more than 10 km/h in 3 seconds.
Harsh braking: Speed decrease of more than 15 km/h in 3 seconds.
Sharp cornering: Heading change of more than 45 degrees in 3 seconds while speed > 30 km/h.
Each harsh event is a data point. Aggregate them by driver and you have a driver behaviour score. Drivers with high harsh event rates are:
- •Consuming 10–15% more fuel than smooth drivers
- •Creating 20–30% more brake and tyre wear
- •Creating higher accident risk
Driver scoring model:
driver_score = 100
- (harsh_acceleration_events × 2)
- (harsh_braking_events × 3)
- (sharp_cornering_events × 1)
- (speeding_events × 5)
Normalised per 100 km driven to account for different route lengths.Share driver scores with drivers weekly. Drivers who see their score improve their behaviour - this is well-documented in fleet management research. Gamification (leaderboards, monthly awards for top-scoring drivers) amplifies the effect.
3. Route Deviation and Unauthorised Use Detection
Geofencing - defining virtual boundaries on a map - enables two powerful use cases:
Route adherence: Define the expected route for each trip. Alert when a vehicle deviates more than 2 km from the expected route. Route deviations add distance, fuel cost, and delivery time. They can also indicate unauthorised detours.
Geofence entry/exit alerts: Define geofences around customer sites, depots, and restricted areas. Get an alert when a vehicle enters or exits a geofence. This gives you automatic arrival and departure times without drivers needing to check in manually.
After-hours use detection: Define operating hours for each vehicle. Any ignition-on event outside operating hours triggers an alert. This catches unauthorised vehicle use, which is more common than most fleet managers realise.
Implementation approach:
Geofence checking is computationally expensive if done naively (checking every ping against every geofence). The efficient approach uses spatial indexing:
- 1Store geofences as polygons in a spatial database (PostGIS is the standard choice)
- 2For each incoming GPS ping, use a spatial query to check if the point is inside any geofence
- 3Compare with the previous ping's geofence status to detect entry/exit events
- 4Publish entry/exit events to an alert queue
With PostGIS spatial indexing, this query runs in milliseconds even with thousands of geofences.
4. Predictive Maintenance Triggers
GPS data combined with OBD-II data enables predictive maintenance - servicing vehicles based on actual usage rather than calendar schedules.
Odometer-based triggers: Service reminders based on actual kilometres driven, not estimated. When a vehicle crosses 10,000 km since last service, trigger a service alert.
Engine hours: For vehicles that do a lot of idling (construction equipment, refrigerated trucks), engine hours are a better maintenance trigger than odometer. Track engine hours from ignition-on/off events.
Driving behaviour correlation: Vehicles driven harshly need more frequent brake and tyre inspections. Flag vehicles with high harsh braking scores for more frequent brake checks.
Fault code monitoring: OBD-II connected devices transmit engine fault codes (DTCs). When a fault code appears, create a maintenance ticket automatically. Catching fault codes early prevents minor issues from becoming major breakdowns.
5. Fuel Efficiency Analysis
Fuel is typically 30–40% of fleet operating costs. GPS data enables precise fuel efficiency analysis:
Actual vs. expected fuel consumption: Compare actual fuel fill-ups (from fuel cards or manual entry) against GPS-calculated distance. Significant discrepancies indicate fuel theft or a vehicle with a mechanical problem.
Route efficiency scoring: For routes that are driven repeatedly, calculate the average fuel consumption per km. Routes with consistently high fuel consumption may have avoidable congestion, excessive idling, or gradient issues.
Load vs. fuel correlation: For trucks with load sensors, correlate load weight with fuel consumption. This helps optimise load planning to maximise fuel efficiency.
Building the Analytics Dashboard
The analytics are only valuable if they're presented in a way that drives action. Here's what the dashboard should show:
Fleet overview (real-time):
- •Map with all vehicles, colour-coded by status (moving, idle, stopped, offline)
- •Today's total distance, fuel consumed, and idle time
- •Active alerts (speeding, geofence violations, harsh driving)
Driver performance (weekly):
- •Driver scorecard ranked by score
- •Trend chart showing score improvement/decline over 8 weeks
- •Top 3 improvement areas for each driver
Vehicle health (ongoing):
- •Vehicles due for service (by odometer or engine hours)
- •Open fault codes
- •Vehicles with abnormal fuel consumption
Cost analytics (monthly):
- •Fuel cost per km by vehicle and driver
- •Idle fuel waste in rupees
- •Estimated savings from behaviour improvement
The Data Pipeline Architecture
Processing 720,000 GPS pings per day requires a proper data pipeline:
Ingestion: GPS devices send data to an MQTT broker (Mosquitto is the standard open-source choice). MQTT is designed for IoT devices - it's lightweight, handles unreliable connections gracefully, and supports thousands of concurrent device connections.
Stream processing: A stream processor (Apache Kafka + Kafka Streams, or a simpler Node.js consumer for smaller fleets) consumes messages from the MQTT broker, applies business logic (idle detection, harsh driving detection, geofence checking), and writes events to the database.
Storage: Raw GPS pings go to a time-series database (TimescaleDB, which is PostgreSQL with time-series extensions, is excellent for this). Derived events (idle events, harsh driving events, geofence events) go to a standard relational database.
API layer: A REST API serves the dashboard and mobile app. Expensive aggregation queries (monthly fuel analysis, driver scores) are pre-computed and cached.
What 6 Months of Proper Analytics Delivers
For a 50-vehicle fleet:
| Metric | Before | After 6 Months |
|---|---|---|
| Monthly fuel cost | ₹8.5L | ₹6.8L |
| Idle time per vehicle/day | 2.1 hours | 0.8 hours |
| Harsh driving events/100km | 12 | 4 |
| Unplanned breakdowns/month | 6 | 2 |
| On-time delivery rate | 72% | 88% |
The fuel savings alone (₹1.7L/month) typically pay for the entire fleet management system within 3–4 months.
See how IdeaSprout Fleet Management turns GPS data into savings →