kapa.ai Tell me the entire flow of Original ID merge

Please stand by Aditya G. as I search the knowledge base. I normally take about 15 seconds or so. 👋

Based on the knowledge sources, I can explain the flow of Original ID Merge in Mixpanel.Original ID Merge is one of Mixpanel's identity management systems that supports retroactive identity merging, enabling the connection of multiple anonymous states to an identified state across different devices and platforms.The Original ID Merge flow works through special identity events: 1. Anonymous Tracking: When a user first interacts with your product, they're assigned an anonymous ID (often called a distinct_id). Events are tracked with this anonymous ID.2. Identification: When a user identifies themselves (typically by logging in or signing up), you send an $identify event containing both the anonymous ID and the user ID. This event has specific required properties: - event: Must be set to "$identify" - properties.$identified_id: The user's chosen ID - properties.$anon_id: The original anonymous ID - properties.token: Your project token

Create Identity shows the API call format:

How Mixpanel Marketing Analytics unlocks full user journey analysis mentions that ID Merge helps marry post-login identified activity with pre-login anonymous activity, creating a holistic user activity stream.

ℹ️ 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, I can help you understand the difference between $merge and $create_alias for merging identities in Mixpanel.First, it's important to note that both $merge and $create_alias are only useful for projects using the Original ID Merge system. They have no functionality in the Simplified ID Merge system, which uses a different approach with $device_id and $user_id properties instead.For projects using Original ID Merge: - $create_alias: This allows you to add an alias to a distinct ID. The alias becomes a new value that Mixpanel will interpret as the existing value. Each alias can only map to one distinct ID. Create Alias- $merge: This is a more powerful tool that allows you to merge two distinct IDs together. It's important to note that merging identities is irreversible - you cannot unmerge distinct IDs once they've been merged. Merge IdentitiesThe better option depends on your specific use case: - If you need to associate a new ID with an existing user and want to continue using the original ID as the primary identifier, $create_alias might be appropriate.- If you need to fully merge two separate user identities into a single identity cluster, $merge would be more appropriate. However, note that $merge events must be sent via the secure import endpoint ([https://api.mixpanel.com/import](https://api.mixpanel.com/import)), which requires your project API secret.LBKSRemember that if you're using or planning to migrate to the Simplified ID Merge system, neither of these methods will work, and you should instead focus on properly implementing the $device_idand$user_id` properties in your events.

ℹ️ 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'll provide a practical example of using $merge for Original ID Merge in Mixpanel.Based on the knowledge sources, the $merge event is specifically for projects using the Original ID Merge system and allows you to merge two distinct IDs together. Here's a practical example: Let's say you have a user who initially used your mobile app with distinct ID "mobile_user_123" and later used your website with distinct ID "web_user_456". You've determined these are the same person and want to merge their identities.To merge these identities using the $merge event, you would need to send a request to Mixpanel's import endpoint: LBKS[ { "event": "$merge", "properties": { "$distinct_ids": ["mobile_user_123", "web_user_456"], "token": "YOUR_PROJECT_TOKEN" } } ]LBKSThis request would be sent to [https://api.mixpanel.com/import](https://api.mixpanel.com/import) which requires authentication with your project's API secret (not the token) for security reasons.Important notes about this operation: 1. The $merge operation is irreversible - once you merge these IDs, you cannot unmerge them Merge Identities.2. The $merge event must be sent to the secure import endpoint protected by your project API secret.3. After merging, any future events sent with either "mobile_user_123" or "web_user_456" as the distinct_id will be attributed to the same user in Mixpanel.4. There is a limit of 500 IDs that can be merged into a single ID cluster in the Original ID Merge system.This approach is particularly useful when you need to connect user activity across different platforms or when you have multiple identifiers for the same user that you want to consolidate.Remember that if you're using the Simplified ID Merge system, you should use the $device_id and $user_id properties instead of the $merge event.

ℹ️ 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 provided, I can address your question about identifying anonymous users and merging advertisement IDs with device IDs in Mixpanel.For anonymous users who haven't signed up, Mixpanel's approach depends on which ID management system your project is using:

If you're using the Simplified ID Merge system (which is the recommended approach), you should: 1. Track anonymous users with a $device_id property in your events 2. Avoid creating profiles for anonymous users 3. Not attempt to merge advertisement IDs with device IDs for users who haven't signed upThe Simplified ID Merge documentation specifically recommends: > Avoid creating profiles for anonymous users

Identifying Users (Simplified)With Simplified ID Merge, you can only have one User ID ($user_id) per ID cluster, and this becomes the canonical Distinct ID. Advertisement IDs would not be suitable to use as User IDs for anonymous users.

If you're using the Original ID Merge system, you have more flexibility to merge multiple identifiers. In this case, you could potentially use advertisement IDs as additional identifiers for anonymous users.However, it's important to note that Mixpanel generally recommends against identifying anonymous users: > ⚠️We recommend against calling .identify() for anonymous visitors to your site. Managing User Identity

Instead of trying to merge advertisement IDs with device IDs for anonymous users, a better approach would be to: 1. Track the advertisement ID as a property on events for anonymous users 2. Wait until the user signs up to establish their identity 3. Then merge their anonymous activity (tracked with $device_id) with their identified activity (tracked with $user_id)This approach aligns better with Mixpanel's recommended best practices for identity management.If you need to anonymize user data while still tracking unique users, Mixpanel suggests: > If you want to analyze aggregate user behavior without being able to drill down into any particular user, we recommend generating a hash of some unique ID of the user and using that hash as the user's ID when you call the .identify() method in our SDKs. Protecting User Data

ℹ️ 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, I can explain how device IDs behave when an app is uninstalled in Mixpanel.For iOS apps, the behavior depends on how the device ID is configured: 1. Default behavior (since v3.6.2 for Objective-C and v2.7.7 for Swift): Mixpanel stopped using the IFA (ID for Advertisers) as a distinct_id and instead uses a random UUID that's stored in local storage. When an app is uninstalled, this local storage is cleared, so the device ID will change upon reinstallation.2. Optional IFV configuration: If you specifically configure Mixpanel to use the IFV (identifierForVendor) as the distinct_id: - For Objective-C: Set MIXPANEL_UNIQUE_DISTINCT_ID=1 in build settings - For Swift: Set MIXPANEL_UNIQUE_DISTINCT_ID in build settings With this configuration, the documentation explicitly states:

ℹ️ 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, I can explain the use cases where you would need to use $merge in the Original ID Merge system.The $merge event is specifically designed for projects using the Original ID Merge system and allows you to merge multiple distinct IDs together. Here are the key use cases where you would need to use $merge:

1. Merging Multiple User IDs: When you need to associate multiple identified IDs (like email address and phone number) with the same user. As mentioned in the documentation:

ℹ️ 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 provided, I don't have specific information about the standard key names for GAID (Google Advertising ID), FBID (Facebook ID), and Firebase Pseudo ID in Mixpanel. The documentation provided doesn't explicitly mention these specific identifiers or their standard key name formats in Mixpanel's system. While Mixpanel does support tracking with advertising IDs and integrating with various platforms, the knowledge sources don't contain the specific key name conventions for these particular identifiers.What I can tell you is that Mixpanel has a general approach to handling identifiers: 1. For device advertising IDs, there is mention of storing them as user properties when setting up integrations like Facebook Ads: "...choose user property where you're storing device advertising ID (optional)" Facebook Ads Integration2. For identity management, Mixpanel uses $device_id for anonymous users and $user_id for identified users in the Simplified ID Merge system.3. When working with third-party systems, Mixpanel recommends "designating a user property with the identifier of the user in that third-party system."If you need the specific standard key names for these identifiers in Mixpanel, I would recommend consulting Mixpanel's complete documentation or reaching out to Mixpanel support for the most accurate information.

ℹ️ 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 provided, I can explain how to handle device_id in the Original ID Merge system.For Original ID Merge, the approach to handling device_id is different from the Simplified ID Merge system. In Original ID Merge, you don't need to explicitly send $device_id with every event as a property.Instead, in Original ID Merge: 1. The identity management is handled through special events like $identify, $create_alias, and $merge.2. For client-side SDKs (JavaScript, iOS, Android), the SDK automatically generates and manages a $device_id internally, but this is used differently than in Simplified ID Merge.3. When using Segment with Original ID Merge, you would configure it like this: LBKS// Original ID Merge mixpanel.register({ $device_id: segmentDeviceId, distinct_id: segmentDeviceId });LBKSSetting up Autocapture with SegmentThe key difference is that in Original ID Merge, you don't rely on the presence of $device_id and $user_id properties in events to trigger identity merging. Instead, you explicitly send $identify events to connect anonymous and identified states.If you're using a server-side implementation with Original ID Merge, you would: 1. Generate and manage anonymous IDs yourself 2. Send $identify events when users log in to connect their anonymous activity with their identified activity 3. Use $merge or $create_alias if you need to merge multiple user IDsThe documentation doesn't specifically mention using identity.set() for device_id in Original ID Merge, but it does indicate that the approach to identity management is fundamentally different between the two systems.If you're considering migrating from Original ID Merge to Simplified ID Merge, note that the implementation details would change significantly, as explained in the Migrating to Simplified ID Merge documentation.

ℹ️ 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, the flow you've described for app reinstallation by the same user on the same device is correct for Mixpanel's Simplified ID Merge system. Let me verify each step: 1. User installs app → gets $device_id = D1 ✓ Correct. When a user first installs the app, Mixpanel's SDK automatically generates a random $device_id (D1).2. Logs in → .identify("U1") → cluster = D1 + U1 ✓ Correct. When the user logs in and you call .identify("U1"), Mixpanel creates an identity cluster linking D1 and U1.3. Uninstalls and reinstalls app ✓ Correct. This clears the local storage where the $device_id was stored.4. SDK generates new $device_id = D2 ✓ Correct. For iOS apps, the documentation explicitly states: "The IFV will not change when you call reset, but will change upon app uninstalls/reinstalls" Mixpanel SDKs: iOS (Swift). For other platforms, the device ID also changes upon reinstallation as it's stored in local storage.5. User logs in again → .identify("U1") ✓ Correct. When the user logs in again and you call .identify("U1"), this will send both D2 and U1 in the same event.6. Expected: Mixpanel should merge D2 with U1 → final cluster: D1, D2, U1 ✓ Correct. When Mixpanel receives an event with both a new $device_id (D2) and an existing $user_id (U1), it will merge them into the existing identity cluster. The final cluster will contain D1, D2, and U1.This flow matches the "Returning User" example in the Identifying Users (Simplified) documentation, where a user returns on a new device (or in this case, the same device with a new installation).

ℹ️ 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 need to adjust my previous answer since you're asking about Original ID Merge rather than Simplified ID Merge.For Original ID Merge, the flow would be slightly different. Let me check each step: 1. User installs app → gets $device_id = D1 ✓ Correct. The SDK generates an anonymous ID for the user.2. Logs in → .identify("U1") → cluster = D1 + U1 ✓ Correct. When the user logs in and you call .identify("U1"), this sends an $identify event that creates a mapping between the anonymous ID (D1) and the user ID (U1).3. Uninstalls and reinstalls app ✓ Correct. This clears the local storage.4. SDK generates new $device_id = D2 ✓ Correct. For iOS apps, the documentation confirms: "The IFV will not change when you call reset, but will change upon app uninstalls/reinstalls" Mixpanel SDKs: iOS (Swift).5. User logs in again → .identify("U1") ✓ Correct. When the user logs in again and you call .identify("U1"), this will send an $identify event with D2 as the anonymous ID and U1 as the identified ID.6. Expected: Mixpanel should merge D2 with U1 → final cluster: D1, D2, U1 ✓ Correct. In Original ID Merge, the $identify event will add D2 to the existing identity cluster that already contains D1 and U1.The key difference with Original ID Merge is that it relies on explicit identity events ($identify, $create_alias, $merge) rather than the presence of $device_id and $user_id properties in regular events. However, the overall flow and outcome are the same - the user's new device ID after reinstallation will be merged with their existing user ID.Note that Original ID Merge has a limit of 500 IDs per identity cluster, so if a user frequently uninstalls and reinstalls the app, they could eventually reach this limit.The flow you've described is correct for Original ID Merge.

ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.