ID Merge: Implementation Best Practices

We recently conducted a Webinar on ID management and I thought of extending it with a blog post so here it is!

Introduction

Users might use different browsers, move from a mobile device to a laptop, or periodically clear browsing data. Mixpanel's identity management system offers the ability to link users’ movements across different platforms, giving a holistic view of the user journey.

Mixpanel is able to link together a user’s journey by using our identity management system to create identity clusters that group together collections of distinct_ids that connect to an individual user. This results in accurate reporting by properly attributing events to the user that performs them, regardless of the device they are presently using.

Understanding how to use Mixpanel’s identity management greatly expands your ability to glean actionable insight from event data.

Benefits of Mixpanel’s Identity Merge

Mixpanel’s Identity merge is a more robust identity management to its legacy ID management.

Pre and post-authenticated events across devices are linked correctly
- Accurate reporting of “unique” users and conversion in Funnels
- Avoid orphaned events and duplicated user profiles
Ability to use multiple identifiers from different sources to refer to one user
Improve identity management troubleshooting
- New $identify, $create_alias, and $merge events (does not count towards MTU)
- Visibility into user’s identity cluster

We’ll be seeing the relevance of these benefits in the later sections when we go through an example.

Identity Management 101

Some Terms that is commonly seen

Distinct ID- Mixpanel’s unique identifier used to link events for a specific user on a specific platform (case-sensitive)

Identity Cluster- Mixpanel connects all of the same user’s Distinct IDs across platforms and tracks that in a cluster

Canonical ID- Mixpanel applies logic to the cluster to determine which Distinct ID is used as the main identifier

Taking an example of a standard use case

On Day 1, let’s say Charlie, a user, has discovered your platform and has come onto your website for the very first time. Once Mixpanel is initiated, the SDK will generate a random distinct id for Charlie and all events triggered by Charlie would be associated to that distinct id profile.

Later on that day, Charlie decides to register/ sign-up on your platform. At this point, on a successful registration, the code should callmixpanel.identify("Charlie");whereCharlieis the product’s internal user_id.

On successful identify call, the user idCharlieis appended to the identity cluster and pre and post registration/ sign-up events are associated to the same profile giving you the complete journey of Charlie on the website

At some point in Charlie’s journey, he decides to download your mobile application. Here, on opening the application for the very first time, on initialisation of Mixpanel’s SDK, a random distinct id would be generated since Charlie is anonymous on the platform (he is yet to log in).

When Charlie logs in, the code should again callmixpanel.identify("Charlie");and this would ensure all events pre and post log-in would be associated to the same profile giving you the complete user journey of Charlie on your Product on multiple platforms

Best Practise:Call identify() on a successful sign-up / login or when an app is re-opened in a logged in state.

More about Identity Cluster

Each identity cluster is limited to a maximum 500 unique Distinct IDs. Once a cluster reaches the limit, a new Distinct ID will no longer be merged. The events associated with the new un-merged Distinct ID will become orphan (ie not linked to the same identity cluster).Calling reset() frequently can result to hitting this 500 limit within a short time.

Merging identities may take up to 24 hours to properly reflect in Mixpanel reports (except Activity Feed). A Canonical ID is chosen based on optimal merging performance. If two merging clusters both have profiles the non-canonical cluster’s profile will automatically be hidden.

Any Distinct ID in a cluster can be used to query and track information about a user (using Mixpanel SDK / APIs). The Distinct ID returned in the result will always be the Canonical ID.

Troubleshooting ID management Implementation

A User’s Profile page allows you to see all the distinct ids and user ids in the identity cluster and all events fired in the user’s journey across platform, pre and post authentication.

Additionally, Mixpanel automatically triggers events to help facilitate identity troubleshooting

Best Practises when Creating User Profiles

Assign your own unique user ID as one of the Distinct IDs in the Identity Cluster by using Mixpanel’s Identity methods
Avoid creating anonymous user profiles - ie calling people.set() and identify(<anonymous_id>)
If possible, cache user properties until after calling identify(<known_id>) or alias(<other_id>, <known_id>)
Populate your “App User ID” as a Super Property and User Property to facilitate identity troubleshooting.
Ensure all events for the same user are linked to the same identity cluster since a user that belongs to different identity clusters will be considered as different users in Mixpanel, causing reports (Funnels, Flows, Retention, etc.) to be incorrect.
Recommended places to call identify(): On successful sign-up or login and when an application is opened in a logged-in state.

Additional resources

Want to discuss further or find out more? Join us on Slack