Clarification on Mixpanel Distinct ID and UUID Format
Is Distinct ID $device: UUID is a correct value for mixpanel Distinct ID . Is this format set by mixpanel or just UUID is set by mixpanel for originbal ID merge
Is Distinct ID $device: UUID is a correct value for mixpanel Distinct ID . Is this format set by mixpanel or just UUID is set by mixpanel for originbal ID merge
Hi Aditya G., 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
The format $device:UUID is specific to the Simplified ID Merge system in Mixpanel, not the Original ID Merge system.In the Simplified ID Merge system:
- When an event contains only a $device_id (no $user_id), Mixpanel automatically sets the distinct_id as $device: followed by the value of the $device_id property.
- This prefix helps Mixpanel distinguish between anonymous users (with the $device: prefix) and identified users (without the prefix).As explained in the documentation: > "distinct_id values prefixed with a $device: will be used as $device_id, while distinct_id values without the $device: prefix will be used as $user_id. Ensure that the distinct_id value of an anonymous user's events are always prefixed with $device: if this approach is used."
Migrating to Simplified ID MergeFor the Original ID Merge system, there is no $device: prefix requirement. The distinct_id is typically just a UUID without any special prefix, and identity management is handled through special events like $identify, $create_alias, and $merge.If you're using the Original ID Merge system, you should use a plain UUID as the distinct_id without the $device: prefix.
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.
Let me check the knowledge base for you again. One moment! đź“š
If you send a distinct_id with the prefix $device: in the Original ID Merge system, Mixpanel will simply treat it as a regular distinct_id value with that specific string format. The $device: prefix has no special meaning or functionality in the Original ID Merge system.The $device: prefix is only meaningful in the Simplified ID Merge system, where it indicates that the ID is an anonymous device identifier. In the Original ID Merge system, identity management works differently: - Original ID Merge relies on special events like $identify, $merge, and $create_alias to establish identity relationships
- It doesn't use the $device_id and $user_id properties to determine identity relationships
- There's no automatic processing of prefixes in the distinct_id valueSo while using a distinct_id with $device: prefix won't cause errors in the Original ID Merge system, it also won't trigger any special behavior. The system will simply treat it as a literal string value that happens to contain the characters "$device:".If you're using the Original ID Merge system, it's generally cleaner to use distinct_ids without special prefixes to avoid confusion, since the prefix doesn't serve any functional purpose in that system.
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.
Let me check the knowledge base for you again. One moment! đź“š
The $device: prefix does not affect the functionality of $identify, $merge, and $create_alias events in the Original ID Merge system.According to the documentation, these special identity events ($identify, $merge, and $create_alias) are only functional in the Original ID Merge system and have no effect in the Simplified ID Merge system where the $device: prefix is used: > "The $identify event payload is only useful for projects using the Original ID Merge system; it has no functionality in other ID management systems." Create Identity> "The $create_alias event payload is only useful for projects using the Original ID Merge system and the Legacy ID Management System; it has no functionality in the Simplified ID Merge system." Create AliasIn the Original ID Merge system, these identity events work based on the specific properties they contain (like $identified_id and $anon_id for $identify events), not based on any prefix in the distinct_id. The $device: prefix is simply treated as part of the string value and has no special meaning in this context.If you're using the Original ID Merge system, the $device: prefix won't interfere with these identity events, but it also won't provide any benefit or special functionality.
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.
Let me check the knowledge base for you again. One moment! đź“š
In the Original ID Merge system, the device ID is not automatically generated by Mixpanel for server-side implementations. You need to generate and manage the IDs yourself.According to the documentation: > "Since the Java SDK is a server-side library, IDs are not generated by the SDK. Instead, you will need to generate and manage the distinct_id yourself and include it in your events and profile data."
Mixpanel SDKs: JavaThis is consistent across other server-side SDKs as well: > "Since the Node.js SDK is a server-side library, IDs are not generated by the SDK. Instead, you will need to generate and manage the distinct_id yourself and include it in your events and profile data."
Mixpanel SDKs: Node.jsHowever, for client-side implementations (web, mobile), Mixpanel's SDKs do automatically generate device IDs: > "When using our Web or Mobile SDKs, Mixpanel will automatically generate an $device_id that's local to that user's device, and set that value as the distinct_id for the event."
Identifying Users (Simplified)So in summary, for Original ID Merge:
- Client-side SDKs (JavaScript, iOS, Android): Mixpanel automatically generates device IDs
- Server-side SDKs (Node.js, Java, PHP, etc.): You need to generate and manage the IDs yourself
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.
Let me check the knowledge base for you again. One moment! đź“š
You can identify whether you're using a client-side or server-side SDK in Mixpanel by looking at the environment where the SDK runs and the specific SDK you're implementing.
Client-Side SDKs
Client-side SDKs run directly in the user's browser or mobile device: - JavaScript: Runs in web browsers - React Native: For mobile apps using React Native - Android: Native Android apps - iOS (Objective-C/Swift): Native iOS apps - Flutter: Cross-platform mobile apps - Unity: Game developmentThese SDKs automatically generate device IDs and handle user identity management. They also automatically collect certain properties like browser type, device information, and location.SDKs: Send data from your application into Mixpanel
Server-Side SDKs
Server-side SDKs run on your backend servers: - Python - Node.js - Ruby - PHP - Go - JavaWith server-side SDKs, you need to generate and manage the distinct_id yourself: > "Since the Python SDK is a server-side library, IDs are not generated by the SDK. Instead, you will need to generate and manage the distinct_id yourself and include it in your events and profile data." Mixpanel SDKs: Python
Key Differences
1. ID Generation: Client-side SDKs automatically generate device IDs; server-side SDKs require you to manage IDs yourself.2. Default Properties: Client-side SDKs automatically collect properties like browser type and device information, while server-side SDKs don't:
"Mixpanel's Web and Mobile SDKs parse User-Agent into a set of properties about the user's browser, device, and OS. This doesn't happen automatically with server-side tracking, but it's easy to add these properties yourself."
Server-Side Best Practices3. Ad-blockers: Client-side tracking can be affected by ad-blockers, while server-side tracking is not.4. Implementation Location: If you're implementing tracking code directly in your website or mobile app, you're using client-side. If you're implementing in your backend services, you're using server-side.If you're unsure which approach to use, Mixpanel provides guidance on choosing the right method based on your needs and resources in their Send Your Data guide.
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.
Let me check the knowledge base for you again. One moment! đź“š
I don't have enough information to determine which type of Mixpanel implementation (client-side or server-side) you're using for your commerce app. The knowledge sources provided don't contain specific details about your implementation.To identify whether you're using client-side or server-side tracking, you would need to examine: 1. Where your tracking code is implemented (in frontend code or backend services) 2. Which specific SDK you're using (JavaScript, Android, iOS, Python, Node.js, etc.) 3. How user IDs are being managed (automatically generated or manually assigned) 4. What default properties are being collectedIf you could share more specific details about your implementation, such as code snippets, SDK information, or how you're handling user identification, I could help determine which approach you're using.Would you be able to provide any of these implementation details so I can give you a more accurate answer?
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.
Let me check the knowledge base for you again. One moment! đź“š
Based on your statement that you do tracking in frontend code, you are using a client-side SDK for Mixpanel implementation in your commerce app.Client-side SDKs run directly in the user's browser or mobile device. For web applications, this would be the JavaScript SDK, while for mobile applications it could be Android, iOS (Objective-C/Swift), React Native, or Flutter SDKs.With client-side SDKs, Mixpanel automatically: 1. Generates device IDs for you
2. Collects default properties like browser type, device information, and location
3. Handles user identity management with methods like identify() and reset()These SDKs also automatically collect many useful properties without additional configuration. For example, the JavaScript SDK collects properties like:
- UTM parameters
- Browser and browser version
- Operating system
- Screen dimensions
- Current URL and referrer information
- And moreDefault Properties: Automatically collected propertiesOne thing to be aware of with client-side tracking is that it can be affected by ad-blockers, which might block 15-30% of events: > "Frontend event tracking (especially on the web) loses between 15% and 30% of events. If you're only tracking on the client-side, you're missing out on a lot of data, even if you're using a reverse proxy."
What to TrackIf this is a concern, you might consider implementing a proxy for your JavaScript tracking or supplementing with some server-side tracking for critical events.Would you like more specific information about the client-side SDK you're using?
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.