The Challenge

Consider the following business scenario:

1. A user installs a game on their Mobile device.
2. The user plays the game and registers.
3. The user then installs the same game onto their Tablet.
4. 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:

1. Interactions on Mobile pre-registration would be counted as one user (1).
2. Interactions on Mobile post-registration would be counted as one user (2).
3. Interactions on Tablet pre-login would be counted as another user (3).
4. 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 Journey Analytics?

Any Event that is sent to Journey Analytics must provide the Property user_id. Journey Analytics 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. Journey Analytics 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, Journey Analytics 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 Journey Analytics expects you to track it:

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 Journey Analytics.

Note – When you use the Journey Analytics REST API to send events, Journey Analytics 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 Journey Analytics stored the user_id that you sent as customer_user_id, the user_id that Journey Analytics 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 Journey Analytics to manage multiple users as a single entity. This may be useful when you want Journey Analytics 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.

Tips:

• To display the user_id that you sent to Journey Analytics, 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 Journey Analytics

Journey Analytics'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 Journey Analytics. 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 Journey Analytics and is used to keep a coherent user identity. The user management module of the Journey Analytics 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 Medallia Support – 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 Journey Analytics:

Journey Analytics 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.

JavaScript

The Journey Analytics JavaScript SDK automatically generates a unique user ID. The user ID is generated the first time the library is called, and stored in a cookie for future usage. The cookie is stored by default for one year, and applicable for the top-level domain.

iOS

If the app is using the AdSupport.framework, we'll use the Advertising Identifier.For apps that do not have the AdSupport.framework included, Journey Analytics will default to using the identifierForVendor as the user_id.

Android

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 Journey Analytics 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 Journey Analytics 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.