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 Merge
For 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 value
So 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 Alias
In 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."
This 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."
However, 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 development
These SDKs automatically generate device IDs and handle user identity management. They also automatically collect certain properties like browser type, device information, and location.
Server-Side SDKs
Server-side SDKs run on your backend servers:
- Python - Node.js - Ruby - PHP - Go - Java
With 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."
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 Practices
3. 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.