Merge pull request #917 from IABTechLab/gwh-APIDOCS-3315-03-uid2-identity-map-features-snippet

add snippet for identity map v3 improvements

Author: genwhittTTD

docs/endpoints/post-identity-map.md

@@ -7,6 +7,7 @@ displayed_sidebar: docs
 ---
 
 import Link from '@docusaurus/Link';
+import POSTIdentityMapImprovements from '../snippets/_post-identity-map-improvements-v3.mdx';
 
 # POST /identity/map
 
@@ -206,13 +207,7 @@ The following sections provide general information and guidance for migrating to
 
 ### Version 3 Improvements
 
-The v3 Identity Map API provides the following improvements over v2:
-
-- **Simplified Refresh Management**: You can monitor for UID2s reaching `refresh_from` timestamps instead of polling <Link href="../ref-info/glossary-uid#gl-salt-bucket-id">salt buckets</Link> for rotation.
-- **Previous UID2 Access**: You have access to previous raw UID2s for 90 days after rotation for campaign measurement.
-- **Single Endpoint**: You use only one endpoint, `/v3/identity/map`, instead of both `/v2/identity/map` and `/v2/identity/buckets`.
-- **Multiple Identity Types in One Request**: You can process both emails and phone numbers in a single request.
-- **Improved Performance**: The updated version uses significantly less bandwidth to process the same amount of DII.
+<POSTIdentityMapImprovements />
 
 ### Key Differences Between v2 and v3
 

docs/getting-started/gs-faqs.md

@@ -175,7 +175,7 @@ Here are some frequently asked questions for advertisers and data providers usin
 - [Does the same DII always result in the same raw UID2?](#does-the-same-dii-always-result-in-the-same-raw-uid2)
 - [If two operators process the same DII, are the results the same?](#if-two-operators-process-the-same-dii-are-the-results-the-same)
 - [How do I know when to refresh the UID2 due to salt bucket rotation?](#how-do-i-know-when-to-refresh-the-uid2-due-to-salt-bucket-rotation)
-- [Do refreshed emails get assigned to the same bucket with which they were previously associated?](#do-refreshed-emails-get-assigned-to-the-same-bucket-with-which-they-were-previously-associated)
+- [Do refreshed emails get assigned to the same bucket that they were previously associated with?](#do-refreshed-emails-get-assigned-to-the-same-bucket-that-they-were-previously-associated-with)
 
 #### How do I know when to refresh a raw UID2?
 
@@ -246,7 +246,7 @@ Metadata supplied with the UID2 generation request indicates the <Link href="../
 We do not make any promises about when the rotation takes place. To stay as up-to-date as possible, we recommend doing the checks once per hour.
 :::
 
-#### Do refreshed emails get assigned to the same bucket with which they were previously associated?
+#### Do refreshed emails get assigned to the same bucket that they were previously associated with?
 
 Not necessarily. After you remap emails associated with a particular bucket ID, the emails might be assigned to a different bucket ID. To check the bucket ID, see [Generate Raw UID2s from DII](../guides/integration-advertiser-dataprovider-overview.md#1-generate-raw-uid2s-from-dii) and save the returned raw UID2 and bucket ID again.
 

docs/sdks/sdk-ref-java.md

@@ -7,6 +7,7 @@ displayed_sidebar: docs
 ---
 
 import Link from '@docusaurus/Link';
+import POSTIdentityMapImprovements from '../snippets/_post-identity-map-improvements-v3.mdx';
 
 # SDK for Java Reference Guide
 
@@ -396,12 +397,7 @@ The following sections provide general information and guidance for migrating to
 
 ### Version 3 Improvements
 
-Version 3 of the `POST /identity/map` endpoint includes the following improvements:
-
-- **Support for multiple identity types**: You can process both email addresses and phone numbers in a single request.
-- **Simpler refresh management**: You can just re-map any raw UID2 when it reaches the refresh timestamp, rather than monitoring salt buckets, which is a separate API call.
-- **Availability of previous raw UID2**: You can see the previous UID2 for 90 days after rotation.
-- **Improved performance**: The new API version uses significantly less bandwidth for the same amount of DII.
+<POSTIdentityMapImprovements />
 
 ### Required Changes
 

docs/snippets/_post-identity-map-improvements-v3.mdx

@@ -0,0 +1,8 @@
+<!-- Used by: endpoints/post-identity-map.md, sdks/sdk-ref-java.md -->
+
+Version 3 of the `POST /identity/map` endpoint provides the following improvements over v2:
+
+- **Support for multiple identity types**: You can process both email addresses and phone numbers in a single request.
+- **Simpler refresh management**: You can just re-map any raw UID2 when it reaches the refresh timestamp, rather than monitoring salt buckets, which is a separate API call.
+- **Availability of previous raw UID2**: You can see the previous UID2 for 90 days after rotation.
+- **Improved performance**: The new API version uses significantly less bandwidth for the same amount of personal data.

i18n/ja/docusaurus-plugin-content-docs/current/endpoints/post-identity-map.md

@@ -1,19 +1,20 @@
 ---
 title: POST /identity/map
-description: DII を raw UID2 とソルトバケット ID にマッピング。
+description: Maps DII to raw UID2s.
 hide_table_of_contents: false
 sidebar_position: 08
 displayed_sidebar: docs
 ---
 
 import Link from '@docusaurus/Link';
+import POSTIdentityMapImprovements from '../snippets/_post-identity-map-improvements-v3.mdx';
+
+# POST /identity/map
 
 :::note
 このページには、近日中に翻訳される新しいコンテンツが含まれています。
 :::
 
-# POST /identity/map
-
 Maps multiple email addresses, phone numbers, or their respective hashes to their raw UID2s. You can also use this endpoint to check for updates to opt-out information, check when a raw UID2 can be refreshed, or view the previous UID2 if the current UID2 is less than 90 days old.
 
 Used by: This endpoint is used mainly by advertisers and data providers. For details, see [Advertiser/Data Provider Integration Overview](../guides/integration-advertiser-dataprovider-overview.md).
@@ -210,13 +211,7 @@ The following sections provide general information and guidance for migrating to
 
 ### Version 3 Improvements
 
-The v3 Identity Map API provides the following improvements over v2:
-
-- **Simplified Refresh Management**: You can monitor for UID2s reaching `refresh_from` timestamps instead of polling <Link href="../ref-info/glossary-uid#gl-salt-bucket-id">salt buckets</Link> for rotation.
-- **Previous UID2 Access**: You have access to previous raw UID2s for 90 days after rotation for campaign measurement.
-- **Single Endpoint**: You use only one endpoint, `/v3/identity/map`, instead of both `/v2/identity/map` and `/v2/identity/buckets`.
-- **Multiple Identity Types in One Request**: You can process both emails and phone numbers in a single request.
-- **Improved Performance**: The updated version uses significantly less bandwidth to process the same amount of DII.
+<POSTIdentityMapImprovements />
 
 ### Key Differences Between v2 and v3
 

i18n/ja/docusaurus-plugin-content-docs/current/snippets/_post-identity-map-improvements-v3.mdx

@@ -0,0 +1,8 @@
+<!-- Used by: endpoints/post-identity-map.md, sdks/sdk-ref-java.md -->
+
+Version 3 of the `POST /identity/map` endpoint provides the following improvements over v2:
+
+- **Support for multiple identity types**: You can process both email addresses and phone numbers in a single request.
+- **Simpler refresh management**: You can just re-map any raw UID2 when it reaches the refresh timestamp, rather than monitoring salt buckets, which is a separate API call.
+- **Availability of previous raw UID2**: You can see the previous UID2 for 90 days after rotation.
+- **Improved performance**: The new API version uses significantly less bandwidth for the same amount of personal data.