Understanding Mixpanel's Legacy ID Management and Distinct IDs | Mixpanel Community

Understanding Mixpanel's Legacy ID Management and Distinct IDs

In my Mixpanel project, the Merge ID setting shows: "This project does not have ID Merge enabled." This means my project is using the Legacy ID Management system. However, in the data, I see that some distinct_id values have a $device: prefix. Can you explain what this means under the Legacy ID Management? Also, I thought that in Legacy ID Management, the distinct_id does not change until the user logs out. But in my data, I see a single distinct_id associated with more than two different user_ids. Can you help explain why this happens?

17 comments

kapa.ai
APP
·
·
Hi Thang D., Please stand by as I search the Mixpanel knowledge base for an AI-powered answer. I normally take about 15 seconds or so. In case AI cannot answer your question, feel free to reach out to Mixpanel support at mixpanel.com/get-support. If you have follow-up questions for this thread, please tag me again with your question: @kapa.ai <follow-up question> 👋
Feel free to ask a follow-up question once I've answered by mentioning me with @kapa.ai
kapa.ai
APP
·
·
Certainly! Here’s what the knowledge sources say about your situation:
1. $device: Prefix in distinct_id under Legacy ID Management
Under Legacy ID Management, Mixpanel did not natively use the $device: prefix for distinct_id values. The $device: prefix is a convention introduced with the Simplified ID Merge system, where anonymous users are tracked with a $device_id, and Mixpanel sets the distinct_id as $device:<device_id> for anonymous events. In Legacy, the distinct_id was typically just a randomly generated value (often a UUID) for anonymous users, and then switched to a user identifier upon login or identification.If you are seeing distinct_id values with a $device: prefix in a project that claims to be on Legacy ID Management, this is unexpected based on the official documentation. It may indicate that: - Some events were ingested using a newer SDK or integration that applies the newer convention, even though the project is set to Legacy. - There may have been a migration or partial update in your implementation, or data was imported from another project using a different ID management system.The documentation does not explicitly describe $device: prefixes appearing in Legacy projects, so this is not standard behavior for Legacy ID Management Understanding Simplified ID Merge.
2. distinct_id Associated with Multiple user_ids in Legacy
In Legacy ID Management, the distinct_id is supposed to represent a single user until logout or reset. When a user logs in, the distinct_id is typically set to their user ID, and when they log out, it is reset to a new anonymous ID. The documentation states that aliasing (linking anonymous and identified states) can only be done once, and subsequent attempts to alias the same user ID to a different anonymous ID will fail Deciding to Migrate.If you are seeing a single distinct_id associated with more than two different user_ids, this is not expected in Legacy ID Management. Possible explanations (not directly covered in the documentation) could include: - Custom or non-standard implementation that reuses or incorrectly assigns distinct_id values. - Data imported or merged from other projects or systems with different ID management logic. - Use of SDKs or integrations that do not strictly follow the Legacy conventions.
Summary
- The $device: prefix in distinct_id is not standard for Legacy ID Management and is a convention from newer ID Merge systems. - In Legacy, a distinct_id should not be associated with multiple user_ids; if you see this, it likely results from custom implementation, data import, or SDK behavior outside the documented Legacy flow.If you need to ensure correct identity management, consider reviewing your SDK versions, event ingestion methods, and any data import processes for consistency with your project's ID management setting.If you need more precise troubleshooting, you may need to audit your implementation or contact Mixpanel support, as the documentation does not provide further details on this scenario.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thang D.
·
·
kapa.ai In the data, I see 4 types of distinct_id values: The distinct_id is the same as the user_id. The distinct_id is a device_id. The distinct_id has a $device: prefix. The distinct_id is neither a user_id nor a device_id. Can you help why this happen in Legacy ID Management?
kapa.ai
APP
·
·
Let me check the knowledge base for you again. One moment! 📚
kapa.ai
APP
·
·
Based on the knowledge sources, here’s what can be determined about the types of distinct_id values you’re seeing in your Mixpanel project with Legacy ID Management:
1. distinct_id is the same as user_id
This is expected in Legacy ID Management. When a user logs in or is identified, the distinct_id is typically set to their user ID. This allows tracking of events to the identified user moving forward Identifying Users (Original) - Example User Flows.
2. distinct_id is a device_id
This is also standard. For anonymous users (before login or identification), the SDK generates a random device ID (often a UUID) and uses it as the distinct_id for all events from that device/session Identifying Users (Original) - Example User Flows.
3. distinct_id has a $device: prefix
This is not standard behavior for Legacy ID Management. The $device: prefix is a convention introduced with the Simplified ID Merge system, where anonymous events have distinct_id values like $device:<device_id> . The documentation does not mention this prefix being used in Legacy projects. If you see this, it may be due to: - Events being ingested using a newer SDK or integration that applies the newer convention, even though the project is set to Legacy. - Data imported from another project or system using a different ID management version.The knowledge sources do not provide an explicit explanation for $device: prefixes appearing in Legacy projects Understanding Simplified ID Merge.
4. distinct_id is neither a user_id nor a device_id
In Legacy ID Management, the distinct_id should be either the anonymous device ID or the user ID. If you see other values, possible reasons (not directly covered in the documentation) could include: - Custom assignment of distinct_id in your implementation. - Data imported or merged from other sources. - Use of static or arbitrary values for distinct_id in some events (e.g., for non-user-attributable events, as described in Hot Shard Limits).
Summary
- User ID and device ID as distinct_id: Expected in Legacy. - $device: prefix: Not standard in Legacy; likely from newer SDKs or data imports. - Other values: Could be due to custom implementation or data import, but not described in the official documentation.If you need to ensure correct identity management, review your SDK versions, event ingestion methods, and any data import processes for consistency with your project's ID management setting. The knowledge sources do not provide further details on these anomalies in Legacy ID Management.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thang D.
·
·
kapa.ai Why does a user have more than one distinct_id in Legacy ID Management?
kapa.ai
APP
·
·
Let me check the knowledge base for you again. One moment! 📚
kapa.ai
APP
·
·
In Legacy ID Management, a user can have more than one distinct_id because Mixpanel does not automatically merge anonymous and identified user states across devices or sessions. When a user is anonymous, they are assigned a randomly generated distinct_id (often a device ID). When they log in or register, their distinct_id typically changes to their user ID. However, if the same user interacts with your product on multiple devices or browsers, each session will generate a new anonymous distinct_id until the user logs in on that device. As a result, the same user can end up with multiple distinct_id values—one for each device or session before identification, and one for their user ID after identification.Additionally, in Legacy ID Management, aliasing (linking anonymous and identified states) can only be done once, and subsequent attempts to alias the same user ID to a different anonymous ID will fail. This limitation can lead to "orphaned" anonymous events and multiple distinct_ids for the same user, especially if they use multiple devices or clear cookies between sessions. This prevents Mixpanel from providing a holistic view of the user's journey across devices and sessions Deciding to Migrate.In summary, under Legacy ID Management, a user can have more than one distinct_id because there is no automatic merging of identities across devices or sessions, and aliasing is limited.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thang D.
·
·
kapa.ai In a user flow, the distinct_id is initially set to the device_id, and the user_id is null. Later, in some events, the user_id becomes not null, but the distinct_id stays the same. Can you explain why this happens?
kapa.ai
APP
·
·
Let me check the knowledge base for you again. One moment! 📚
kapa.ai
APP
·
·
In Legacy ID Management, the expected behavior is that when a user is anonymous, the distinct_id is set to the device ID (often a randomly generated value), and the user_id is null. When the user logs in or is identified, the distinct_id should typically switch to the user ID. However, if you observe that after the user is identified (i.e., user_id becomes not null), the distinct_id remains as the device ID, this suggests that the identification step did not update the distinct_id as expected.The knowledge sources do not provide a detailed explanation for this specific scenario in Legacy ID Management. In the documented flows, after calling .identify(user_id), Mixpanel is expected to use the user ID as the distinct_id for subsequent events, not continue using the device ID Identifying Users (Original) - Example User Flows.Possible reasons for this behavior, based on the documentation, could include: - The .identify() method was not called correctly, or not called at all. - There is a custom implementation or event ingestion method that continues to set the distinct_id to the device ID even after identification. - The SDK or integration being used does not follow the standard Legacy ID Management flow.However, the knowledge sources do not explicitly describe a scenario in Legacy ID Management where user_id becomes not null but distinct_id remains as the device ID. Therefore, I'm sorry, but there's no information in the knowledge sources that fully explains why this happens in Legacy ID Management.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thang D.
·
·
kapa.ai Why do many events have a user_id that is null? For example, the event answer_attempt_submission always has a null user_id. Can you explain why this happens and let me know which other events have the same issue?
kapa.ai
APP
·
·
Let me check the knowledge base for you again. One moment! 📚
kapa.ai
APP
·
·
Events in Mixpanel often have a user_id that is null when they are triggered by users who have not yet been identified (i.e., are still anonymous). According to the documentation, before a user logs in or is identified, events are tracked using a device-based identifier (such as a device ID or anonymous ID), and the user_id property is not set—hence, it remains null. This is standard behavior in both Legacy and newer ID management systems: anonymous events do not have a user_id until the user is authenticated or identified Identifying Users (Original) Identifying Users (Simplified).For your specific example, the event answer_attempt_submission always having a null user_id suggests that this event is being tracked before the user logs in or is identified. This could be intentional (e.g., allowing anonymous users to attempt answers) or due to the identification step not being implemented before this event is tracked.As for which other events have the same issue, the knowledge sources do not provide a way to list all events with a null user_id—this depends on your specific implementation and at what point in the user journey you identify users. Any event tracked before user identification will have a null user_id by default.In summary: - Events have a null user_id when triggered by anonymous users (before login/identification). - This is expected behavior unless you identify users before tracking those events. - The documentation does not provide a list of which events have this issue; it depends on your implementation and when you call the identification method.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
Thang D.
·
·
kapa.ai When an identified user named A123 logs in, the event has a distinct_id equal to user ID A123. Later, an event appears with the same distinct_id (A123) but a different user_id—let’s say B123. Could this happen if user A123 logged out and then logged in with another account (user B123)? If so, why does the distinct_id still remain as A123?
kapa.ai
APP
·
·
Let me check the knowledge base for you again. One moment! 📚
kapa.ai
APP
·
·
Based on the knowledge sources, in Legacy ID Management, when a user logs in, the distinct_id is typically set to their user ID (e.g., A123). When that user logs out, the recommended practice is to call .reset(), which clears the local storage and generates a new anonymous distinct_id for the next user session. If a new user (e.g., B123) logs in on the same device, the expected flow is: 1. User A123 logs in: - distinct_id = A123 - user_id = A1232. User A123 logs out: - .reset() should be called, generating a new anonymous distinct_id.3. User B123 logs in: - After identification, distinct_id should now be B123, and user_id = B123.If you see an event where distinct_id is still A123 but user_id is B123, this suggests that .reset() was not called upon logout. In this case, the SDK continues to use the previous distinct_id (A123) even after a new user logs in and is identified as B123. This is not the recommended practice and can lead to incorrect user attribution, as events for B123 would be associated with the distinct_id of A123 Identifying Users (Original) - Example User Flows Identifying Users (Simplified) - Best Practices.In summary: Yes, this can happen if user A123 logs out and B123 logs in without calling .reset(). The distinct_id remains as A123 because the SDK did not generate a new anonymous ID, so the new user's events are incorrectly attributed to the previous user's distinct_id. The documentation strongly recommends calling .reset() on logout to prevent this scenario and ensure correct user tracking.If .reset() is not called, the distinct_id will not change, leading to the issue you described. This is a common pitfall in Legacy ID Management implementations.
kapa.ai is still learning and improving, please let me know how I did by reacting below.
ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

17 comments

1. $device: Prefix in distinct_id under Legacy ID Management

2. distinct_id Associated with Multiple user_ids in Legacy

Summary

1. distinct_id is the same as user_id

2. distinct_id is a device_id

3. distinct_id has a $device: prefix

4. distinct_id is neither a user_id nor a device_id

Summary

1. `$device:` Prefix in distinct_id under Legacy ID Management