Mixpanel SDKs and Common Scenarios
Mixpanels client-side SDKs help reduce the overhead for identity management drastically. When a client-side SDK is initialized, Mixpanel automatically generates and stores a distinct_id value with which to track user activity on the device. This value is typically used to track anonymous activity. Once a user can be identified, the identify method should be called with the newly chosen identified value.
Calling identify causes several things to happen. If the new distinct_id value you are identifying with is different from the currently stored distinct_id value, an $identify event will be tracked with your chosen distinct id value as the $identifed_id and the locally stored distinct_id as the $anon_id. Additionally, the locally stored distinct_id value will change to that of the $identified_id.
This means future activity from the device will be sent to Mixpanel with the newly stored distinct_id value. If a new user begins using that device their activity would also be tracked with that distinct_id. To account for cases of multiple users on a single device, Mixpanel’s client-side SDKs have a reset method.
Reset will clear the device’s Mixpanel stored data and generate a new anonymous distinct_id for the device. This method should be used once a user’s session has ended (at logout for example). With reset, you can attribute pre and post-login activity to different users on one device.
Reset for iOS
Mixpanel's iOS libraries use the identifier for advertisers (IFA) to track activity instead of generating a random distinct_id. Calling reset will always reset the distinct_id to the IFA. If you want to track multiple users' anonymous activity on iOS you can set a preprocessor flag to have Mixpanel generate a random distinct_id using the steps seen in our developer documentation (Objective-C and Swift).
Mixpanel's server-side SDKs do not store or generate distinct_id values. When tracking user activity from your server, the implementer is responsible for including the distinct_id when tracking any event or profile update. As such you will need to provide both distinct_ids when aliasing or using $merge from the server. If you want to merge distinct_ids from the server, the $merge event is often simplest as it has fewer guardrails to consider.
Implementations that track activity on both the client and server will need to pass distinct_id values between locations. If passing a distinct_id from your server to the client, you can use the identify method to merge that server id to the anonymous client-side distinct_id. If passing from client to server, use the $merge event to merge the distinct_ids.