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 launched connected programs, three key metrics 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. Ignoring even one of them can jeopardize the scalability of connected programs, and the reliability of connected services such as crash detection.

To help auto insurers identify the best-in-class telematics SDKs, we have defined a testing methodology, which we share in this content, along with our findings. Our ultimate goal is to provide insurance teams with a reliable framework to replicate these tests, and gain deeper insights into how an SDK’s technical performance directly impacts user satisfaction and engagement.

Trip Detection Rate

Detecting trips

As mentioned earlier, the trip detection rate reflects how well an SDK can automatically identify all 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. We believe that 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 this article, 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 TSPs compensate for this by completing the trip. They 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. This strategy is called “auto completion”. In some cases, that improves the user interface because the trip is displayed with the correct starting point in the app. 

However, other TSPs including DriveQuant do not use this strategy for two main reasons:

• We chose to display only the part of the trip where driving data is actually collected. Auto completing the trip does not bring any information about the behavior of the driver during this part of the trip. Auto completion is a nice visual enhancement but does not improve the data analysis. Trips with auto-completion and trips without auto-completion provide insurers with the same volume of driving data.

• Auto completion can lead to confusion and create mistakes. Our tests reveal that around 15% of trips using auto-completion 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.

To sum up, while auto-completion seems to provide greater trip accuracy, insurers should keep in mind that it is only a visual enhancement that is not without risk. 

• In the context of Pay-How-You-Drive programs, auto-completion does not bring any additional value as there is no behavioural 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” (link here), auto-completion is not relevant as telematics apps should be combined with a beacon.

When comparing telematics SDKs, insurers can quickly identify those using auto-completion by opening the app and checking 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 customer complaints.

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, iPhone 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 400mo 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 Go per month. That being said, these SDKs track all types of mobility, including footwalk, which results in increased data consumption.

Conclusion

The tests reflect the capabilities of 5 telematics SDKs to provide a top-notch customer experience. Results show that DriveKit likely delivers the most balanced customer experience, as it detects all motorised trips without impacting the phone’s battery life. Even though SDK A is ahead by a short margin in terms of data usage, DriveKit ranks second, with a very low data consumption.

Even though all telematics SDKs offer almost similar trip detection capabilities, there are strong differences in battery and data consumption. From an insurer point of view, these metrics should be considered as the pillars of any successful connected programs: 

• 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.  

For all these reasons, insurers should conduct their own tests to identify the best-in-class telematics SDKs that will deliver a positive customer experience. Insurance teams replicating the testing method presented above will likely find slightly different results as all telematics SDKs continue to improve. But what matters is that they won’t compromise the success of their connected program by opting for a telematics SDK that does not perform well on the three most essential functionalities: trip detection, battery usage and data consumption.