Understanding Identity Stitching: Classic Segment vs. Mixpanel Actions
how did identity stitching work with the classic Segment → Mixpanel destination as opposed to Segment with Mixpanel actions?
how did identity stitching work with the classic Segment → Mixpanel destination as opposed to Segment with Mixpanel actions?
Hi Elena M., 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 knowledge sources do not provide a detailed, side-by-side technical comparison of how identity stitching (ID merge) worked in the classic Segment → Mixpanel destination versus the newer Mixpanel Actions destination. However, here’s what can be confidently stated based on the available documentation: - Mixpanel Actions Destination:
The Actions destination uses Segment’s Actions framework, which allows for more granular mapping of identity and event data. When you call Segment’s identify API, Mixpanel sets the specified userId as the Mixpanel distinct_id, and any traits are applied as profile properties. This mapping is explicit and configurable in the Actions destination settings. The Actions destination is cloud-mode only, and identity management is handled according to the Mixpanel project’s configured ID Merge API (either Simplified or Original). Segment works out of the box with both APIs, and the userId from Segment is mapped to distinct_id in Mixpanel Docs: Segment Integration Overview Docs: Data Mapping.- Classic Segment → Mixpanel Destination:
The classic destination could be implemented in either device mode (SDK on the client) or cloud mode. In device mode, super properties and people properties could be set directly, and identity management relied on the Mixpanel SDK’s behavior on the client. In cloud mode, identity was managed by the data sent from Segment’s servers. The classic destination required enabling Mixpanel People explicitly for profile data, and identity stitching depended on how identify and alias calls were made and mapped from Segment to Mixpanel. There is less flexibility in mapping and less transparency compared to Actions. The classic destination is now considered legacy, and Actions is recommended for new implementations Docs: Segment Integration FAQ.Key Differences:
- The Actions destination provides more explicit, configurable, and transparent mapping of identity fields, and always operates in cloud mode.
- The classic destination’s identity stitching depended more on the mode (device vs. cloud) and required additional settings for profile data.
- Both destinations ultimately rely on the Mixpanel project’s ID Merge API (Simplified or Original) for how identities are merged and stitched in Mixpanel.If you need a more technical, step-by-step comparison, the knowledge sources do not provide enough detail to answer further. For most use cases, the Actions destination is recommended for its improved mapping and reliability.
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! 📚
Yes, you can replicate identity stitching (ID merge) prior to Mixpanel Actions using your Segment raw data, but it requires reconstructing the identity clusters yourself. Here’s what the knowledge sources indicate: - Mixpanel’s ID Merge (Original API):
Identity stitching in Mixpanel (prior to Actions) relied on special events like $identify, $create_alias, and $merge to link anonymous and identified users. Segment’s classic destination would send identify and alias calls, which Mixpanel would use to merge identities. However, when exporting raw event data (e.g., from Segment or Mixpanel), the events themselves only contain the identifiers as they were at the time of ingestion—not the resolved, merged identity. To accurately reconstruct user journeys and unique user counts, you need to use the identity mapping table that Mixpanel generates when ID merge is enabled. This table shows how different identifiers are clustered together as a single user in Mixpanel User Identity Resolution – JSON Pipelines User Identity Resolution – Schematized Export Pipeline.- Replicating Identity Stitching:
If you have access to the identity mapping table exported from Mixpanel, you can join your raw Segment event data with this table to resolve all identifiers to the canonical user (the “resolved_distinct_id”). If you do not have this table, you would need to reconstruct the identity clusters yourself by replaying the sequence of identify and alias calls in your raw data, mimicking how Mixpanel would have merged them. This can be complex, as you must ensure you follow the same logic and constraints (e.g., only merging anonymous IDs in UUIDv4 format, not merging an anonymous ID that was already merged, etc.) Identifying Users (Original) – Mechanism.Summary:
You can replicate identity stitching using your Segment raw data by replaying the identity events (identify, alias) to build your own mapping of identifiers to users, or by leveraging Mixpanel’s exported identity mapping table if available. This process is manual and can be complex, but it is possible to achieve the same result as Mixpanel’s internal identity stitching logic.If you need more details on the exact logic or code, the knowledge sources do not provide a step-by-step guide, but the above approach is supported by the documentation.
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 the knowledge sources, this is a known challenge when reconstructing identity stitching from raw data. Mixpanel’s UI may show anonymous IDs linked to users even if you cannot find a direct mapping in your exported identify or alias tables. This is because: - Mixpanel’s internal identity resolution uses not only explicit $identify and $create_alias events, but also the ingestion-time state of the user’s device and session. For example, if a user’s anonymous events (with a given anonymous ID) are followed by an identify call on the same device/session, Mixpanel will merge those automatically—even if you don’t see a corresponding explicit mapping event in your raw data exports Identifying Users (Original) – Mechanism.- Exported event data only contains the identifiers as they appeared at ingestion, not the resolved/merged identity. The true mapping of all identifiers (including those not explicitly linked via events) is maintained internally by Mixpanel and surfaced in the UI, but not always directly available in your exported tables User Identity Resolution – JSON Pipelines.- Identity mapping table: Mixpanel provides an identity mapping table when exporting from projects with ID merge enabled. This table is the authoritative source for how Mixpanel has clustered identifiers, and should be used to resolve all identifiers to the canonical user. If you do not have this table, it is not always possible to perfectly reconstruct the identity clusters as seen in the UI, especially for anonymous IDs that were merged implicitly by Mixpanel’s backend logic User Identity Resolution – Schematized Export Pipeline.In summary:
If you are missing links for some anonymous IDs, it is likely because Mixpanel’s internal merging logic (based on session/device context) created those links, and they are not always represented as explicit events in your raw data. The only reliable way to replicate the UI’s identity stitching is to use the identity mapping table exported from Mixpanel. Without it, there will be cases where you cannot reconstruct all links from raw event data alone.If you need this mapping, consider exporting the identity mapping table from Mixpanel, as described in the documentation User Identity Resolution – JSON Pipelines.
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.