Connected Insurance: How to benchmark a best-in-class telematics SDK?

Introduction

The success of a connected insurance program depends on many factors including the quality of the mobile app, the underwriting and the customer experience. A key component of a seamless customer experience, and a critical requirement for building scalable Pay-As-You-Drive and Pay-How-You-Drive programs, is a best-in-class telematics SDK.

Today, it is fair to say that all telematics SDKs on the market can be considered good products. It is no surprise as mobile telematics is a mature technology that has been around for the last 10 years, powering around 50 millions insurance policies in 2025. Insurers (including Progressive, AllState, Direct Assurance and Tokio Marine to name only a few) using this technology have reported lower loss-ratios and higher customer loyalty for years.

That being said, there are critical differences between good telematics SDKs and best-in-class telematics SDKs. Based on feedback from insurers who have successfully scaled connected programs, the most performant SDKs consistently outperform on three key metrics that drive customer adoption and satisfaction: trip detection rate, battery consumption, and data usage.

• Trip detection rate refers to an SDK ability to automatically detect all motorised trips based on smartphone data. It is the most important SDK functionality as Pay-As-You-Drive and Pay-How-You-Drive programs rely on trip data to personalize premiums, based on the distance driven and/or driving behavior. Poor trip detection thus impacts a driver’s risk profile and can lead to inaccurate premiums. Insurance teams should also doubt the reliability of a SDK that does not detect motorised trips accurately as it may fail to activate crash detection, potentially leading to terrible consequences.

• Battery consumption refers to how much a SDK drains a phone battery. High battery consumption negatively impacts user experience and threatens user’s retention by generating support tickets, low user satisfaction, and eventually app uninstallation.

• Data usage refers to the amount of cellular data an SDK consumes. High data usage negatively drains users’ data plan. The consequences are similar to those of high battery consumption: low user satisfaction and app uninstallation.  

Each of these metrics directly influences the customer experience, which is one of the key value drivers of any connected insurance program. If a telematics SDK underperforms on any of these three metrics, large-scale adoption of a connected insurance program and crash detection is at risk.

To help auto insurers identify the most performant SDKs across these three indicators, this guide presents a testing methodology along with results gathered under real-world conditions. The goal is to provide insurance teams with a reliable and reproducible framework for selecting telematics SDKs that preserve customer experience and policyholder satisfaction.

Trip Detection Rate

Detecting trips

As mentioned earlier, the trip detection rate reflects how well an SDK automatically identify motorised trips using smartphone data. This capability is essential for any connected program, as trip data is required to perform road risk analysis, to personalise premiums and to enable crash detection.

Testers manually recorded the start and end points, along with the duration of each trip, to accurately measure the trip detection rate. The information was later used to compare the actual trip data with the trip data recorded by the SDKs.

The chart below shows the trip detection rate for each SDK:

Most SDKs achieved a high trip detection rate, above 97%. Although SDK D seems significantly less reliable, its poor performance is likely due to the app it was integrated into, which focuses on tracking family members rather than monitoring motorised trips. Had SDK D been implemented into an insurance app, its performance would have been above 97%.

Detecting distance and duration

To provide an overview of a trip, all telematics SDKs collect data on the distance driven and on the trip duration. These are essential indicators for connected insurance programs as actuarial models demonstrate that increased kilometers and time spent driving correlate with higher risk. While mobile telematics is highly effective at detecting trips, accurately detecting the exact distance and duration is more challenging.

As explained in the article "How does automatic trip detection work?", mobile telematics combines several mechanisms to detect a trip. These mechanisms can be more than 99% effective, as demonstrated in the previous section. However, a short lapse of time is required for the phone OS to wake up the app in background and confirm that the detected movement is a motorised trip. During this short time window, no driving data is recorded by the SDKs, meaning that the first 300 to 500 meters of each trip are not captured in terms of distance, duration and driving behavior.

Some telematics service providers (TSP) compensate for this by completing the trip, a strategy called "auto-completion". These TSPs consider that the distance between the last known location of the car and the first measured point of the new trip was actually driven by the vehicle. In some cases, this strategy improves the app interface because the trip is displayed with the correct starting point in the app. 

However, this strategy is only adopted by a minority of TSPs. Most telematics providers, including DriveQuant, do not enable auto-completion by default for two main reasons:

• Transparency with drivers requires displaying only the portion of the trip where driving data is actually collected. Auto completing the trip adds no information about the driving behaviour during that segment. While it may enhance visual presentation, it does not improve data analysis. Whether a trip is auto-completed or not, insurers receive the same volume of driving data.

• Auto completion can lead to confusion and create mistakes. Our tests reveal that around 15% of auto-completed trips show an incorrect starting point. These errors typically occur when testers drive a second vehicle or use another means of transport. In such cases, auto-completion mistakenly merges two trips that correspond to two different vehicles, assigning the endpoint of the second vehicle’s trip as the starting point of the next trip with the first vehicle.

Insurance teams should also keep in mind that its relevance in connected insurance programs is limited: 

• In the context of Pay-How-You-Drive programs, auto-completion does not add any additional value as there is no behavioral data associated with the computed distance and duration.

• In the context of Pay-As-You-Drive programs, as explained extensively in the article “Understanding Beacon Technology in Connected Insurance”, auto-completion is not relevant as telematics apps should be combined with a beacon.

To identify the few SDKs using auto-completion, insurers should open the app and check the trip interface. If the first meters of a trip appear in a different color - typically grey -  it means that auto-completion was used to compute the missing distance. As noted above, although the app may display a complete trip, it is only an interface modification. There is no difference in terms of quality and quantity of driving data collected compared to other SDKs.

Battery consumption

Battery consumption refers to how much an SDK impacts a phone’s battery life. Optimized battery consumption is a requirement to boost user adoption and minimize frictions and complaints from users.

Measuring battery consumption varies depending on the phone operating system. 

• On iOS devices, daily battery usage can be checked by navigating to “Settings”, “Battery”, and “Daily Usage”.

• On Android devices, daily battery usage can be checked by navigating to “Settings” and “Battery”. Some custom interfaces do not show daily usage. Therefore, it may require setting up a 24-hour alarm to manually report battery usage.

The chart below shows the average daily battery consumption for each SDK:

All SDKs except SDK C consume less than 3% battery per day on average. It is worth noting that SDK B and SDK C show significant OS variations, consuming 1% more battery on iOS than on Android. In contrast, SDK A, SDK D and DriveKit achieve consistent battery efficiency across both OS.

Data usage

Data usage refers to the amount of cellular data consumed by an SDK. Minimized data consumption helps preserve customers’ data plan, a critical requirement in countries where mobile data allowances are limited and/or expensive. Low data usage also demonstrates a greater emphasis on privacy as it indicates that the SDK transfers the minimal amount of data necessary.  

As with battery consumption, the method for checking data usage varies depending on the phone’s operating system.

• Before testing, iOS users have to reset their cellular data statistics by navigating to “Settings”, “Cellular”, and then “Reset statistics”.

• Before testing, Android users must manually report their initial cellular data statistics for each app.

The chart below shares the average monthly data usage for each SDK:

SDK A and DriveKit consume less than 400 MB data per month, which is roughly equivalent to streaming a single HD video of under 30 minutes. SDK B and SDK C do consume a more significant amount of cellular data, above 1 GB per month. That being said, these SDKs track all types of mobility, including footwalk, which results in increased data consumption.

Conclusion

The tests demonstrate that while all telematics SDKs offer comparable trip detection capabilities, there is a noticeable performance gap in battery and data consumption between good and best-in-class SDKs. This gap has real consequences for the customer experience: 

• Without a very high trip detection rate, risk analysis and personalized pricing are doomed to lead to inaccurate premiums, and connected services such as crash detection may fail to activate.

• Without low battery usage, the insurance app will likely be deleted in a matter of days or weeks, as it causes friction and dissatisfaction for customers.

• Without low data usage, the insurance app will likely be deleted as users will not engage in a connected program that drains their data plan and/or require a more expensive data plan.  

Based on our real-world tests, DriveKit likely delivers the most balanced customer experience, detecting all motorised trips without impacting battery life. While SDK A leads by a short margin in data usage, DriveKit ranks second with very low consumption.

Insurers looking for a telematics provider can rely on the testing methodology shared in this guide to assess SDK performance across three key customer experience metrics. While results may vary slightly over time as SDKs continue to evolve, replicating these tests gives insurers a reliable way to identify partners offering the most performant and user-friendly solutions.