Advertiser/Data Provider Integration Overview
このガイドは、ユーザーデータを収集し、他の UID2 参加者に送信する組織向けのインテグレーションオプションの概要を提供します。データ収集者には、広告主、データオンボーダー、測定プロバイダー、ID グラフプロバイダー、サードパーティデータプロバイダー、およびその他のデータを他の参加者に送信する組織が含まれます。
Advertiser/Data Provider Routes to Use UID2
アドテクノロジー業界では、広告主はアイデンティティを使用してオーディエンスを構築し、コンバージョンを追跡し、グラフを生成します。広告主として、または広告主に代わって行動するデータプロバイダーとして、以下の表は UID2 を使用してこれらの目標の一部を達成する方法 の例を示しています。
UID2 は、これらのユースケース以外でも使用できます。これらは一部の例に過ぎません。
Send/Receive? | Action | Advantage/Result |
---|---|---|
オーディエンスを送信 | API またはピクセルを介して raw UID2 を送信 | オーディエンスを作成します。 |
コンバージョンを送信 | コンバージョン情報として raw UID2 を送信 | コンバージョン情報を計測(アトリビューション)または API やピクセルを介してリターゲティングに使用します。 |
グラフデータを受信 | API またはピクセルを介してグラフ/データプロバイダーから raw UID2 を受信 | グラフデータを構築します。 |
High-Level Steps
UID2 とインテグレーションする広告主とデータプロバイダーのインテグレーション手順は、次のとおりです。
POST /identity/map エンドポイントのバージョン 3 より前のバージョンを使用している場合は、Using POST /identity/map Version 2 を参照してください。このバージョンを使用している場合は、強化された機能を利用するためにできるだけ早くアップグレードすることを推奨します。
Summary of Implementation Options
以下の表は、広告主とデータプロバイダー向けの実装オプションを、各レベルのステップごとに示しています。一部のステップは、独自のカスタム実装の一部としてのみ管理されます。一部のステップは、利用可能な UID2 実装オプションの 1 つ以上によって管理できます。詳細は、各ステップのリンクをクリックしてください。
High-Level Step | Implementation Options |
---|---|
1: Generate Raw UID2s from DII | DII を raw UID2 にマップするには、次のいずれかのぷションを利用します:
|
2: Store Raw UID2s and Refresh Timestamps | カスタム(必要に応じて) |
3: Manipulate or Combine Raw UID2s | カスタム(必要に応じて) |
4: Send Stored Raw UID2s to DSPs to Create Audiences or Conversions | カスタム(必要に応じて) |
5: Monitor for Raw UID2 Refresh | POST /identity/map エンドポイントから返されるリフレッシュタイムスタンプ(r フィールド)を使用して、Raw UID2 を更新するタイミングを判断します。 |
6: Monitor for Opt-Out Status | POST /optout/status エンドポイントへの API コール。 |
Integration Diagram
以下の図は、データ収集者がオーディエンスの構築とターゲティングのために DII を raw UID2 にマッピングするために完了する必要があるステップを概説しています。
DII とは、ユーザーの正規化されたメールアドレスまたは電話番号、または正規化されて SHA-256 ハッシュ化されたメールアドレスまたは電話番号を指します。
UID2 ベースのオーディエンス情報を正確かつ最新の状態に保つには、これらのインテグレーションステップを毎日実行してください。
図の各部分の詳細は、以下のセクションを参照してください。
1: Generate Raw UID2s from DII
directly identifying information (DII) から raw UID2 を生成するか、データプロバイダーなどの他の UID2 参加者から UID2 を受信できます。
raw UID2 を生成するには、次のいずれかのオプションを使用します:
-
UID2 SDK のいずれか:
- Python SDK: See Map DII to Raw UID2s.
- Java SDK: See Usage for Advertisers/Data Providers.
-
Snowflake: Map DII を参照してください。
-
AWS Entity Resolution: AWS Entity Resolution Integration Guide を参照してください。
-
HTTP endpoints: POST /identity/map を参照してください。詳細は、Generate Raw UID2s from DII を参照してください。
2: Store Raw UID2s and Refresh Timestamps
Step 1 Generate Raw UID2s from DII のレスポンスには、マッピング情報が含まれています。Step 1 で返される以下の情報を保存することを推奨します:
- DII と raw UID2 (
u
フィールド) のマッピングをキャッシュします。 - リフレッシュタイムスタンプ (
r
フィールド) を保存して、raw UID2 がいつリフレッシュされるかを把握します。 - オプションで、過去 90 日以内に UID2 がリフレッシュされたユーザーのために提供された場合は、前の raw UID2 (
p
フィールド) を保存します。
3: Manipulate or Combine Raw UID2s
Step 1 で受け取った raw UID2 を使用します。たとえば、以下を行うことができます:
- 何らかの操作を行う: たとえば、DII から生成した raw UID2 と、広告主やデータプロバイダーなどの他の参加者から受け取った raw UID2 を組み合わせます。
- 新しい raw UID2 を既存のオーディエンスに追加します。
4: Send Stored Raw UID2s to DSPs to Create Audiences or Conversions
raw UID2 を次の目的で使用します:
- 保存された raw UID2 を DSP に送信して、オーディエンスやコンバージョンを作成します。
- 測定のために raw UID2 を使用します。
たとえば、Step 1 で返された (raw UID2 (u
フィールド)) を DSP に送信してオーディエンスを構築することができます。各 DSP にはオーディエンスを構築するための独自のインテグレーションプロセスがあるため、raw UID2 を送信してオーディエンスを構築するためのインテグレーションガイダンスに従ってください。
コンバージョン情報を API またはピクセルを介して送信して、測定 (アトリビューション) またはリターゲティングを行うこともできます。
5: Monitor for Raw UID2 Refresh
raw UID2 は、特定の時点でのユーザーの識別子です。特定のユーザーの raw UID2 は、UID2 リフレッシュプロセスの一環として、約 1 年に 1 回変更されます。
V3 Identity Map API は、各 raw UID2 がいつリフレッシュされるかを示すリフレッシュタイムスタンプ (r
フィールド) をレスポンスで提供します。このタイムスタンプを使用して、保存されたデータの raw UID2 を再生成するタイミングを判断します。この時刻より前にリフレッシュされないことが保証されています。
リフレッシュのタイミングを毎日確認することを推奨します。raw UID2 をリフレッシュするかどうかを判断するには、次の手順に従います:
-
現在の時刻とPOST /identity/map レスポンスから保存したリフレッシュタイムスタンプ (
r
フィールド) を比較します。 -
If the current time is greater than or equal to the refresh timestamp, regenerate the raw UID2 by calling POST /identity/map again with the same DII.
このアプローチにより、raw UID2 が最新かつ有効であり、オーディエンスのターゲティングや測定に使用できることが保証されます。
6: Monitor for Opt-Out Status
ユーザーのオプトアウトステータスを受け入れることは重要です。定期的にオプトアウトステータスを監視し、最近オプトアウトしたユーザーの raw UID2 を使用し続けないようにします。
UID2 Operator Service で最新のオプトアウト情報を確認するには、次の 2 つの方法があります:
-
POST /identity/map エンドポイントを呼び出してオプトアウトを確認します。DII がオプトアウトされている場合、raw UID2 は生成されません。
-
POST /optout/status エンドポイントを使用して raw UID2 のオプトアウトステータスを確認します。
UID2 オプトアウトワークフローの詳細や、ユーザーがオプトアウトする方法は、User Opt-Out を参照してください。
Using POST /identity/map Version 2
以下の情報は、POST /identity/map
エンドポイントの以前のバージョン 2 を使用するインテグレーションアプローチにのみ関連し、参照用に提供されています。新しい実装では最新バージョンを使用する必要があります: High-Level Steps を参照してください。
Identity Map API のバージョン 2 を使用する場合の主な違いは次のとおりです:
- Step 2: ソルトバケット ID を保存する代わりにリフレッシュタイムスタンプを保存します
- Step 5: ソルトバケットのローテーションを監視する代わりにリフレッシュタイムスタンプを使用します
他のすべてのステップ (1, 3, 4, および 6) は、v3 実装で説明されているとおりです: High-Level Steps を参照してください。
Integration Diagram (v2)
以下の図は、v2 インテグレーションフローを概説しています。主な違いは、Step 2(ソルトバケット ID の保存)と Step 5(ソルトバケットのローテーションの監視)にあります。
Store Raw UID2s and Salt Bucket IDs (v2)
このステップは、v3 実装の Step 2 を置き換えます。
Step 1 のレスポンスには、マッピング情報が含まれています。Step 1 で返される以下の情報を保存することを推奨します:
- DII (
identifier
) と raw UID2 (advertising_id
) とソルトバケット (bucket_id
) のマッピングを保存します。 - レスポンスデータを受信したタイムスタンプを保存します。後で、このタイムスタンプを Step 5 で返される
last_updated
タイムスタンプと比較できます。
Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)
このステップは、v3 実装の Step 5 を置き換えます。
raw UID2 は特定の時点でのユーザーの識別子です。特定のユーザーの raw UID2 は、salt bucketのローテーションの結果として、約 1 年に 1 回変更されます。
各ソルトバケットは約 1 年に 1 回更新されます が、個々のバケットの更新は年間を通じて分散されます。おおよそ 365 分の 1 のソルトバケットが毎日ローテーションされます。これに基づいて、オーディエンスの更新に合わせて定期的にソルトバケットのローテーションを確認することを推奨します。たとえば、毎週更新する場合は、毎週ソルトバケットの更新を確認します。
ソルトバケットがローテーションされた場合は、raw UID2 を再生成します。詳細は、Determine whether the salt bucket has been rotated を参照してください。
ソルトバケットのローテーションを監視する手順は、以下のいずれかを参照してください:
-
Python SDK: Monitor Rotated Salt Buckets
-
Snowflake: Monitor for Salt Bucket Rotation and Regenerate Raw UID2s
-
HTTP endpoints: Monitor for Salt Bucket Rotations for Your Stored Raw UID2s (v2)
AWS Entity Resolution では、ソルトバケットの監視を行う方法はありません。代わりに、AWS Entity Resolution サービスを使用して定期的に raw UID2 を再生成することができます。
Determine whether the salt bucket has been rotated (v2)
特定の raw UID2 のソルトバケット ID が変更されたかどうかを判断するには、次の手順に従います。
- 2 つの値を比較します:
-
ソルトバケットのローテーションを監視する際に返される各
bucket_id
のlast_updated
タイムスタンプ。 -
同じ
bucket_id
の raw UID2 生成のタイムスタンプ。これは Step 1 で返され、Step 2 で保存したものです。
last_updated
タイムスタンプが、先ほど記録したタイムスタンプよりも新しい場合、ソルトバケットがローテーションされています。その結果、このbucket_id
に関連付けられているすべての raw UID2 を、Step1 Generate Raw UID2s from DII に従って再生成する必要があります。
FAQs
UID2 フレーム ワークを使用する広告主とデータプロバイダー向けのよくある質問のリストは、FAQs for Advertisers and Data Providers を参照してください。