Push Diagnosis Data
Introduction
The DriveKit SDK regularly collects information on the smartphone's configuration: application permissions, sensor statuses and any user-generated events.
The push diagnosis data service is designed to share all diagnosis data collected by the DriveKit SDK installed on each of your users' mobile applications with your platform.
These insights can be used to:
Identify users facing configuration issues, which may improve the onboarding experience
Detect trip recording issues caused by user events (logout, app uninstallation, phone shutdown...)
Principle
The diagnosis data push service sends the diagnosis events right after they are transmitted by the DriveKit SDK to the DriveQuant platform. The process is described below:
The DriveKit SDK collects the diagnosis data, which is stored locally on the user's phone.
The DriveKit SDK sends the diagnosis data to the DriveQuant platform at least one a day. There is no precise time for data retrieval, as this depends on the state of the application and the smartphone.
If you subscribe to the push diagnosis data service, the data is transmitted to your platform as soon as it is received and stored on the DriveQuant platform.
All diagnostic events are shared after an initial installation and initialization of the DriveKit SDK. The initial push diagnosis data is delayed by at least 30 minutes in order to give the user time to grant permissions.
The push is triggered by the SDK, which sends information once a day even if there are no changes in diagnostic indicators. An empty push means that there are no changes. The daily push, even if empty, confirms that the application is still installed and active on the user's phone.
Configuration
See Configuration in the parent section.
The body of the request is a JSON object with a set of fields that contain the driving scores organized by categories and the raw data collected on the user smartphone stored in tables. An example of data in JSON format is given at the end of this section.
Your service should respond with a 2xx http status code (typically 200 OK) when the push request is accepted. Any other code will be considered as a failure, and the service will attempt to send the data again as defined in the Retry Policy section.
If your service responds with a 2xx http status code, while the data has not been accepted by your platform, then there will be no further attempt to send the data!
Retry Policy
Every push request not successfully acknowledged by your service will be retried once a day. Also, the failed events will be sent every time the SDK sends an update, and before sending any new event. After 30 unsuccessful attempts, the push data will be permanently discarded.
Sample Message
The body of the request is a JSON object with a set of fields containing the user unique identifier, the user's smartphone data, and a list of the events collected by the SDK, divided into 4 categories:
permissions: events related to the application’s permissions
sensors: events related to the smartphone’s sensors
settings: events related to the smartphone’s configuration
events: events related to user's events (login/logout, app install/uninstall, smartphone on/off)
The table below lists the types of diagnosis data and their possible values.
permissions
NOTIFICATION_ACCESS
GRANTED / DENIED
permissions
LOCATION_ACCESS
GRANTED / DENIED
permissions
BLUETOOTH_ACCESS
GRANTED / DENIED
permissions
ACTIVITY_ACCESS
GRANTED / DENIED
sensors
GPS_SENSOR
ENABLED / DISABLED
sensors
BLUETOOTH_SENSOR
ENABLED / DISABLED
settings
LOW_POWER_MODE
ENABLED / DISABLED
settings
PERMISSIONS_AUTO_DELETE
ENABLED / DISABLED
settings
BATTERY_OPTIMISATION
ENABLED / DISABLED
events
PHONE_STATE
TURNED_ON / TURNED_OFF
events
APP_STATE
INSTALLED / UNINSTALLED
events
LOGIN_STATE
LOGGED_IN / LOGGED_OUT
The OpenAPI specification can be downloaded here in OpenAPI YAML format.
Last updated
Was this helpful?

