Introduction
The success of a connected insurance product that uses smartphones is highly dependent on the technology used to collect and process data. A connected insurance product consists of a mobile application developed by the insurer, with telematics functionality to record and analyze data from the smartphone's sensors.
Traditionally, this functionality is developed by a telematics provider and incorporated into the insurer's application via a mobile Software Development Kit (SDK).
The telematics provider is responsible for data collection and analysis. Data is transformed into indicators reflecting driving behaviour. These indicators are then used by the insurer to calculate the insurance premium and for prevention purposes.
If you are considering launching smartphone-based connected insurance, it is crucial to evaluate the technology offered by each telematics provider. To guide you in this decision, this article proposes an inventory of essential aspects to verify:
-
The resources available for testing the solution.
-
The performance of the mobile SDK.
-
The technical documentation.
-
The update frequency.
-
The technical support.
-
The methods for accessing data.
The resources available for testing the solution
First, it's essential to assess the supplier's technology in real-life conditions. To avoid technical development, the supplier should be able to provide a ready-to-use demo application using its mobile Software Development Kit (SDK).
This application is designed to help you understand the user experience and evaluate the performance of the technology, including :
- obtaining the necessary permissions to access the phone's sensors,
- recording trips,
- and displaying driving data.
A supplier should offer you quick and easy access to a demo application. For a comprehensive and detailed evaluation, we suggest involving around ten people from your organization and running tests on iOS and Android smartphones for at least a month.
The DriveQuant application is powered by the DriveKit SDK, and uses the same technology we supply to our customers. It is available on the AppStore and Google Play.
The performance of the mobile SDK
There are two main factors to consider when evaluating a smartphone telematics solution.
Firstly, you need to verify the SDK's ability to automatically detect vehicle movements and record a user's entire trips. This is why, once the test application has been installed on your phone, you need to make sure that all your trips have been correctly analysed.
Secondly, battery consumption must be as low as possible, as this is a key criterion for the user experience. A telematics solution runs in background and uses the GPS sensor.
Excessive use of the GPS sensor can significantly reduce the phone's autonomy, which can lead users to uninstall the application.
The DriveKit SDK has been designed to minimize battery consumption by not using the GPS sensor when not driving. Automatic trip detection relies on a combination of low-power mechanisms, such as the Activity Recognition API, SLC on iOS, the use of geozones, detection by the vehicle's Bluetooth system or Android Auto, and in some cases the use of an iBeacon-type Bluetooth transmitter.
All these mechanisms work together to guarantee optimal trip capture. To find out more, we invite you to read the article explaining how automatic mode works in the DriveKit SDK.
When testing, check battery drain after a day's use and use the following order of magnitude as a reference: the battery drain caused by a telematics application should be less than 2% for a user who makes two 30-minute trips a day.
The technical documentation
A smartphone telematics SDK comes with detailed technical documentation for developers. The documentation facilitates the integration, understanding, and troubleshooting of issues related to using the SDK in a mobile application.
Most of the time, the documentation is freely accessible and should contain:
-
Detailed instructions on installing, using, and integrating the SDK into a mobile application
-
A description of the SDK's features, methods, and parameters
-
Code examples and tips that help developers quickly integrate the SDK
-
A history of updates and the introduction of new features, allowing developers to take full advantage of the latest versions
A well-documented SDK reflects the quality of the solution. What's more, a generic SDK maintained by a team of specialists guarantees the durability and reliability of the solution.
The more integrated the SDK, the better it performs, since technical improvements, new functions and bug fixes are shared and benefit all customers.
DriveQuant's DriveKit SDK documentation is freely available.
To simplify integration into our customers' applications, we offer :
-
a project containing the necessary code for a quick start-up on iOS and Android
-
an open-source iOS and Android application that implements all DriveKit SDK features.
The update frequency
A telematics SDK needs to be updated regularly. Updates are essential because the underlying technology is evolving rapidly:
-
iOS and Android operating system updates
-
Changes to the AppStore Connect and Google Play consoles.
-
Deployment of new functionalities.
-
Bug fixes.
-
Improvements based on user feedback.
-
Security updates.
In general, a popular telematics SDK should have a regular release cycle, with at least one monthly update. You should also check that the SDK update takes place immediately after the deployment of new versions of iOS and Android (in September).
The DriveKit SDK changelog is freely available in our public documentation.
The technical support
A telematics SDK is a technology that sometimes requires expert assistance to accelerate the installation into an existing application. Make sure this is a service provided by your supplier.
Support plays a crucial role in the successful integration of mobile telematics SDKs for several reasons:
-
Mobile developers who primarily focus on coding graphical interfaces may find working with telematics technology unfamiliar, especially when it comes to managing sensors and obtaining the necessary permissions for a telematics application to operate correctly.
-
A telematics SDK contains numerous configurations and guidance is essential to make the best possible use of it.
-
The SDK provides very rich but also very specific data that needs to be well understood to display on the application's graphical interfaces.
In addition to comprehensive documentation and open-source code, DriveQuant offers support to technical teams throughout the installation phase of the DriveKit SDK in your application and also participates in testing to validate that the integration complies with your needs.
The methods for accessing data
The main role of a telematics solution is to produce driving behavior indicators. These are used directly to estimate risk levels, calculate insurance premiums or manage claims. This is why the methods used to access this data are essential.
The first aspect to consider is the processing time. It is essential that analysis results and driving indicators are available immediately after a trip or an accident.
In the case of a trip, it is better for the driver to be able to access the results of the analysis after the trip has been completed. In some cases, trip data is also processed on the insurer's platform to complete the analysis.
For an assistance solution, accident data needs to be transmitted very quickly, since it can be used to trigger an alert and is used by an operator to make decisions.
The second aspect is the nature of the data. A telematics provider must be able to share not just the data resulting from the analysis, but also the raw data recorded by the phone's sensors, and possibly intermediate data (e.g. filtering, anomaly correction, map projection).
The third aspect concerns data access methods. Ideally, a supplier's solution should offer the possibility of accessing driving indicators and collected data by several methods:
-
from the mobile SDK, if possible with data already synchronized in a local database. This approach enables direct, instant access to data for user display in the mobile application.
-
using web services to retrieve trip or accident data from your platform.
-
through a web administration interface that includes clearly presented results and management functionalities (such as user search, visualization of trip data and score history).
The trip analysis lifecycle using DriveQuant's DriveKit SDK is described here.
With the DriveQuant solution, the time required to analyze a trip is always less than 4 seconds, and once analyzed, the data is synchronized in the SDK and transmitted to the customer's platform via a publication service.
For other needs, DriveQuant offers a web administration interface and a full range of web services to access user data. These services are described in the “REST SERVICES” section of our public documentation.
Conclusion
Smartphone telematics is recognized for its reliability, but its complexity requires a thorough evaluation of the solution offered by a provider.
A high-performance, reliable solution must meet at least the following nine conditions:
-
The SDK must be easy to test with a demo application.
-
The automatic mode must be efficient and detect all trips.
-
The SDK must not cause excessive consumption of the phone's battery.
-
The SDK must be generic, but offer sufficient configurations to adapt to a variety of use cases.
-
The SDK should already have been integrated into at least 20 mobile applications.
-
Documentation should be accessible, clear and include code samples.
-
The SDK must be updated regularly, at least once a month.
-
The supplier must be able to provide experts to support your technical team during the SDK installation phase.
-
Access to collected data and driving indicators must be possible via the SDK, APIs and a web portal.
