Understanding Resolved Distinct ID Behavior in Kapa.ai
kapa.ai how come sometimes the resolved_distinct_id contains the userid and the distinct_id contains the device id and sometimes is the other way around?
kapa.ai how come sometimes the resolved_distinct_id contains the userid and the distinct_id contains the device id and sometimes is the other way around?
The reason you sometimes see the resolved_distinct_id as the user ID and the distinct_id as the device ID (and vice versa) depends on which Mixpanel ID Merge API your project is using:
1. Original ID Merge API: In this system, the canonical distinct_id (the one used for queries and exports) is programmatically selected by Mixpanel from any of the IDs in the identity cluster (which can include both device IDs and user IDs). This selection is not user-configurable and can appear random. As a result, sometimes the canonical distinct_id is the user ID, and other times it is the device ID. The resolved_distinct_id is used to represent the unified user identity in reporting, but the underlying distinct_id on events may still be the device ID or user ID, depending on how the cluster was formed and which ID Mixpanel chose as canonical at that time Canonical Distinct ID (Original), FAQ (Original).
2. Simplified ID Merge API: With the Simplified ID Merge, the canonical distinct_id is always set to the $user_id once a user is identified. Before identification, events use the $device_id (prefixed as $device:device_id) as the distinct_id. After identification, all events for that user will use the $user_id as the distinct_id, and the resolved_distinct_id will also be the $user_id. This makes the mapping more predictable Canonical Distinct ID (Simplified), Understanding Simplified ID Merge.
Summary: - In the Original API, the canonical distinct_id can be either the device ID or user ID, and this is not user-controlled. - In the Simplified API, the canonical distinct_id is always the user ID after identification.
If you are seeing both patterns, it is likely due to your project using the Original ID Merge API, or you are looking at data from before and after a user was identified. For accurate user counts and analysis, always use the resolved_distinct_id from the identity mapping table, as it reflects Mixpanel’s unified view of the user User Identity Resolution.
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'm sorry, but the knowledge sources do not explicitly mention a scenario where the actual user ID would only exist in the distinct_id column and not in the resolved_distinct_id column. According to the documentation, when using the identity mapping table for projects with ID merge enabled, you should use the resolved_distinct_id in place of the non-resolved distinct_id whenever present. If there is no resolved_distinct_id, you can then use the distinct_id from the existing people or events table. However, the documentation does not provide details on cases where the user ID would be present only in distinct_id and not in resolved_distinct_id User Identity Resolution.
If you are encountering this situation, it may be due to a data ingestion timing issue, an incomplete identity mapping, or a project-specific configuration, but the knowledge sources do not provide enough information to confirm or explain this behavior. For further clarification, you may need to reach out to Mixpanel support.
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.