Maintaining User Identity - The Signal 
Blog Post

Community Tip: Maintaining User Identity

Last edited: Jan 13, 2018
Customer Advocacy @ Mixpanel

This Community Tip focuses on the nuances of identity management to ensure users are tracked within your Mixpanel implementation. This post describes best practices for single users on multiple devices, multiple users on single devices, and tips for handling user logouts.

After you get started with Mixpanel, you will realize that identity management is one of the most important aspects of a Mixpanel integration. To attribute a user’s activity correctly, you must maintain the same unique identifier for a user throughout the course of their interactions with your app or site. Luckily, our SDK contains methods to manage this for both anonymous and authenticated users.

Single Users on Multiple Devices: Alias on Signup, Identify on Login

Nowadays, many users have multiple devices they can use to access their accounts – phones, laptops, and perhaps a tablet. How do you ensure that a user’s activity across this multitude of platforms actually connects back to the correct user?

The best practice is to call the alias method at registration (exactly one time during the lifetime of a user) and then the identify method on all future logins.

The function of the alias method (JavaScript / iOS / Android) is twofold: linking pre-authenticated activity with authenticated actions going forward, as well as enabling you to use your unique identifier in place of Mixpanel’s automatically generated Distinct Id once the alias call reaches Mixpanel’s datastore. In this way, the alias method allows you to continuously tie back your unique identifier to the same Distinct Id value in Mixpanel, attributing all actions to the same user.

The identify method (JavaScript / iOS / Android) will update the Distinct Id sent with future events. N.B. identify doesn’t send a tracking call (although it might flush enqueued calls depending on your platform).

For more information on these methods and their particular use cases, please see here for a detailed explanation with graphics explaining the process.

Multiple Users on Single Devices: Identify on Login, Reset on Logout

Now that you know the alias and identify methods help make sure that a user’s activity for multiple devices tracks back to the same user, what happens if you have multiple users on the same device? How do you ensure that each user has an individual profile and that multiple users’ activity doesn’t look like a single user?

In this particular scenario, if you keep track of users on your own server and there isn’t any pre-authenticated behavior that needs to be linked to the user, you don’t need to use the alias method. You can instead overwrite the default Distinct Id by immediately calling the identify method with your unique identifier (i.e. internal Id, username, email address) – this will cause all of the user’s activities to be tied back to the same unique identifier. If you have pre-authenticated behavior, you should still utilize the alias method to ensure a user’s Distinct Id stays consistent before and after signing up.

What’s really important here is that you need to think through how to handle logouts. When a user logs out, the Distinct Id by default does not change. It lives in the local storage (mobile) or cookie (browser) of the device to persist for future sessions, so it will only change if the identify method is explicitly called with a new value.

In order to properly handle multiple identities on the same device, you’ll want to add some additional code to the logout process. The syntax is a little different for each library, but the impact is the same – you are resetting the Distinct Id and removing all existing super properties. We include this sample code in the following section as examples of resetting a user profile in each of our client-side libraries.

While resetting users is useful if you have many users on the same device, it does have some undesirable effects. First, all events for logged out users will appear anonymous, meaning the unique user counts for these events will not be correct. In addition, because you remove super properties, you will need to again register these for each user on login.

Ultimately the tradeoff for the above drawbacks is that each profile is one unique user within your implementation. We typically only recommend implementing the above if you anticipate this scenario happening as the norm – if multiple users on the same device is not common, implementing logic on logout to handle this scenario may be more trouble than it is worth.

Handling Logouts on Client-side Libraries

For JavaScript, calling the reset method will clear the Distinct Id and all super properties, as well as generate a new Distinct Id for the user.


For Android, calling the reset method will clear the Distinct Id and all super properties, as well as generate a new Distinct Id for the user. If the next person who signs on already has an account, then they’ll trigger the identify method and their activity will map back to their existing profile. If they don’t have a profile, they’ll have a new Distinct Id and create a new profile as they interact with your site or app.


For iOS, the Distinct Id defaults to the IFA (Identifier for Advertisers) if Ad Support Framework is included; otherwise the IFV (Identifier for Vendors) of the device is used. When you call the reset method it will reset super properties, but the Distinct Id will always be associated with that device due to the way IFA/IFV is managed. What you’ll need to do is generate a new UUID and pass this as an argument to the identify method in order to reset the Distinct Id to be anonymous for the next user.

[mixpanel reset];
NSString *uuid = [[NSUUID UUID] UUIDString];
[mixpanel identify:uuid];

Questions as to how you should implement identity management given your specific scenario? Reach out to to speak to someone smart, quickly.

Get the latest from Mixpanel
This field is required.