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.
To get started with Marakanda Device Insights, you need to read the instructions below and download the necessary artefacts:
DDC manual and sample code on GitHub
DDC Manual and sample code on GitHub
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.
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:
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.