Myronkaifung identitymanagement update (#1290)

* Update _meta.json

* Update _meta.json

* Create overview.mdx

* Rename identifying-users.md to identifying-users-simplified.mdx

* Create identifying-users-original.mdx

* Create serverside-id-management.mdx

* Rename identifying-users-simplified.mdx to identifying-users-simplified.md

* Update _meta.json

* Update _meta.json

* Delete pages/docs/tracking-methods/id-management/serverside-id-management.mdx

* Update and rename overview.mdx to identity-management.mdx

* Update identifying-users-original.mdx

* Update identifying-users-simplified.md

* Add files via upload

* Update identity-management.mdx

* Rename identifying-users-simplified.md to identifying-users-simplified.mdx

* Update identity-management.mdx

* Update identity-management.mdx

* Update identity-management.mdx

* Update local.txt

* Update vwo.md

* Update amplitude.md

* Update create-identity.md

* Update leanplum.md

* Update identity-create-alias.md

* Update onesignal.md

* Update identity-merge.md

* Update braze.md

* Update mailchimp.md

* Update iterable.md

* Update moengage.md

* Update airship.md

* Update google-analytics.md

* Update apptimize.md

* Update events-and-properties.md

* Update schematized-export-pipeline.md

* Update migrating-to-simplified-id-merge-system.md

* Update user-profiles.md

* Update events-and-properties.md

* Update google-analytics.md

* Update migrating-to-simplified-id-merge-system.md

* Update qa-data-audit.mdx

* Update migrating-to-simplified-id-merge-system.md

* Update migrating-to-simplified-id-merge-system.md

* Update migrating-to-simplified-id-merge-system.md

* Update local.txt

* Update identity-management.mdx

* Update identifying-users-original.mdx

* Update identifying-users-simplified.mdx

* add div around id management callout

* add div around id management callout

* Update overrides.scss

* Update identifying-users-original.mdx

* Update identifying-users-simplified.mdx

* Update identifying-users-original.mdx

* Update overrides.scss

* Update identity-management.mdx

* Update identifying-users-original.mdx

* Update identifying-users-original.mdx

* Update identifying-users-original.mdx

Author: myronkaifung

pages/docs/cohort-sync/integrations/airship.md

@@ -33,7 +33,7 @@ _It is not recommended to use the same tag name for two static exports, as users
 **For dynamically syncing exports:** Every 15 minutes, Mixpanel will initiate a sync between the Mixpanel cohort and the Airship tag. At the time of the sync, Mixpanel will add the tag for newly-qualified users, and remove the tag for users who have exited the cohort. Users can move into and out of the cohort depending on if they meet the cohort criteria. Note that these tags only apply to the “mixpanel” Tag Group Key, which must be created within Airship.
 
 ## How are users matched between Airship and Mixpanel?
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the $user_id in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the $user_id in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Users are matched between Airship and Mixpanel using the [Airship channel id](https://docs.airship.com/guides/airship/user-guide/channels-intro/#channel-ids). This value must be set as a Mixpanel user property named `$ios_urban_airship_channel_id` for iOS users or `$android_urban_airship_channel_id` for Android users. These values must match with the Airship channel id.
 

pages/docs/cohort-sync/integrations/apptimize.md

@@ -31,7 +31,7 @@ Follow these steps to enable the integration with Apptimize:
 
 ## Matching Users between Apptimize and Mixpanel
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarly applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarly applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles (users with at least 1 set profile properties) to match to Apptimize - users without user profiles (i.e. anonymous users) will not export.
 

pages/docs/cohort-sync/integrations/braze.md

@@ -91,7 +91,7 @@ In order to build a Braze Segment after importing a cohort:
 
 ## Matching Mixpanel and Braze Users
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 In order to match Mixpanel users to ones on Braze's end, the user in Mixpanel should have a profile property named $braze_external_id with the value you have assigned in Braze to the same user as [external_user_id](https://www.braze.com/docs/developer_guide/platform_integration_guides/ios/analytics/setting_user_ids/#suggested-user-id-naming-convention).
 

pages/docs/cohort-sync/integrations/iterable.md

@@ -59,7 +59,7 @@ The best way to match users from Mixpanel to Iterable is to set the `$iterable_u
 
 Iterable uses an email address to match users from the cohort with users from their system. The integration will fail if an email address is not sent. In order to use this integration, you must set email as a user profile property.
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 ## Iterable Events into Mixpanel and MTU Exemptions
 

pages/docs/cohort-sync/integrations/leanplum.md

@@ -32,7 +32,7 @@ The Leanplum integration will show a **Connected** tag in the UI once the connec
 
 ## Matching Users Between Leanplum and Mixpanel
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles to match to Leanplum - users without user profile properties (i.e. anonymous users) will not export.
 

pages/docs/cohort-sync/integrations/mailchimp.md

@@ -29,7 +29,7 @@ You will need to provide an API key (referred to as an Authorization token in Ma
 
 ## Matching Users between Mailchimp and Mixpanel
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles to match to Mailchimp - users without user profile properties (i.e. anonymous users) will not export.
 

pages/docs/cohort-sync/integrations/moengage.md

@@ -35,7 +35,7 @@ You can find these values in your MoEngage settings page - note that MoEngage Ap
 
 ## Matching Users between MoEngage and Mixpanel
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles to match to MoEngage - users without user profile properties (i.e. anonymous users) will not export.
 

pages/docs/cohort-sync/integrations/onesignal.md

@@ -29,7 +29,7 @@ Follow these steps to enable the integration with OneSignal:
 
 ## Matching Users between OneSignal and Mixpanel
 
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles to match to OneSignal - users without user profile properties (i.e. anonymous users) will not export.
 

pages/docs/cohort-sync/integrations/vwo.md

@@ -27,7 +27,7 @@ To enable the integration:
 4. The VWO integration will show a **Connected** tag in the UI once the connection establishes.
 
 ## Matching Users between VWO and Mixpanel
-> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identifying-users#simplified-vs-original-id-merge) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
+> **Warning:** Projects using the [simplified ID merge system](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) must have the `$user_id` in Mixpanel match the user identifier in the partner service. Using any alternative partner properties to match users between tools may result in partner events not being attributed to the correct user in Mixpanel. Any partner properties mentioned in the below section are primarily applicable to projects on the original ID merge system.
 
 Mixpanel only exports identified user profiles with the user property `$vwo_user_id` to match to VWO - users without user profile properties (i.e. anonymous users) will not export. The value of this property should equal a matching User ID in VWO.
 

pages/docs/data-pipelines/schematized-export-pipeline.md

@@ -44,7 +44,7 @@ User data is exported to a single table named `mp_people_data`  (user data is ac
 Since user profiles are mutable, the data in the table is replaced every time an export happens based on the schedule (daily or hourly) with the latest user profiles.
 
 ## User Identity Resolution
-Exports from projects with [ID merge enabled](/docs/tracking-methods/id-management/identifying-users#how-do-i-switch-between-the-simplified-and-original-api) will need to use the identity mapping table to replicate the user counts seen in UI reporting. When ID merge is enabled, Mixpanel assigns multiple identifiers to an individual. Mixpanel resolves these into one identifier, and uses that for reporting unique user counts. Read more about how Mixpanel resolves IDs [here](/docs/tracking-methods/id-management/identifying-users#example-user-flows).
+Exports from projects with [ID merge enabled](/docs/tracking-methods/id-management/identity-management#identity-merge-apis) will need to use the identity mapping table to replicate the user counts seen in UI reporting. When ID merge is enabled, Mixpanel assigns multiple identifiers to an individual. Mixpanel resolves these into one identifier, and uses that for reporting unique user counts. Read more about how Mixpanel resolves IDs [here](/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows).
 
 Pipelines export event data as they appear when Mixpanel ingests them. This means exported event data before sending alias event has the original user identifier, **not** the resolved identifier. Use the identity mappings table to accurately count unique users. This will allow you to recreate the identity cluster that Mixpanel creates.
 

pages/docs/data-structure/events-and-properties.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-Events are the core of [Mixpanel's Data Model](/docs/tutorials/plan/tracking-strategy#the-mixpanel-data-model). All events should have an **Event Name**, a **Timestamp** of when that event has occurred, and a **[Distinct ID](/docs/tracking-methods/id-management/identifying-users#what-is-distinct-id)** (Mixpanel's identifier for a user) to tie all events belonging to the same user. Events can optionally have a set of properties, which describes the event in more detail.
+Events are the core of [Mixpanel's Data Model](/docs/tutorials/plan/tracking-strategy#the-mixpanel-data-model). All events should have an **Event Name**, a **Timestamp** of when that event has occurred, and a **[Distinct ID](/docs/tracking-methods/id-management/identity-management#distinct-id)** (Mixpanel's identifier for a user) to tie all events belonging to the same user. Events can optionally have a set of properties, which describes the event in more detail.
 
 * If you're familiar with databases, events are like tables and properties are like columns.
 * If you're familiar with Google Analytics, events are like hits and properties are like dimensions.
@@ -71,8 +71,8 @@ Mixpanel reserves certain event property names for special processing or for spe
 | ip | - | The `ip` event property is the value to be used for geo location parsing (i.e. `$city`, `$region`, and `mp_country_code`) if `ip` as param to the [/track endpoint](https://developer.mixpanel.com/reference/track-event) has **not been** set to 1. Our client-side libraries, by default, will set the `ip` param to 1 so geo location is parsed from the incoming request, but this can be disabled or, if you're implementing from the [server-side](/docs/best-practices/server-side-best-practices#tracking-geolocation-http-api), you can include the `ip` event property so it's parsed from it instead of the IP of the incoming request. The `ip` event property is not stored in Mixpanel. |
 | $bucket / bucket | - | A reserved property that is hidden from the Mixpanel interface, and will cause other events to not appear in the interface. Do not name any property bucket or $bucket. |
 | $distinct_id / distinct_id | Distinct ID | Mixpanel's internal unique identifier for a user. See [Identifying Users](/docs/tracking-methods/id-management/identifying-users). |
-| $device_id | Device ID | In [Simplified ID Merge](/docs/tracking-methods/id-management/identifying-users#example-user-flows): unique identifier used to track a device while the user is in anynymous state. |
-| $user_id | User ID | In [Simplified ID Merge](/docs/tracking-methods/id-management/identifying-users#example-user-flows): unique identifier used to track a user across devices when user is in identified state. |
+| $device_id | Device ID | In [Simplified ID Merge](/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows): unique identifier used to track a device while the user is in anynymous state. |
+| $user_id | User ID | In [Simplified ID Merge](/docs/tracking-methods/id-management/identifying-users-simplified#example-user-flows): unique identifier used to track a user across devices when user is in identified state. |
 | $event_name | Event Name | Name of the tracked event used in the Mixpanel UI. |
 | $time / time | Time or Date | A unix time epoch that is used to determine the time of an event. Ingested as [`time`](https://developer.mixpanel.com/reference/import-events#propertiestime) property and indicated as `$time` in Mixpanel’s UI. If no `time` property is provided, we will use the time when the event arrives at our servers. |
 | $insert_id | Insert ID | A unique identifier for the event, used to deduplicate events that are accidentally sent multiple times. More details [here](https://developer.mixpanel.com/reference/import-events#propertiesinsert_id). |

pages/docs/data-structure/user-profiles.md

@@ -18,7 +18,7 @@ A user profile has a set of properties associated with a given user. Under the h
 | 456 | Bob | `[email protected]` | Product |
 | 789 | Carol | `[email protected]` | Design |
 
-User profiles are joined onto your events based on their **[Distinct ID](/docs/tracking-methods/id-management/identifying-users#what-is-distinct-id)** (Mixpanel's identifier for a user). This lets you join the events performed by a user with properties about who that user is. Thus, it's very important that you use the same Distinct ID for both the events and user profile for the same user.
+User profiles are joined onto your events based on their **[Distinct ID](/docs/tracking-methods/id-management/identity-management#distinct-id)** (Mixpanel's identifier for a user). This lets you join the events performed by a user with properties about who that user is. Thus, it's very important that you use the same Distinct ID for both the events and user profile for the same user.
 
 For more information about user profiles refer to the documentation on [The Mixpanel Data Model](/docs/tutorials/plan/tracking-strategy#the-mixpanel-data-model).