Device Insights Documentation
All you need to know in order to start using Device Data Collector (DDC) SDK.
Device Insights consists of three main components – the Device Data Collector (DDC) SDK, a machine learning platform, and prediction reports that can be imported or integrated into CRM tools, in order to drive retention and acquisition market activities.
Marakanda Device Insights is a prescriptive big data analytics solution that offers unique device and user behaviour insight for mobile operators and other telecom players. The DDC SDK is available for iOS and Android devices.
To get started with Marakanda Device Insights, you need to read the instructions below and download the necessary artefacts:
- Technical instructions and sample code – available on the Marakanda/eBuilder GitHub page (see below)
- DDC SDK – add as dependency to your project
- Licence key – acquired upon request to deviceinsight.sdk.support [at] ebuilder.com
- Public key for encryption – provided to Marakanda by tenant
Device Insights on Android
Device Insights on iOS
A licence key is necessary in order to use the DDC SDK. The licence key is available upon request by email to: deviceinsight.sdk.support [at] ebuilder.com
Data Encryption And Encryption Keys
Data is encrypted using a standard 2048 bit RSA key. Device Insights uses a key pair – a public and a private key – to encrypt / decrypt personal data. The operator must provide Marakanda with the public key.
Only sensitive DDC-SDK event attributes that can serve as identifiers for devices or for the persons operating the devices (such as deviceID, externalUserID or IMEI) are subject to anonymisation via encryption.
- Encryption takes place in the SDK installed in the host-app on the end-user’s smartphone using the public key.
- While Device Insights data is processed in the Marakanda back-end, the encrypted data stays encrypted.
- The tenant (operator) can then decrypt the data using the private key.
The DDC SDK uses less than 4 seconds of low CPU device processing time per day, From an end-user perspective, there is no impact on device and battery performance.
The DDC SDK is designed to run lean in the background. Device resource use and battery life impact is minimal and will not be noticeable for end-users.
The SDK can extract and upload device data when the host app is opened, based on a background scheduler (Android) or based on location updates (iOS). Normal configuration is to extract data once per hour and upload every second hour (configurable).
Extracting device data normally takes < 0.2 seconds and processing the upload takes < 0.4 seconds (+ network latency time) of low CPU background resource use.
With OS-based throttling of background services, we typically get ~10 samples uploaded at ~5 occasions every 24 hours. This results in a total SDK processing time of < 4 seconds per day.
The DDC SDK supports host apps that run on:
- Android 4.4 or later
- iOS v.9 or later
Depending on the OS-version, more than 50 unique data points are captured.
Encryption takes place within eBuilder’s DDC SDK, running on the mobile device where the tenant (operator/data controller) provides the public key to use for encryption as a parameter.
All processing of Device Insights data on eBuilder’s back-end (running at AWS) use the encrypted values.
The tenant can leverage eBuilder’s back-end reporting API to either display various reports graphically or to fetch Device Insights reports as compressed CSV files – these reports contain the encrypted values.
Decryption can be done using eBuilder’s decrypt-utility, running on the tenant’s computer. Using decrypt-utility requires the tenant to provide their secret, private key as a parameter.
The key set is owned and managed by the tenant and the public key is shared with eBuilder in order to encrypt data.
The settings required for ProGuard to exclude our SDK from obfuscation are available on the DDC SDK GitHub page. Make sure to follow the instructions to allow ProGuard to obfuscate the host app without interfering with the SDK code.
The big difference between the Android and the iOS SDK lies in the way we collect data.
Android has a time-based trigger that collects data on set time intervals, normally 2x per hour (scheduling can be adjusted). iOS has an activity trigger (initiated by activating the app or by location change), so the volume of data will depend on app usage as well as location permission.
Another difference is the variation in data parameters that can be collected.