Home Author
Author

Mark Delaney

Mark writes about what usage-based insurance programmes actually measure: phone sensors, plug-in devices, braking thresholds, speed bands, and the raw data behind a driving score. He reads app permissions and program disclosures closely, and lays out how a metric is defined before discussing what a given score might mean for a driver's rate.

a map view with a highlighted driving route on a phone screen
What Gets Measured

Does Your Insurer Know Your Exact Location or Just Your Driving Style?

by Mark Delaney
written by Mark Delaney

How GPS data is used in scoring models

Every usage-based insurance program starts with a phone sensor package or a plug-in device that records motion. GPS is one input among several, alongside the accelerometer, gyroscope, and sometimes a connection to the vehicle’s onboard diagnostics port. The GPS chip’s main job is to establish speed and location at a point in time, which the scoring engine then uses to infer two things: how fast the vehicle was going relative to the posted limit on that road, and what kind of road it was.

Road type matters because braking hard on a highway on-ramp is scored differently than braking hard in a school zone. To make that distinction, the software has to know roughly where the car is, which means it is cross-referencing GPS coordinates against a mapping database in the background. This is the main reason location data enters the scoring model at all: not to build a diary of your day, but to give context to speed, braking, and cornering events so the algorithm isn’t penalizing a driver equally for two very different situations that look the same on an accelerometer graph.

Time-of-day driving, which several programs weight heavily, is also derived from the same GPS timestamp. Late-night and early-morning trips are statistically associated with higher claim rates in the aggregate, so a program that scores “hard braking events” will often also be scoring “percentage of miles driven between certain overnight hours.” Both draw from the same underlying stream of GPS pings; the insurer isn’t necessarily running a second, separate location-tracking process to get the time-of-day figure.

Distracted-driving inferences—phone handling scores in particular—are a partial exception. Some programs use motion sensors and phone-screen activity together, and GPS is used mainly to confirm the phone was actually inside a moving vehicle rather than, say, being used on a train or as a passenger. In that context, location is a corroborating signal rather than the primary measurement.

Whether route and destination are stored or discarded

This is where the answer genuinely depends on the specific program, and it’s worth reading the terms rather than assuming. Broadly, there are three patterns in the market:

  • Aggregated only: The app calculates speed, braking, and road-type context on the device or in a short-lived server process, produces a per-trip score, and does not retain a plottable route history for the customer or, in principle, for the insurer’s long-term systems.
  • Route retained, viewable to the driver: Many consumer-facing apps show you a map of each trip, complete with the streets you drove and where hard-braking icons appeared. If the app can show you that map, the underlying route data exists somewhere in the insurer’s systems, at least for a retention period defined in the privacy policy.
  • Retained for claims and fraud review: Some insurers explicitly reserve the right to keep trip-level location history for a longer window specifically so it can be referenced if a policyholder later files a claim connected to that trip window, or if there’s a dispute about whether a vehicle was where the policyholder said it was.

The practical point for a driver evaluating a program is that “we score your driving” and “we retain a map of everywhere you drove” are not the same commitment, and a company can do the first without doing the second — but plenty do both. The only reliable way to know which applies to a specific program is the privacy notice or data disclosure section of that insurer’s telematics terms, not the marketing page for the app. Look specifically for language about retention period, whether raw GPS traces are kept versus only derived scores, and whether third parties (mapping vendors, reinsurers, data processors) receive the location stream or only the summary score.

Destination — as opposed to route — is a narrower question. Knowing that a trip ended at a specific address is a different level of granularity than knowing a car passed through a given intersection at speed. Some programs deliberately truncate the start and end points of a trip, sometimes called “geofencing” or “endpoint fuzzing,” so the exact home or workplace address isn’t precisely resolved in what’s stored, while the middle of the route is captured at full resolution for scoring purposes. Whether an individual program does this, and how much fuzzing is applied, again varies and is usually described in the technical FAQ rather than the app’s main marketing copy.

Questions worth asking before enrolling

  • Does the privacy policy distinguish between “location data used for scoring” and “location data retained for other purposes”?
  • Is there a stated retention period, and does it differ for active drivers versus the period after a policy ends?
  • Can you request an export or deletion of your trip history, and does that affect your discount or score history?
  • Is any location data shared with data brokers, marketing partners, or affiliated companies, as opposed to being used internally for underwriting and claims?

What insurers say they use location data for

Insurers that run telematics programs typically describe location data serving four purposes, and it’s useful to separate them because they carry different implications for a driver:

Scoring and discount calculation. This is the purpose disclosed most prominently, because it’s the value proposition of the program. Speed relative to road type, time-of-day exposure, and sometimes route familiarity (a driver who takes the same commute daily versus one with highly variable routes) feed into a behavior score that maps to a discount tier or a rate adjustment at renewal.

Trip verification for claims handling. If a policyholder reports a collision, an insurer with telematics data for that vehicle may reference the trip log for that time window as one input among several — alongside the police report, photos, and statements — when assessing what happened. This is presented as a claims-support tool rather than a surveillance function, though it functions as both.

Fraud and misrepresentation checks. Underwriting sometimes asks where a vehicle is principally garaged and how it’s typically used (commuting, business, pleasure), because that affects the base rate independent of telematics. Location data from the monitoring app can be used to check that actual driving patterns are roughly consistent with what was disclosed at underwriting — for instance, a vehicle rated as low-mileage personal use that shows extensive weekday commuting into a dense urban core might prompt a review at renewal.

Product development and aggregate research. Insurers and the vendors who build telematics platforms use de-identified, aggregated location and driving data to refine risk models — which intersections generate disproportionate hard-braking events, which road types correlate with claim severity, and so on. This use is typically described as aggregated and stripped of individual identifiers, but the precise de-identification standard is set by the company’s own policy and isn’t standardized across the industry, so “aggregated” doesn’t mean identical things everywhere.

What insurers generally do not advertise as a stated purpose is real-time location sharing with unrelated third parties for marketing, or continuous tracking outside of active trips. If a program’s terms describe always-on background location collection rather than trip-triggered collection, that’s a meaningfully different design and worth noting specifically, since it changes both battery impact and the volume of location data generated regardless of whether you’re driving.

Where this varies by insurer and by state disclosure rules

Two layers of variation stack on top of each other, and it’s easy to conflate them.

The first is simply product design. Because telematics programs are built by different insurers and different technology vendors, the sensor mix, the scoring weight given to location-derived context versus raw motion data, and the data retention architecture are all company decisions. A driver comparing two programs side by side may find one relies heavily on phone GPS with light accelerometer input, while another leans on a plug-in OBD-II device that captures vehicle diagnostics with GPS as a secondary layer. Neither approach is standard across the industry, and marketing materials rarely spell out the technical architecture in enough detail to compare programs directly — that detail usually lives in the terms of service or a technical support page.

The second layer is regulatory. Insurance is regulated at the state level in the US, and states differ in what they require insurers to disclose about data collection, how long consent for monitoring lasts, and what rights a policyholder has to access or request deletion of data collected about them. Some states have broader consumer privacy statutes that apply to location data generally, which can extend to telematics programs operating in that state even though the statute wasn’t written with car insurance specifically in mind. Other states rely mainly on the insurance department’s general rules about fair use of underwriting data, without a dedicated location-privacy statute. Because this changes and varies by state, the accurate approach is to check your own state’s current insurance department guidance and any applicable state privacy law directly, rather than relying on a general description — what applies in one state’s regulatory framework may not apply at all in another.

A related, often-overlooked variation is what happens to telematics data when a policy lapses, is canceled, or moves to a different insurer. Some programs retain historical driving data to offer a returning customer a “pre-scored” discount if they re-enroll within a defined window; others discard the history once monitoring stops. If continuity of a driving score matters to you — for example, if you’re deciding whether to pause a program during a period of low driving — that retention behavior is program-specific and is usually described in the FAQ rather than the main privacy policy.

The practical takeaway is not that telematics location tracking is uniformly invasive or uniformly limited — it’s genuinely a spectrum, and the only way to know where a specific program sits on that spectrum is to read that insurer’s telematics-specific privacy disclosure, check your state insurance department’s current guidance on data use in usage-based insurance, and ask directly, in writing, what happens to your trip-level location data after your policy ends.

0 comments
the interior of a car showing both front seats from the back seat perspective
What Gets Measured

Can Usage-Based Insurance Tell When You’re a Passenger Instead of the Driver?

by Mark Delaney
written by Mark Delaney

Why the passenger question matters at all

Usage-based insurance (UBI) programmes score a policyholder using data collected from a smartphone app, a plug-in device, or sensors built into a newer vehicle. That data is only useful if the programme can be reasonably confident about who was actually driving. A trip full of hard braking and sharp turns should only affect a score if the enrolled driver was behind the wheel — not if they were a passenger in someone else’s car, or asleep in the back seat while a family member drove. Because premiums or discounts are often tied to these scores, insurers have put real engineering effort into “driver detection,” but it remains one of the harder problems in consumer telematics, and every method used today has known blind spots.

How driver-detection algorithms attempt to distinguish roles

Most programmes don’t rely on a single signal. Instead they combine several imperfect indicators and let a model decide, with some level of confidence, whether the enrolled person was likely driving. The general logic tends to fall into three buckets: how the phone is moving and being handled, where in the vehicle the phone (or the person) seems to be sitting, and what the phone is connected to. Each is discussed below, but it’s worth stating up front that none of these, alone, reliably proves who had their hands on the wheel — they’re proxies, not direct observations.

Motion and phone-handling signals

Smartphone-based programmes lean heavily on the accelerometer, gyroscope, and GPS already built into the device. The app looks at patterns like how smoothly the phone accelerates and decelerates relative to the vehicle’s motion, whether the phone is being picked up, tilted, or touched during the trip, and how consistent the phone’s orientation is with someone actively operating a vehicle versus holding a phone loosely in a lap or pocket. Frequent screen unlocks, texting-style tap patterns, or a phone that stays remarkably still in a cupholder can all feed into a “driver” or “passenger” probability score. Some systems also compare the trip’s motion signature against a driver profile built up over previous confirmed trips — essentially asking, “does this look like how this person usually drives?”

Seating position estimates

A newer and more technical layer tries to estimate where inside the cabin the phone physically is — driver’s seat, front passenger seat, or rear — using subtle differences in signal strength, sensor readings, or, in some vehicle-integrated systems, actual seat and seatbelt sensors. Phone-only approaches typically can’t pinpoint seating position with high confidence; they infer it indirectly, for example by looking at very small differences in acceleration or rotation that correlate with which side of the vehicle the phone is on. This is genuinely difficult physics to do well from a phone alone, which is why seating-position estimates are usually treated as a supporting signal rather than a deciding one.

Device pairing and vehicle connection

Where a vehicle has Bluetooth, a factory telematics system, or a plug-in OBD-II device, the programme has a stronger anchor: it can see whether a specific phone paired to the car’s audio system, or whether a specific plug-in device (tied to a specific vehicle) recorded the trip. This narrows the question from “was this phone in a moving car” to “was this phone connected to this particular car,” which is a meaningfully better signal — though it still doesn’t confirm who was sitting where. A paired phone tells you the owner’s device was in or near the vehicle; it doesn’t tell you whether they were driving, riding along, or the phone was simply left in the car.

Where the inference breaks down: known failure cases

Because every one of these signals is indirect, there are recurring scenarios where driver-detection gets it wrong. Understanding these helps explain why programmes generally describe their scoring as probabilistic rather than certain, and why most give drivers some mechanism to flag or exclude a trip.

  • Multiple household drivers, one enrolled phone. If a spouse, teenager, or friend drives the enrolled person’s car with that person’s phone left in the vehicle — or if the enrolled driver rides along while someone else drives — the trip can be attributed to the wrong person because the phone, not the person, is what’s actually being tracked.
  • Carpools and rideshares. A passenger in a rideshare or carpool who has the monitoring app running may register a trip’s harsh braking or speed events, even though they had no control over the vehicle. Some apps attempt to detect rideshare-style trips and suppress scoring, but detection isn’t universal across every trip type or region.
  • Front-seat passengers versus drivers. Distinguishing “driver’s seat” from “front passenger seat” from phone sensors alone is one of the least reliable estimates in the whole system, precisely because the two positions are close together and produce similar motion patterns. A confident wrong call here is more common than most drivers realize.
  • Multiple phones in one vehicle. When more than one enrolled phone is present — for instance, two household members both running the same insurer’s app — the algorithm has to decide which phone belongs to the driver, and it can pick the wrong one, especially at trip start when it has the least data to go on.
  • Phone left in the car, person not present. A phone forgotten in a car that someone else then drives, or a car used for a delivery or errand by another household member, can generate a “trip” attributed to the enrolled driver’s profile even though they weren’t in the vehicle at all.
  • Low-data early trip segments. Driver-detection models generally get more confident as a trip progresses and more sensor data accumulates. Short trips — a drive around the block, a quick supply run — give the algorithm less to work with, so misclassification is disproportionately more common on short trips than long highway drives.

It’s also worth noting that failure rates and how transparent a programme is about them vary by insurer and by the specific technology used (phone-app-only versus plug-in device versus factory-installed vehicle telematics). A system with a direct connection to the vehicle’s own sensors tends to have fewer ambiguous cases than a phone sitting loose in a cupholder, but “fewer” is not the same as “none.”

What drivers can do to reduce misattributed trips

None of these steps guarantee perfect attribution, but they reduce the odds that someone else’s driving — or your own passenger trips — ends up shaping your score.

  • Keep your phone in a consistent, driver-side position. Some apps explicitly recommend mounting the phone in the same spot each time (a dashboard mount or windshield cradle near the driver) rather than letting it sit in a bag, cupholder, or pocket, since consistent positioning gives the motion and orientation signals more to work with.
  • Use the app’s passenger or “not driving” mode if one exists. Many UBI apps have a manual toggle for when you’re a passenger, on a train, or on a rideshare trip. Using it consistently — rather than only when you remember — is what actually improves the model’s confidence in flagging similar trips later.
  • Don’t leave your enrolled phone in a car someone else is driving. If another household member is taking the vehicle, consider whether your phone needs to travel with it, especially if the programme is phone-app-based rather than tied to the vehicle itself.
  • Check whether the programme is vehicle-based or phone-based, and treat it accordingly. A plug-in device or built-in vehicle telematics system records whoever drives that car, regardless of whose phone is present — so the relevant question shifts from “whose phone was in the car” to “who was driving this specific vehicle.” Household members sharing a car under a vehicle-based programme should ask the insurer how (or whether) individual drivers within the same household are distinguished at all.
  • Review trip data promptly if the app allows it. Many programmes let you view individual trips shortly after they’re recorded, sometimes with an option to note that a trip wasn’t yours or wasn’t representative. Checking this regularly — rather than only when a score drops unexpectedly — makes it easier to catch a pattern of misattribution early, such as repeated short trips you don’t recognize.
  • Keep the app and phone software current. Sensor calibration and driver-detection models are refined over time through software updates; running an outdated version of the app can mean missing improvements to exactly this kind of classification.

What to check with your own insurer or programme

Because driver-detection methods, confidence thresholds, and correction mechanisms differ by insurer, by state, and even by which specific telematics technology (phone app, plug-in device, or embedded vehicle system) is in use, it’s worth reading your own programme’s documentation rather than assuming it works the way a different insurer’s programme does. Useful questions to look for answers to include: what happens when the app detects low confidence about who was driving, whether there’s a passenger mode and how it affects scoring if used inconsistently, and whether trips can be reviewed or annotated after the fact. Program guides, in-app help sections, or a call to the insurer’s telematics support line are typically better sources for these specifics than general comparisons across companies, since the underlying technology and its limitations are not standardized across the industry.

0 comments
a car's headlights illuminating a dark rural road
How Scoring Works

Why Night Driving Weighs So Heavily in a Usage-Based Score

by Mark Delaney
written by Mark Delaney

How “Night Driving” Windows Are Defined by Time of Day

Every usage-based insurance (UBI) program has to draw a line somewhere between “daytime” and “nighttime” driving, and that line is not universal. Most telematics apps and plug-in devices define the night window using the trip’s start time, though some instead evaluate the entire duration of a trip and flag it as a night trip if any meaningful portion falls after dark.

Common windows used across the industry tend to cluster in a similar range, typically starting somewhere between 9 p.m. and midnight and ending somewhere between 4 a.m. and 6 a.m. A program might treat any trip beginning at 11 p.m. or later as a night trip, while another might start counting at 9 p.m. The difference of even an hour or two matters to a driver whose schedule regularly puts them on the road right at the boundary — a late shift ending at 11:15 p.m. could fall inside one insurer’s night window and outside another’s entirely.

A few programs also adjust the window seasonally, since actual darkness shifts with sunset and sunrise times across the year and by latitude. This is less common than a fixed clock-based window, but it does exist in some scoring models, particularly those that lean more heavily on contextual data rather than a flat time-of-day rule. Because the definition is proprietary to each program, the only reliable way to know exactly what counts as “night” for a given policy is to check the specific program’s disclosures, FAQ, or in-app scoring explanation rather than assume it matches a previous insurer’s rules.

The Statistical Basis for Treating Night Trips Differently

The reason night driving carries weight in a score is not that insurers consider it morally riskier or a sign of poor habits. It is that crash data, aggregated over long periods and large populations, consistently shows a higher rate of fatal and serious-injury crashes per mile driven at night compared with daytime hours. This is usually measured as crashes per vehicle-mile-traveled (VMT), which corrects for the fact that fewer people are on the road at night in absolute terms — the comparison is about risk density per mile, not just raw crash counts.

Several contributing factors are generally cited in traffic-safety research when explaining this gap:

  • Reduced visibility — headlights illuminate a fraction of the distance that daylight allows, which shortens the time a driver has to react to hazards, pedestrians, or stopped vehicles.
  • Higher prevalence of impaired driving — alcohol- and drug-involved crashes are disproportionately concentrated in late-night and early-morning hours in most datasets.
  • Fatigue — drowsy driving incidents cluster around late night and the pre-dawn hours, tied to natural circadian dips in alertness.
  • Different road mix — night driving often includes a higher share of higher-speed rural or arterial roads, which are less forgiving than the low-speed local roads that dominate daytime commuting.

None of these factors describes any individual driver on any individual trip. A driver who commutes home at 10:30 p.m. on a well-lit interstate is not personally impaired or fatigued because of the hour, and most usage-based programs do not claim otherwise. What the scoring reflects is a population-level statistical association between the time window and elevated risk, applied uniformly to everyone whose trips fall into it. This is the same logic that underlies age-based or location-based rating factors elsewhere in insurance pricing: the model does not know the individual, only the correlation the group has demonstrated historically.

It’s worth noting that the strength of this correlation is not perfectly stable — it can vary by road type, by region, and by the specific hours examined. A program’s exact weighting is calibrated against its own claims data and the vendor’s broader dataset, not against a single universal night-risk multiplier that applies identically everywhere.

How This Factor Is Weighted Relative to Braking or Speed

Usage-based scores are composite figures, typically built from several behavioral and contextual inputs that might include hard-braking events, rapid acceleration, cornering forces, speeding relative to the posted limit, phone handling or distraction signals, mileage, and time-of-day distribution. Night driving is usually one input among these rather than a standalone score, and how much it moves the needle depends on the specific weighting formula, which is not standardized across the industry.

In general terms, based on how these programs describe their own methodologies, a few patterns tend to hold:

  • Behavioral events — hard braking, aggressive acceleration, sharp cornering — are often weighted heavily because they are direct, observed evidence of how a specific trip was actually driven, not just when it occurred.
  • Speeding relative to the limit is frequently treated as a strong signal too, since excessive speed has a well-documented and fairly direct relationship to crash severity.
  • Night driving and other contextual factors (like the proportion of miles on highways versus local roads) tend to function more as a background risk adjustment — they shift the baseline expectation for a trip rather than penalizing a specific observed action within it.

Despite being a background factor, night driving can still carry disproportionate influence for one practical reason: it is binary and structural, not variable and occasional. A driver’s hard-braking rate can improve trip to trip with more cautious habits. The hour a shift ends generally cannot. For a nurse, security guard, delivery driver, or restaurant worker whose schedule regularly requires late-night trips, the night-driving component of a score may be effectively fixed regardless of how smoothly every individual trip is driven. This is a frequent point of frustration among enrolled drivers, and it’s a legitimate one — the factor is measuring a time slot, not a skill.

Some newer scoring models attempt to soften this by giving more relative weight to behavioral inputs and less to time-of-day, or by contextualizing night trips against road type and posted speed rather than penalizing the hour alone. Others explicitly separate “controllable” and “less controllable” factors in their driver-facing explanations, sometimes advising users that behavioral metrics are the ones they can most directly influence. Whether a specific program does this — and how much it does — is disclosed, if at all, in that program’s own scoring methodology page rather than in any general industry standard.

Why the Exact Night Window and Weighting Vary by Program

There are a few structural reasons no single night-driving definition or weighting has become universal across US usage-based insurance.

Different data sources and vendors

Many insurers license their telematics technology from a small number of third-party vendors rather than building scoring algorithms in-house, while others build proprietary models. Each vendor’s model is trained on its own aggregated dataset, which may weight time-of-day risk differently depending on the mix of drivers, regions, and vehicle types in that dataset.

State regulatory review

Insurance rating factors, including those used in usage-based programs, are generally subject to review by state insurance regulators, and the degree of scrutiny — and what’s permitted — varies by state. A weighting scheme approved in one state’s regulatory environment is not automatically transferable to another, which is part of why the same insurer’s program can behave slightly differently depending on where a policy is written.

Program design philosophy

Some programs are built primarily as pricing tools, where the score maps fairly directly to a discount or surcharge. Others are positioned more as feedback or coaching tools, where the score is meant to encourage behavior change and the underlying weighting may be tuned to emphasize factors a driver can act on. A coaching-oriented program has more incentive to de-emphasize an unchangeable factor like a work-driven late shift, while a pure-pricing program may weight it purely on its statistical predictive value.

Ongoing recalibration

Because these are actuarial models, insurers periodically recalibrate them against updated claims experience. A night-driving weighting that reflected the data available at a program’s launch may be adjusted after a few years of the insurer’s own claims history, which means published weightings — where they’re published at all — should be treated as current-version information, not fixed permanently.

What This Means for a Driver Evaluating a Program

For anyone comparing usage-based programs or already enrolled in one, the practical takeaway is to look past the marketing language of “drive safe and save” and check the specific mechanics that apply to the policy in question:

  • What hours count as the night window, and does it apply to trip start time or any portion of the trip?
  • How much relative weight is placed on time-of-day versus observed behavioral events like braking and speeding?
  • Is there any adjustment for road type, posted speed limit, or other context around night trips, or is it a flat penalty for the hour alone?
  • Does the program’s disclosure materials describe the score as a discount-eligibility tool, a surcharge risk, or primarily a feedback mechanism?

This information is typically found in the program’s terms, FAQ, or in-app scoring breakdown rather than in general advertising. Because the definitions and weightings are set independently by each insurer and can change between years, a driver whose schedule includes regular night hours is generally better served by reading the specific program’s documentation than by assuming any single number or rule they’ve heard applies across the board.

0 comments
a car navigating a tight curved road from an elevated angle
How Scoring Works

What Counts as Aggressive Cornering in a Telematics Algorithm

by Mark Delaney
written by Mark Delaney

How Lateral Acceleration Is Detected by Onboard Sensors

Every telematics programme, whether it runs through a plug-in device, a factory-installed module, or a smartphone app, relies on a small accelerometer to sense motion in three dimensions. Forward and backward motion registers as acceleration and braking. Up-and-down motion mostly gets filtered out as road noise. The dimension that matters for cornering is lateral acceleration — the sideways force that pushes a vehicle’s contents toward the outside of a turn.

When a car turns, the tires generate a centripetal force that keeps the vehicle on its curved path. The accelerometer inside the phone or device measures the reaction to that force, typically expressed in units of g (a fraction of standard gravity). A gentle highway curve taken at speed might produce a lateral reading of a few hundredths of a g. A tight, fast turn can push that figure well above a tenth of a g, and aggressive slaloming or a sharp evasive swerve can spike higher still.

Phone-based systems face an added complication: the phone’s orientation inside the car isn’t fixed. Software has to work out which axis of the sensor corresponds to “sideways” relative to the vehicle, a process usually done by watching how the readings behave over the first several minutes of a trip and recalibrating continuously. Dashboard-mounted devices and factory telematics units, which are bolted to the car in a known orientation, generally produce cleaner and more consistent lateral readings than a phone sitting loose in a cupholder or bag. This is one reason two drivers in the same car, one using a phone app and one using a plug-in dongle, can occasionally see somewhat different cornering scores for what felt like the same driving.

GPS data is layered on top of the raw accelerometer signal. Speed and position let the algorithm distinguish a real turn from, say, the phone shifting position on a seat, and they also let it estimate the radius of the turn being taken — information that matters for the next step: deciding which turns are worth flagging.

The Difference Between a Sharp Turn and a Flagged Cornering Event

Not every corner that produces a noticeable lateral force gets logged as an event that affects a score. Insurers set a threshold — a lateral acceleration value that a turn must exceed before it’s recorded — and that threshold is calibrated against ordinary driving so that routine cornering, like turning into a parking lot or following a curved exit ramp at a reasonable speed, doesn’t trigger a flag every few minutes.

Most programmes combine two things before logging an event:

  • A lateral force threshold, so only turns above a certain sharpness are candidates.
  • A duration or repetition check, so a single brief blip caused by sensor noise or a pothole doesn’t count the same as a sustained hard turn.

Speed at the point of the turn matters too, because the same steering angle produces very different lateral forces depending on how fast the car is going. A tight turn taken slowly may never cross the threshold, while a much gentler curve taken too fast can. This is part of why the algorithm is measuring force rather than steering angle directly — force is a better proxy for how much stress the turn actually put on the vehicle and its occupants, and by extension how much margin for error the driver had left themselves.

Once a turn crosses the threshold, it’s typically logged as a discrete event with a timestamp, location, speed, and severity value. Some systems bucket these into tiers — for instance, a moderate cornering event versus a harsh one — with harsher events carrying a larger scoring penalty. The exact thresholds, tiering, and weighting are proprietary to each insurer’s programme and are rarely published in detail, so a driver comparing notes with a friend on a different insurer’s app should expect the numbers to not line up neatly even if the driving looked similar from the outside.

How Road Design and Unavoidable Turns Get Treated by the Algorithm

One of the more persistent frustrations drivers report with cornering scores is the sense of being penalized for the road itself rather than for how they drove it. A cloverleaf highway interchange, a mountain switchback, or a tightly curved neighborhood street can require lateral forces that would look identical to careless driving on a straight road, even when the driver is doing exactly what the road demands.

Telematics providers are aware of this and most have some form of map-matching built in, using GPS position data to compare the recorded route against known road geometry. In principle, this lets the algorithm distinguish “sharp turn because the road curves sharply here” from “sharp turn because the driver cut a gentle curve too fast.” In practice, how well this works varies a great deal by provider, by how current and detailed the underlying map data is, and by how strong the GPS signal was at that moment — dense urban blocks, tunnels, and multi-level interchanges are all places where GPS accuracy tends to degrade.

Where map-matching is weak or absent, the practical effect is that a driver whose regular commute includes a lot of curved roads, on-ramps, or roundabouts may see a persistently lower cornering score than a driver on a mostly straight commute, independent of how carefully either one is driving. This is a known limitation rather than a hidden one, but it’s not always disclosed clearly to the driver in the app itself, and it’s worth checking a specific programme’s materials or asking the insurer directly whether road-geometry adjustment is applied to cornering events before assuming a low score reflects driving behavior alone.

A related wrinkle involves necessary evasive maneuvers — swerving to avoid an object, an animal, or another vehicle’s sudden movement. A single sharp lateral event of this kind will typically still be logged and scored the same as any other hard corner, because the sensor has no way to know intent. Some programmes allow a small number of these events to be absorbed without much effect on an overall score simply because the scoring is usually based on a rate of events per mile or per trip rather than a strict count, so an isolated incident in months of otherwise smooth driving tends to have limited weight. A pattern of frequent hard cornering, by contrast, is much harder for the algorithm to explain away as one-off necessity, and will read as a consistent behavioral signal.

Why Cornering Scores Tend to Vary More Than Braking Scores

Drivers who watch their own telematics dashboards over time often notice that their braking score settles into a fairly stable number, while their cornering score moves around more from week to week or month to month. There are a few structural reasons this tends to happen.

First, braking events are largely a function of the driver’s following distance and reaction time, which are relatively stable habits that don’t change much depending on where someone happens to drive. Cornering events, by contrast, are heavily shaped by the specific roads travelled on a given trip. A week of driving confined to a grid of straight suburban streets will generate very few cornering opportunities at all; a week that includes a mountain drive, an unfamiliar city with tight one-way streets, or a highway interchange with a tight cloverleaf will generate several, almost regardless of skill. Route variability feeds directly into score variability in a way that braking is less exposed to.

Second, the detection threshold for lateral force is sensitive to small changes in vehicle speed and steering input near the margin, more so than the threshold for deceleration tends to be in ordinary traffic. A turn taken at just above versus just below the flagged speed can be the difference between a logged event and nothing at all, and ordinary variation in traffic conditions — needing to slow slightly more or less for a curve depending on the car ahead — can push a turn across that line on one trip and not the next.

Third, sensor placement and calibration issues described earlier affect lateral readings more than they affect forward/backward readings, because gravity provides a constant, easily-corrected reference for the vertical and forward axes, while the sideways axis depends more on how well the device’s orientation has been estimated. A phone that shifts slightly in a cupholder mid-trip can introduce noise into lateral readings that wouldn’t show up the same way in braking data.

None of this means cornering scores are meaningless or that they should be dismissed — used correctly, they can capture a real pattern of taking turns faster or more sharply than the road warrants. But because the score is more exposed to route, road geometry, and sensor-placement noise than braking is, most usage-based programmes treat it as one input among several rather than the dominant factor in an overall driving score, and it’s the input most likely to look “noisy” to a driver checking their app week to week. If a cornering score seems consistently out of step with a driver’s own sense of how they drive, the more informative comparison is usually not one week against another, but the pattern over several months against the mix of roads actually travelled — and, where an insurer publishes it, whether route-based adjustment is factored into that particular metric before it’s rolled into a discount or surcharge.

0 comments
a simple upward and downward arrow graph on a printed document
Data and Opting Out

Can a Telematics Program Increase Your Premium Instead of Lowering It?

by Mark Delaney
written by Mark Delaney

Two different mechanisms, often bundled into one app

Most monitored-driving programs actually combine two separate pricing mechanisms, and conflating them is where a lot of driver confusion starts.

The first is an enrollment discount: a reduction applied simply for signing up and letting the insurer collect data, sometimes for completing a short onboarding period. This portion is typically small, disclosed upfront, and not contingent on how you actually drive. It exists mainly to compensate the insurer for the data it gains and to offset the cost of a driver who might otherwise decline to participate.

The second is a score-based adjustment, calculated after a monitoring period – commonly somewhere between a few weeks and a few months, depending on the insurer – using the behavioral data collected through a phone app, a plug-in device, or a factory-installed telematics system. This is the part that can move in either direction. A driver with a strong score may see the enrollment discount grow at renewal. A driver with a weak score may see it shrink, disappear, or convert into a surcharge that pushes the premium above where it would have been without enrolling at all.

The distinction matters because marketing materials tend to foreground the discount and mention the score-based adjustment in smaller print, or describe it only in terms of “potential savings.” Whether the program can raise your rate above a non-participating baseline – and by how much – is a program-specific fact you need to check in the actual terms, not infer from the advertising.

Which behaviors are commonly tied to surcharges

Programs vary in what they measure, but most build their scoring around some combination of the following. Understanding how each is measured is useful before assuming what a poor reading means.

Hard braking and rapid acceleration

These are usually detected through the accelerometer in a phone or device, measured as a rate of deceleration or acceleration over a short time window (for example, a drop in speed that exceeds a set threshold within roughly a second). A single hard-braking event from avoiding a hazard reads identically, to the sensor, as one caused by tailgating. Programs generally rely on frequency over many trips to smooth out one-off events, but a driver in stop-and-start urban traffic will naturally register more hard-braking events than one on open highways, regardless of skill.

Speed relative to the posted limit

Some programs compare recorded GPS speed against mapped speed-limit data for the road segment being driven. This introduces a known source of error: mapping databases are not always current, and misclassified roads can flag normal driving as speeding. Insurers that use this metric typically build in some tolerance, but the size of that tolerance is rarely published in detail.

Phone handling and distraction

Motion sensors and screen-state data can be used to infer whether a phone was being handled, unlocked, or actively used while the vehicle was moving. This is often one of the more heavily weighted factors because distraction is closely tied to crash risk in insurer models, but it’s also one of the more error-prone signals – a phone sliding off a seat or being used by a passenger can register as driver distraction depending on how the sensor logic works.

Night driving and mileage

Trips are timestamped and geolocated, so a program can score the proportion of driving that happens late at night or the total distance covered. These aren’t behaviors in the same sense as braking or phone use – they’re exposure factors – but some programs fold them into the same composite score, which means a driver who simply works night shifts can be scored down for something that isn’t really about driving quality.

Cornering and route/context factors

A smaller number of programs also log lateral acceleration through turns, or use trip context (time of day, road type) as a modifier on other signals. These tend to carry less weight than braking, speed, or phone handling in most published methodology summaries, but that weighting differs by insurer and can change between program versions.

The common thread is that every one of these metrics is a proxy for risk, not a direct measurement of it. A proxy can be systematically noisy for particular driving conditions – dense city grids, rural roads with outdated speed data, jobs that require night driving – without the program being able to distinguish “risky” from “circumstantial.”

Why the structure varies so much between insurers

There is no single national template for these programs. Several things drive the variation:

  • State regulatory approval. Auto insurance rating factors are approved at the state level, and not every state’s regulator has approved the same telematics variables or the same maximum surcharge. A factor that can move your premium in one state may be capped, restricted, or entirely unavailable to insurers in another. This is one of the main reasons the same program, offered under the same brand name, can behave differently depending on where a policy is written.
  • Underwriting philosophy. Some insurers designed their programs primarily as retention and marketing tools – a way to attract price-sensitive, safety-conscious drivers with a modest guaranteed discount and a soft-touch score that rarely produces a surcharge. Others built programs closer to true usage-based pricing, where the score materially replaces some of the traditional rating factors and can move the premium substantially in either direction.
  • Program maturity and data volume. Newer programs, or those with smaller enrolled populations, often lean on conservative scoring because the insurer has less data to validate which thresholds actually predict claims. More established programs may apply sharper distinctions between drivers because they have more history to back the model.
  • Whether the program is opt-in per term or continuous. Some programs score a single monitoring window and then lock in the resulting discount tier for the policy period, insulating you from mid-term swings. Others rescoring continuously and adjust at every renewal, meaning a bad month of driving right before renewal can outweigh a good year before it.

Because of this variation, a comparison of headline discount percentages between two insurers tells you very little about the actual downside risk. A program advertising a larger maximum discount may also carry a larger maximum surcharge; a program with a smaller headline discount may guarantee no surcharge at all. The only way to know which situation you’re in is to read the specific program’s terms, not to compare taglines.

What program terms typically disclose – and where to look for it

Because these programs are relatively new relative to traditional rating factors, disclosure quality varies, but most legitimate programs will address the following points somewhere in the terms, FAQ, or program agreement rather than in the main advertising copy:

  • Whether a surcharge is possible at all. Some programs explicitly state that participation can never raise your premium above what it would have been without enrolling – it can only reduce or fail to reduce it. Others explicitly reserve the right to apply a rate increase based on the score. This is usually the single most important sentence in the document, and it’s worth searching for directly rather than assuming.
  • The scoring window and how often it’s reassessed. Look for language describing whether the score is calculated once, periodically, or continuously, and whether a new score applies at the next renewal or takes effect mid-term.
  • How much weight each behavior carries. Detailed weighting formulas are rarely published in full, but many programs provide a general description – for example, indicating that phone distraction or hard braking is weighted more heavily than mileage. This helps you understand what’s actually driving your score rather than guessing from the app’s dashboard.
  • Opt-out and data-retention terms. Programs generally describe what happens if you stop participating mid-term – whether your discount reverts, whether it disappears immediately, and whether the collected data is retained or deleted. Some also describe whether declining to enroll, or exiting early, affects your eligibility to re-enroll later.
  • Minimum data thresholds. Many programs require a minimum number of trips or miles before a score is considered reliable enough to act on. Driving very little during the monitoring window can sometimes result in a default or neutral score rather than a discount, which is worth checking if your driving is seasonal or infrequent.

If any of these points aren’t addressed in the material you were given at enrollment, it’s reasonable to ask the insurer directly or check the state insurance department’s consumer resources, since rate filings for approved programs are generally public record even when the marketing summary is thin.

The practical takeaway

A telematics or usage-based program is not a single, uniform product – it’s a pricing structure that each insurer configures differently within the limits its state regulator allows. The enrollment discount is usually the safe, guaranteed part. The score-based adjustment is the part that can help you or hurt you, and whether it can hurt you at all is a specific, checkable fact rather than something you should assume from how the program is marketed. Before enrolling, or before assuming your existing app-based discount is purely upside, it’s worth locating the actual program terms and confirming three things: whether a surcharge is possible, what behaviors drive the score most heavily, and how often the score is recalculated. Those three answers will tell you far more about your actual risk than the discount percentage on the sign-up screen.

0 comments
a printed insurance disclosure document with a pen resting on it
Data and Opting Out

How to Read a Telematics Privacy Disclosure Before You Enroll

by Mark Delaney
written by Mark Delaney

Where Data-Collection Scope Is Usually Defined

Telematics privacy disclosures are rarely a single document. Most programmes split the terms across two or three places: a general privacy policy that covers the insurer’s whole business, a program-specific addendum or “telematics terms” page that covers the app or plug-in device, and sometimes a separate consent screen inside the app itself that you tap through during setup. The section that actually tells you what is measured is almost never on page one. It’s usually titled something like “Information We Collect,” “Data Collected Through the Program,” or “Types of Telematics Data.”

When you find that section, read it as a list of categories rather than a narrative. Most programmes collect some combination of the following:

  • Motion and location data — GPS coordinates, speed, acceleration, braking force, and cornering, usually sampled continuously while the app or device detects that a trip is underway.
  • Trip metadata — start and end times, trip length, and sometimes road type or time of day, which several insurers use as a proxy for risk exposure separate from how someone actually drives.
  • Phone-use signals — whether the handset was handled, screen-on events, or call and messaging activity during a trip. Not every program collects this; some rely on the vehicle’s own sensors or a plug-in device instead of the phone, which changes what’s technically observable.
  • Device and account identifiers — the phone’s operating system, app version, and an internal ID tied to your account, which is distinct from your name but can usually be linked back to you by the insurer.
  • Vehicle diagnostic data — for programs using a plug-in device or built-in vehicle connectivity, this can include mileage, fault codes, or airbag deployment status.

The scope section is also where you’ll find out whether monitoring runs continuously or only during something the app defines as a “trip.” That distinction matters for anyone concerned about background tracking: a program that only activates above a certain speed threshold behaves very differently from one that logs location whenever the phone has motion permission enabled. If the disclosure doesn’t say explicitly when collection starts and stops, that’s a gap worth noting before you enroll, not after.

One more thing worth checking here: whether the scope section references a companion vehicle, not just the primary driver. Some household or family plans capture trip data for anyone who drives the enrolled car, which has implications beyond the person who signed up.

How Third-Party Data-Sharing Clauses Are Typically Worded

This is the part of the disclosure most people skim past, and it’s usually the longest section because it has to cover several different categories of recipient. Sharing clauses tend to separate into three tiers, and the wording usually signals which tier you’re reading about.

Service providers acting on the insurer’s behalf

Language here often reads like “we may share information with vendors who help us operate the program,” followed by examples such as app hosting, data analytics, or customer support. These vendors are typically bound by a contract that limits what they can do with the data, but the disclosure rarely names them. If you want to know exactly who handles your trip data, that detail is sometimes only available by contacting the insurer directly or checking a vendor list buried in a linked policy.

Affiliated companies

Larger insurance groups often reserve the right to share telematics data across sibling companies — for underwriting other lines of insurance, for example. The phrasing to watch for is something like “our affiliates” or “companies within our corporate family.” Whether that sharing affects pricing on another policy you hold with the same group is not always spelled out, and it varies by company and by state, since some states place additional limits on cross-affiliate use of driving data.

Independent third parties

This is the category that generates the most reader concern, and for good reason: it can include data brokers, marketing partners, or other insurers participating in shared scoring consortiums. The wording is often narrower than it looks — many disclosures state that data is shared only in aggregated or de-identified form, or only with consent, or only in connection with a claim. But “de-identified” is doing a lot of work in that sentence, and standards for what counts as properly de-identified differ by company and by state law. If the disclosure uses that term without describing the method, it’s fair to treat it as unverified rather than assume the strongest possible interpretation.

It’s also worth checking whether the sharing clause distinguishes between data used to price your policy and data used for other purposes — research, product development, or sale to unrelated third parties. Some disclosures bundle all of this under one broad permission; others separate it out and let you opt out of the non-underwriting uses specifically. Where an opt-out exists, it’s usually described in the same section, not in a separate privacy-rights page, so read to the end of the sharing clause before concluding there isn’t one.

Spotting the Retention and Deletion Terms

Retention terms answer a question scope sections don’t: how long the company keeps what it collects, and what happens to it after you leave the program. This section is sometimes folded into the general privacy policy rather than the telematics addendum, so if you don’t see it near the collection section, check the main policy’s “data retention” or “how long we keep your information” heading.

A few patterns to look for:

  • A defined retention period tied to policy status. Some insurers state that trip data is kept for the length of the policy plus a set number of years afterward, often justified by recordkeeping or regulatory requirements. Others are vaguer, stating data is kept “as long as necessary for business purposes,” which gives little practical guidance about an actual timeline.
  • Different retention for raw versus derived data. A company might delete second-by-second location traces after a shorter window while keeping the summary score, discount level, or a derived risk category for much longer. If the disclosure distinguishes between raw telematics data and “derived” or “processed” data, that distinction usually determines what actually gets deleted and when.
  • What happens on cancellation. Leaving the program or switching insurers doesn’t automatically trigger deletion in every case. Some disclosures state that data already collected is retained under the standard schedule regardless of whether you’re still enrolled; others describe a specific deletion or de-identification process triggered by opting out. If this isn’t addressed at all, that silence is itself useful information — it likely means the standard retention period applies with no early exit.
  • State-specific rights. A growing number of states have consumer privacy laws that create rights to request deletion or access to collected data, but the availability and mechanics of those rights vary significantly by state and by how the insurer has implemented compliance. If the disclosure references a “Your Privacy Rights” or “State Privacy Notices” section, that’s usually where any deletion request process is described, separate from the telematics-specific terms.

Retention language is also where you can sometimes tell how a score is calculated over time — whether a single bad trip is smoothed out over a rolling window or whether it’s weighted more heavily near renewal. Not every disclosure goes into that level of detail, but when it does, it’s usually adjacent to the retention terms rather than the collection section, since it’s describing what’s done with data that’s already been kept.

Questions Worth Asking Before Signing Up

Even a clearly written disclosure tends to leave some things unaddressed, either because they’re genuinely determined case-by-case or because the language defaults to the broadest permission available. Based on where these documents most often stay vague, it’s worth getting direct answers — from an agent, a customer service line, or the program’s FAQ — on the following before you enroll:

  1. Does monitoring run continuously in the background, or only during app-detected trips? The scope section may not say this plainly, and it changes how much location data is generated even when you’re not driving for insurance purposes.
  2. Can a single trip or a short bad stretch affect pricing, or is scoring based on a longer rolling average? This affects how much a bad week matters relative to months of otherwise steady driving.
  3. What happens to already-collected data if I opt out midway through the program? If the disclosure doesn’t specify, ask directly rather than assuming deletion is automatic.
  4. Is any of my data shared with unaffiliated third parties in a form that isn’t fully de-identified? If the answer relies on a definition of de-identification, ask what standard is used.
  5. Does participation affect pricing on other policies I hold with the same company or its affiliates? This is more likely with bundled policies and varies by state and by insurer group structure.
  6. Is there a way to see my own trip data and my derived score, not just the discount or surcharge it produced? Some programs offer a dashboard; others only report the net effect on price, which makes it hard to know which behaviors are actually being weighted.
  7. Who do I contact, and through what process, if I want to exercise a state privacy right to access or delete my data? The relevant contact is sometimes different from general customer service.

None of these questions require legal training to ask, and a program that’s confident in its own terms should be able to answer them without directing you back to the same disclosure you already read. If an answer changes depending on your state, that’s a normal and expected response — telematics privacy terms are shaped as much by state law as by company policy, and a program available nationally may genuinely operate under different rules depending on where the vehicle is registered. Treat that variation as a reason to check the specific document for your state rather than a reason to assume the disclosure is being evasive.

0 comments