Custom eco-driving analytics with Navixy DataHub

When you manage hundreds of vehicles, “standard safety scores” don’t tell the full story. Operations track fuel loss, compliance needs audits, and finance wants defensible numbers. Read how our customer in LATAM built in Navixy DataHub a custom driver behavior report that met their business needs and delivered measurable results.

Key takeaways

Turn telematics into business evidence. Correlate driver behavior with costs, maintenance, and insurance KPIs using SQL-ready, auditable data.

Build custom eco-driving logic. Define thresholds and scoring formulas that match your goals.

Deliver analytics faster. Stream telematics data directly to BI tools.

Engage drivers with transparent feedback. Use fair scoring to cut fuel, accident, and maintenance costs.

Case study: how one logistics fleet turned telematics data into a driver improvement engine

Let’s be honest — most eco-driving reports out there are boring. They list violations, assign some arbitrary points, and call it a day. But when you’re managing 1,200 trucks burning through thousands of liters of diesel a week, that kind of reporting doesn’t move the needle. You need analytics that explain behavior, not just punish it.

That was the revelation for a regional logistics provider operating in the LATAM region. Their management team wanted to receive a system that linked driver performance directly to fuel costs, maintenance schedules, and insurance exposure.

The starting point: Too much data, too little clarity

Like most large fleets, this logistics provider had more data than they could ever use — GPS pings, CAN-bus metrics, temperature logs, and driver IDs. Yet, their analytics tools could barely answer these questions:

Which drivers consistently exceeded speed thresholds in urban zones?
How do harsh braking events correlate with increased maintenance costs?
And the big one — are our “eco-driving scores” actually linked to savings, or are they just numbers on a dashboard?

The IT team tried to piece things together through APIs and CSV exports. The result: late-night Excel marathons, inconsistent thresholds, and dashboards that broke every time an update hit the telematics platform.

“We had five different ‘official’ reports for fuel economy, and none of them matched,” admitted their operations director. “Our BI manager was becoming a translator.”

Enter Navixy DataHub: a data foundation for real analytics

By connecting telematics feeds to Navixy DataHub, the team gained direct SQL access to their entire dataset (speed, RPM, heading, and timestamps), all organized in a structured DataHub Bronze layer. No APIs, no polling scripts, and no nightly batch jobs.

This new data foundation allowed them to build a custom eco-driving model that reflected their corporate priorities:

Overspeeding thresholds varied by region and road type.
Penalty weights were based on cost impact, not guesswork.
Scores were normalized per 100 km, so short-haul and long-haul drivers could be compared fairly.

Finally, they stopped fitting their business into the software and made the software fit their business. The first live dashboard went up within a week. Within a month, they had performance trends across all 1,200 drivers — not just alerts, but context: which routes, times, or conditions triggered risky behavior.

The multidimensional business impact

The biggest win wasn’t just lower fuel use (though they did cut consumption by 11% in the first three months). The real shift came from driver engagement. When drivers saw that the scoring logic made sense and that the penalties reflected actual risk and cost, they started competing to improve.

In terms of numbers, maintenance costs dropped by 8%, accident claims went down 15%, and their insurer took notice. The company is now negotiating with their insurance company for a usage-based premium model built on those same eco-driving scores.

Actionable checklist from a LATAM logistics service provider

These are the exact algorithm the Navixy customer, the logistics service provider in LATAM, followed to get the most out of their eco-driving report and turn driver behavior monitoring into measurable business improvement:

Identify the primary KPI: fuel cost control, risk reduction, or compliance.
Draft violation bands and penalty weights with ops and finance.
Build event detection SQL for speeding, harsh braking/acceleration, and sharp turns.
Normalize scores (per 100 km/hour) to compare apples to apples.
Publish detailed and summary tables; connect them to a BI tool via PostgreSQL.
Schedule reviews; adjust weights as policies and networks evolve.

Use this checklist as a starting template to build your own driver behavior monitoring report that reflects your data, your priorities, and your fleet’s operational reality.

Practical guide: how to build a custom eco-driving report in Navixy DataHub

With Navixy DataHub, creating an eco-driving report is not about filling in a template. It’s about defining your own logic without API limitations and nightly exports. Let’s walk through how this works in practice.

Step 1. Define the inputs

The raw data comes directly from telematics devices: speed, location, heading and timestamps.

Step 2. Configure thresholds and penalties

Set business-specific thresholds and penalty weights for driving violations:

Overspeeding: points for ranges like +0–20 km/h, +20–40 km/h, etc. (can be banded by road type/region)
Harsh braking: deceleration beyond a set threshold.
Harsh acceleration: rapid acceleration above a chosen limit.
Sharp turns: sudden heading changes at higher speeds.

Each event can be assigned a penalty score that reflects business priorities. For example, an insurer may assign heavier penalties to speeding, while a fleet operator may focus more on harsh braking that increases maintenance costs. Penalty weights reflect cost or risk impact. Finance and operations can co-own the table of penalties so it aligns with budgets and policies.

Step 3. Event detection logic (under the hood)

Once areas and their corresponding thresholds are defined, create the logic that will be applied. Turning this into actionable insight requires two layers of processing: event detection and aggregation.

3.1. Collecting the right signals

From the Bronze layer of Navixy DataHub, pull:

Speed (to detect overspeeding and calculate accelerations).
Timestamps (to measure change over time).
Heading (for sharp turn detection).
Distance (for score normalization per 100 km).

3.2. Detecting driving events

Each type of violation is identified by comparing live values with business-defined thresholds. Implement detection rules with SQL (or Python notebooks that read from SQL):

Detect speeding events
While iterating the time series, whenever speed > base limit, we open (or continue) a speeding “event”. When speed drops back to/below the limit, we close the event and compute:

Duration (short bursts ≤ 60 seconds are ignored as grace),
Peak over‑limit during the event.

The penalty for that event is a fixed amount based solely on how far over the limit the driver peaked:

0–20 km/h → speed_range1 points
20–40 km/h → speed_range2 points
40–60 km/h → speed_range3 points
60 km/h → speed_range4 points

def speeding_points(max_over, penalties):
if max_over < 20: return penalties['speed_range1']
if max_over < 40: return penalties['speed_range2']
if max_over < 60: return penalties['speed_range3']
return penalties['speed_range4']

Why peak and not duration? It simplifies policy and makes review easier: one clear penalty per incident, instead of “per‑minute” math.

Detect harsh maneuvers (from acceleration)

Estimate acceleration by comparing back‑to‑back speeds:

Convert km/h to m/s and divide the change by the time between points.
If deceleration is below the braking threshold (e.g., −3.5 m/s²) and the vehicle was moving (≥ 10 km/h), add harsh_brake points.
If acceleration is above the acceleration threshold (e.g., +3.0 m/s²) and speed was ≥ 10 km/h, add harsh_accel points.

def mps(kmh):
    return kmh / 3.6

def detect_harsh_maneuvers(speeds, timestamps, decel_threshold=-3.5, accel_threshold=3.0, min_speed=10):
    points = {'harsh_brake': 0, 'harsh_accel': 0}
    for i in range(1, len(speeds)):
        prev_speed, curr_speed = speeds[i-1], speeds[i]
        dt_seconds = timestamps[i] - timestamps[i-1]

        # skip if time delta is too small or speed is too low
        if dt_seconds <= 0.1 or prev_speed < min_speed:
            continue

        acc = (mps(curr_speed) - mps(prev_speed)) / dt_seconds

        if acc < decel_threshold:
            points['harsh_brake'] += 1
        elif acc > accel_threshold:
            points['harsh_accel'] += 1

    return points

Detect sharp turns (from heading changes)

If there are two consecutive GPS points, we estimate the bearing (heading). A sharp turn is when the change in heading between steps is above your threshold (e.g., 150°) and the vehicle is moving at least a minimum speed (e.g., 30 km/h). Each detection adds harsh_turn points.

from math import sin, cos, radians, atan2, degrees

def bearing_deg(lat1, lon1, lat2, lon2):
    phi1, phi2 = radians(lat1), radians(lat2)
    d_lon = radians(lon2 - lon1)
    y = sin(d_lon) * cos(phi2)
    x = cos(phi1) * sin(phi2) - sin(phi1) * cos(phi2) * cos(d_lon)
    return (degrees(atan2(y, x)) + 360) % 360

def delta_heading(h1, h2):
    return abs((h2 - h1 + 180) % 360 - 180)

def detect_sharp_turns(gps_points, speed_threshold=30, heading_threshold=150):
    sharp_turns = []
    for i in range(1, len(gps_points)):
        lat1, lon1, t1 = gps_points[i-1]
        lat2, lon2, t2 = gps_points[i]
        h1 = bearing_deg(lat1, lon1, lat2, lon2)
        if i < len(gps_points) - 1:
            lat3, lon3, t3 = gps_points[i+1]
            h2 = bearing_deg(lat2, lon2, lat3, lon3)
            delta_h = delta_heading(h1, h2)
            speed = calculate_speed(lat1, lon1, lat2, lon2, t1, t2)  # implement this
            if delta_h > heading_threshold and speed >= speed_threshold:
                sharp_turns.append((lat2, lon2, t2, delta_h))
    return sharp_turns

3.3. Aggregating into scores

A single harsh braking event means little by itself. But when aggregated across time, distance, or drivers, it reveals patterns:

Per driver: to compare performance and highlight coaching needs.
Per fleet: to evaluate risk exposure and operating costs.
Per 100 km: to normalize across different vehicle usage levels.

Score formula:

points_per_norm = (total_points / distance_km) * norm_distance # e.g., per 100 km 
score = max(0, max_score - points_per_norm) # clamp at zero

Example:
If a van drove 250 km and collected 8 points, with norm_distance = 100 and max_score = 100, then points_per_norm = (8/250)*100 = 3.2 → score = 96.8. If a van drove 250 km and collected 8 points, with norm_distance = 100 and max_score = 100, then points_per_norm = (8/250)*100 = 3.2 → score = 96.8.

The report engine summarizes all violations into a scoring model. For example, a driver may accumulate 45 penalty points per 100 km, while another averages only 12. These results feed directly into business KPIs: insurance risk models, maintenance forecasting, or sustainability goals.

Step 4. Generate the report

Aggregate penalties by driver/vehicle/route and normalize data to compare fairly across duty cycles. The system outputs two layers of results:

Summary table: total violations per type, cumulative penalty points, and normalized scores (e.g., points per 100 km).
Detailed table: each violation with its timestamp, type, and penalty. This table can be used for auditability, then visualized in your BI tool of choice via PostgreSQL connectors.

This dual-view allows both tactical oversight (who did what, and when) and strategic insight (aggregate scores across vehicles or time periods).

Wrapping up: turn driver behavior monitoring into a data strategy

Eco-driving is often treated as an add-on, a checkbox feature. But as you learned from the case study, when you control the data logic with the help of Navixy DataHub, it becomes a strategic tool. It won’t turn every driver into a saint overnight. But when data is accurate, transparent, and business-aligned, improvement stops being a lecture and starts being a culture. That’s what Navixy’s partner in LATAM discovered, and it all started with a clear idea of what really mattered.

Want to explore the difference between pre-packaged dashboards and decision-ready analytics? Contact Sales to enable capabilities of Navixy DataHub for your business.

How to build an eco-driving report in DataHub for fleet behavior monitoring

Author