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.

circle-info

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.

triangle-exclamation

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:

  1. permissions: events related to the application’s permissions

  2. sensors: events related to the smartphone’s sensors

  3. settings: events related to the smartphone’s configuration

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

Category
Type
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 herearrow-up-right in OpenAPI YAML format.

chevron-rightSample message (click to expand)hashtag

Last updated

Was this helpful?