There are times when the same user may be active on several devices (Mobile, PC, Tablet, etc). Being able to associate user activities, across different devices or applications, to the same user may reveal important insights, and have an affect on overall business performance.
Cooladata provides a mechanism to associate user activities from various devices to the same user identity. We will detail this mechanism below. You are welcome to contact firstname.lastname@example.org with any additional questions you might have.
Consider the following business scenario:
- A user installs a game on their Mobile device.
- The user plays the game and registers.
- The user then installs the same game onto their Tablet.
- The user plays and logs in with their Facebook identity.
How many users would you count in this scenario? The worst case scenario is that your analytics platform treats the interactions of this single user as four different users:
- Interactions on Mobile pre-registration would be counted as one user (1).
- Interactions on Mobile post-registration would be counted as one user (2).
- Interactions on Tablet pre-login would be counted as another user (3).
- Interactions on Tablet post-login would be counted as another user (4).
A better strategy would be to track all these interactions as a single user.
How should you track this with Cooladata?
Any Event that is sent to Cooladata must provide the Property user_id. Cooladata expects you to use the user_id property to send a constant anonymous user ID, which is available for the application at any time.
In addition to that, with any event you can provide a user_alternative_id (Alias) as an Event Property. Cooladata expects you to provide the user_alternative_id when the user registered and you can gain access for a registered user ID.
Once an event is sent with a user_id and user_alternative_id together, Cooladata will associate all events from this registered user, based on user_alternative_id, to the pre-registered user, based on user_id.
Let’s review the five steps scenario as Cooladata expects you to track it:
|Scenario Step||user_id||user_alternative_id (Alias)||uid|
|1||1234||NA||CoolaData generated 'abc'|
|2||1234||999||1234 and 999 events are mapped to 'abc'|
|3||6789||NA||CoolaData generated 'xyz'|
|4||6789||999||Mapped to 'abc'|
When you use one of CoolaData’s Trackers, CoolaData automatically enriches each event with a user_id that uniquely identifies the end user who performed the event. This user_id is saved as a CoolaData cookie on the device that generated the event and is uniquely associated with that user_id.
Sending your own user ID
In addition, you have the option to add your own user_id to each event. To assign your own user_id to an event add a property named user_id to the JSON sent to CoolaData.
Note – When you use the CoolaData REST API to send events, CoolaData does not automatically generate a user_id. In order to manage user IDs, you must add the user_id property to each event, or send it with the tracker init.
If you added your own user_id to an event then CoolaData stored the user_id that you sent as customer_user_id, the user_id that CoolaData automatically generated (as a cookie on the device) as internal_user_id. Both types are treated as the same user and maintain a one-to-one relationship between them.
Consolidating multiple users
In addition to the above, you may want CoolaData to manage multiple users as a single entity. This may be useful when you want CoolaData to consolidate the events of users that log in anonymously (or with a different login name) on the same computer or users that log in using the same name on a different computer.
To consolidate multiple users:
- Add an alternative_user_id property containing your website/app login name to an event along with a user_id property. This will map multiple customer user IDs to the same internal_user_id.
- The two IDs only need to be sent once to make the connection. Sending them again will have no impact.
- Sending the 2 user identities for coupling can be done either by sending them together in an event or by using the user identities matching API.
- To display the user_id that you sent to CoolaData, query the customer_user_id property.
- For better performance, in CQL queries, use user_id whenever possible instead of the customer_user_id or alternative_user_id.
User management at Cooladata
Cooladata’s data model manages three user_id fields: customer_user_id, user_id and user_alternative_id.
customer_user_id is a mandatory property in any event that is being sent to Cooladata. Use this Property to send the anonymous ID, which is available at all times. In most cases this is an ID that is saved in a cookie called cd_user_id.
user_alternative_id (Alias) is an additional user property. You can send it with any event you choose and it’s not mandatory. This Property should be used when your user identifies themselves uniquely for the first time (e.g. via logging-in), and you can send it when available. It should be sent together with the user_id you send with any event.
user_id is managed by Cooladata and is used to keep a coherent user identity. The user management module of the Cooladata platform generates the user_id to keep track of the various interactions and map all interactions to a global user ID.
Important note: the user matching mechanism (user_alternative_id) is currently in beta. to use it, contact email@example.com – This feature will not be active prior to contacting us.
Other scenarios that can impact counts:
IOS – iTunes & App Stores – Automatic Downloads
Apple may install an app of multiple device from a single install event. Users install the app on their mobile device and the user iOS configuration (Settings -> iTunes and App Store) may enable Apple to automatically install the same app on additional devices such as tablets or mac owned by the same user.
Many customers send an install event from their mobile measurement provider (such as AppsFlyer or Kochava). In this case, you will see activity from devices that never had an install event.
If you are using IDfV (ID for Vendor) for the individual user, you will also see two users, where it is the same user with different devices.
As a result you may prefer generating an id per user per app and send the device as a property instead of using the IDfv.
This may also help when users continue a session between different devices using IOS8 Handoff.
How User IDs are Assigned in CoolaData:
CoolaData assigns a user_id so that it will persist across sessions. If applicable, we also persist the user ID across apps and upon installs and uninstalls. The following text details how user ID assigned in various platforms.
If the app is using the AdSupport.framework, we’ll use the Advertising Identifier.
For apps that do not have the AdSupport.framework included, CoolaData will default to using the identifierForVendor as the user_id.
If the app is using Google Play services 4.0+, then we’ll use AdvertisingIdClient.
If the app working with the READ_PHONE_STATE permission, then we get Secure.ANDROID_ID; otherwise, use UUID.randomUUID().
User Time to Expire
The data you tracked is saved in Cooladata indefinitely.
However, user ID associations are kept for up to 90 days. Users that have not been active for more than 90 days will be treated as new users. This means that they will not be associated with any data previously provided about them. Note that users can be assigned multiple IDs, and logging in using any of the ID’s associated with them will keep them active in Cooladata for an additional 90 days. To update user’s data after more than 90 days, send the data again with one of the first events once they’ve logged in to the system.