| title | description | hide_table_of_contents | sidebar_position |
|---|---|---|---|
FAQs |
UID2 の実装に関するよくある質問。 |
false |
20 |
import Link from '@docusaurus/Link'; import ExampleTokenInBidstream from '../snippets/_example-token-in-bidstream.mdx';
UID2 に関するよくある質問は、以下のカテゴリーに分かれています:
UID2 フレームワークに関するよくある質問を紹介します。
- EUID インフラのすべてのインテグレーションパートナー(SSP、サードパーティデータプロバイダー、測定プロバイダー)は、自動的に UID2 にインテグレーションされますか？
- ユーザーは、自分の UID2 ID に基づいたターゲティング広告をオプトアウトできますか？
- UID2 に DII を送信すると、UID2 はその情報を保存しますか？
- UID2 は HIPAA で規制されているデータの処理を許可しますか？
- パブリックオペレーターとプライベートオペレーターのどちらを使用すべきですか？
:::note モバイルパブリッシャーインテグレーションに関する FAQs については、FAQs for Mobile Integrations を参照してください。 :::
Will all integration partners in the EUID infrastructure (SSPs, third-party data providers, measurement providers) be automatically integrated with UID2?
EUID インフラのすべてのインテグレーションパートナー(SSP、サードパーティデータプロバイダー、測定プロバイダー)は、自動的に UID2 にインテグレーションされますか？
いいえ。UID2 は EUID とは別の独自のフレームワークとして機能します。そのため、EUID フレームワークへのアクセスや使用に関する事務手続きは、UID2 フレームワークへの使用やアクセスを自動的に許可するものではありません。新規契約を UID2 用に締結する必要があります。
ユーザーは、自分の UID2 ID に基づいたターゲティング広告をオプトアウトできますか？
はい。Transparency and Control Portal を通して、ユーザーは自分の UID2 に関連するターゲティング広告の配信をオプトアウトできます。各リクエストは、UID2 Opt-Opt Service と UID2 Operator を通じて配信され、UID2 Operator はオプトアウト情報を関連するすべての参加者に公開します。
UID2 に DII を送信すると、UID2 はその情報を保存しますか？
いいえ。UID2 service のコンポーネントは、DII を保存しません。
さらに、ほとんどの場合、UID2 は、POST /token/generate、POST /token/refresh、または POST /identity/map の呼び出しが完了すると、値を全く保存しません。必要な例外は、ユーザーがオプトアウトした場合です。この場合、UID2 は、オプトアウトしたユーザーを示すハッシュ化された不透明な値を保存します。保存された値は、DII から生成された同じ UID2 に関する将来のリクエストを識別するために使用され、そのため拒否されます。
UID2 は HIPAA で規制されているデータの処理を許可しますか？
いいえ。UID2 の参加者は、HIPAA (Health Insurance Portability and Accountability Act of 1996;医療保険の携行性と責任に関する法律) で定義されている、保護対象保険情報 (PHI: Protected Health Information) から UID2 を生成してはなりません。
パブリックオペレーターとプライベートオペレーターのどちらを使用すべきですか？
ほとんどの参加者にとって、Public Operator が最もシンプルなソリューションです。Public Operator のインテグレーションは、独自の Private Operator をホストするよりも簡単なオプションです。Private Operator インスタンスを持つことにはいくつかの利点がありますが、追加の複雑さとコストがかかります。
最適な選択肢は、自身の状況やニーズによって異なります。決定に役立つ情報については、以下を参照してください:
UID2 フレームワークを使用するパブリッシャーからのよくある質問です。
- 送信した DII と返されたトークンが一致していることをテストするにはどうすればよいですか？
- トークンを復号化する必要がありますか？
- ユーザーのオプトアウトはどのように通知されますか？
- トークン生成の呼び出しは、Server-Side と Client-Side のどちらで行うべきですか？
- Client-Side からトークンのリフレッシュを呼び出すことはできますか？
- トークンを手動でリフレッシュする場合、リフレッシュのタイミングをどう判断すればよいですか？
- Refresh Token のワークフローをテストするにはどうすればよいですか？
- UID2 Token の一意性とローテーションポリシーは何ですか？
- UID2 Token は、ビッドストリームではどのように見えますか？
送信した DII と返されたトークンが一致していることをテストするにはどうすればよいですか？
POST /token/validate エンドポイントを使用して、POST /token/generate で送信している DII が有効かどうかをチェックできます。POST /token/validate は主にテスト目的で使用されます。
詳細は Using POST /token/validate to Test を参照してください。
トークンを復号化する必要がありますか？
いいえ、パブリッシャーは UID2 token を復号化する必要はありません。しかし、社内でのみ使用するために raw UID2 にアクセスしたい場合は、UID2 support と協力してアクセスしてください。
ユーザーのオプトアウトはどのように通知されますか？
ユーザーがオプトアウトした場合、API レスポンスは以下のいずれかのケースで通知します:
- 直接または UID2 SDK のいずれかで POST /token/generate エンドポイントを呼び出し、UID2 Token を生成する場合、必須の
optout_checkパラメータに1を指定します。 - 直接または UID2 SDK のいずれかで POST /token/refresh エンドポイントを呼び出し、UID2 Token をリフレッシュした場合。
トークン生成の呼び出しは、Server-Side と Client-Side のどちらで行うべきですか？
UID2 Token は、Client-Side、Server-Sideのどちらでも生成できます。詳細については、以下を参照してください:
- Prebid.js を使用して Client-Side からトークンを生成します: UID2 Client-Side Integration Guide for Prebid.js.
- Prebid.js を使用して Server-Side からトークンを生成します: UID2 Client-Server Integration Guide for Prebid.js.
- その他の Server-Side オプション: Publisher Integrations.
Client-Side からトークンのリフレッシュを呼び出すことはできますか？
はい。POST /token/refresh は、API Key を使用する必要がないため、Client-Side (例えば、ブラウザやモバイルアプリ) から呼び出すことができます。
トークンを手動でリフレッシュする場合、リフレッシュのタイミングをどう判断すればよいですか？
推奨されるリフレッシュ間隔は 1 時間です。
リフレッシュのタイミングを決定するには、POST /token/generate エンドポイントのレスポンスの refresh_from フィールドのタイムスタンプを使用します(詳細は Successful Response を参照してください)。または、POST /token/refresh エンドポイントのレスポンスの refresh_from フィールドのタイムスタンプを使用します(詳細は Successful Response With Tokens を参照してください)。
Token Refreshが必要かどうかを確認する機能を持つ SDK のいずれかを使用することもできます。
詳細は、Recommended Token Refresh Frequency および Managing Token Refresh with an SDK を参照してください。
Refresh Token のワークフローをテストするにはどうすればよいですか？
refresh-optout@example.com のメールアドレスまたは +00000000002 の電話番号を使用して、トークンリフレッシュのワークフローをテストすることができます。どちらかのパラメータ値をリクエストに使用すると、常に refresh_token を含む identity レスポンスが生成され、ログアウトレスポンスが返されます。
:::tip メールアドレスの正規化、ハッシュ化、Base64 エンコードされたハッシュ値、または、電話番号のハッシュ化、Base64 エンコードされたハッシュ値を取得するには、ハッシングツールを使用できます。詳細は、UID2 Hashing Tool を参照してください。 :::
SDKを使うかどうかで手順は少し異なります。
- DII がメールアドレスか電話番号かに応じて、以下の値のいずれかを使用して POST /token/generate リクエストを送信します:
emailの値:refresh-optout@example.com.email_hashの値:refresh-optout@example.comをハッシュ化し Base64 エンコードした値はNaNI8RU0bL1Jpp1jJLC5aJO/lchc6gGhgXQIAwJ7cV4=です。phoneの値:+00000000002.phone_hash+00000000002をハッシュ化し Base64 エンコードした値は0VoxsIuk88qt7TnZaTC//C9Vur3pR1zBMIr1cJe7xjE=です。
- SDK の background auto-refresh が Advertising Token のリフレッシュを試み(これには数時間かかることがあります)、リフレッシュの試みが
OPTOUTステータスで失敗するのを観察するまで待ちます。この時点で SDK はファーストパーティクッキーもクリアします。
-
DII がメールアドレスか電話番号かに応じて、以下の値のいずれかを使用して POST /token/generate リクエストを送信します:
emailの値:refresh-optout@example.com.email_hashの値:refresh-optout@example.comをハッシュ化し Base64 エンコードした値はNaNI8RU0bL1Jpp1jJLC5aJO/lchc6gGhgXQIAwJ7cV4=です。phoneの値:+00000000002.phone_hash+00000000002をハッシュ化し Base64 エンコードした値は0VoxsIuk88qt7TnZaTC//C9Vur3pR1zBMIr1cJe7xjE=です。
-
返された
refresh_tokenを次のステップで使用するために保存します。 -
POST /token/refresh リクエストを
refresh_token(Step 2 で保存) をtoken値として送信します。
ボディのレスポンスは空でなければならず、refresh-optout@example.comのメールアドレスと+00000000002の電話番号は常にログアウトしたユーザになるので、statusの値はoptoutでなければなりません。
UID2 Token の一意性とローテーションポリシーは何ですか？
UID2 Service は、ランダムな初期化ベクトルを使用して UID2 Token を暗号化します。UID2 Token は、ユーザーがインターネットを閲覧する際に、特定のユーザーに対して一意になります。つまり、UID2 Token が生成されるたびに、同じ UID2 であっても常に異なるトークンが生成されます。トークンが更新されるたびに新しいトークンが生成され、暗号化されます。
UID2 Token は、ビッドストリームではどのように見えますか？
UID2 実装のアプローチにはさまざまな方法があります。以下は、UID2 Token がビッドストリームでどのように渡されるかを示すコードスニペットの一例です:
UID2 フレームワークを使用する広告主やデータプロバイダーによくある質問を紹介します。
- ソルトバケットのローテーションによって UID2 をリフレッシュするタイミングを知るには？
- 更新されたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられますか？
- インクリメンタルアップデートの場合、UID2 はどのくらいの頻度で更新するべきですか？
- マッピング用の DII の SHA-256 はどのように生成すればよいですか？
- メールアドレス、電話番号、または対応するハッシュと raw UID2 のマッピングを、自身のデータセットに保存すべきでしょうか？
- ユーザーのオプトアウトはどのように処理すればよいですか？
- 同じ DII は常に同じ生UID2になりますか？
- 2 つの Operator が同じ DII を処理した場合、結果は同じになりますか？
ソルトバケットのローテーションによって UID2 をリフレッシュするタイミングを知るには？
UID2 生成リクエストで提供されるメタデータには、UID2 の生成に使用される salt bucket が含まれます。ソルトバケットは持続し、UID2 の生成に使用された基礎となる DII に対応します。指定されたタイムスタンプ以降にローテーションしたソルトバケットを得るには、POST /identity/buckets エンドポイントを使用します。返されたローテーションしたソルトバケットは、どの UID2 をリフレッシュすべきかを教えてくれます。
:::note ローテーションがいつ行われるかについては、いかなる約束もいたしません。可能な限り最新の状態を保つため、1 時間に 1 回のチェックを勧めます。 :::
更新されたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられますか？
必ずしもそうとは限りません。特定のバケット ID に関連付けられたメールアドレスを再マッピングした後、そのメールが異なるバケット ID に割り当てられる可能性があります。バケット ID を確認するには、マッピング関数を呼び出す そして返された UID2 とバケット ID を再び保存してください。
:::info メールアドレスのマッピングや再マッピングを行う際には、バケットの数やローテーションする日、メールアドレスが割り当てられる特定のバケットについて、いかなる仮定も行わないようにしてください。 :::
インクリメンタルアップデートの場合、UID2 はどのくらいの頻度で更新するべきですか？
オーディエンスの更新は、毎日行うことが推奨されています。
ソルトバケットは 1 年に 1 回程度更新されますが、個々のバケットの更新は 1 年に分散して行われます。これは、全バケットの約 1/365 が毎日ローテーションされることを意味します。もし忠実さが重要であれば、POST /identity/buckets エンドポイントをもっと頻繁に、例えば 1 時間ごとに呼び出すことを検討してください。
マッピング用の DII の SHA-256 はどのように生成すればよいですか？
システムはメールアドレス正規化ルールに従って、salt せずにハッシュ化する必要があります。
Should I store mapping of email addresses, phone numbers, or corresponding hashes to raw UID2s in my own datasets?
メールアドレス、電話番号、または対応するハッシュと raw UID2 のマッピングを、自身のデータセットに保存すべきでしょうか？
はい。何百万ものメールアドレスや電話番号をマッピングする必要がある場合、マッピングを保存しないことで処理時間が大幅に増加する可能性があります。しかし、実際に更新が必要なマッピングだけを再計算すると、毎日更新する必要があるのは UID2 の約 365 分の 1 なので、総処理時間が短縮されます。
:::important
Private Operator を使用していない場合は、単一の HTTP 接続を使用して、バッチあたり最大 5,000 アイテムのバッチサイズで、メールアドレス、電話番号、またはハッシュを連続してマッピングする必要があります。つまり、複数の並行接続を作成せずにマッピングを行ってください。 :::ユーザーのオプトアウトはどのように処理すればよいですか？
ユーザーが Transparency and Control Portal を通じて UID2 ベースのターゲティング広告をオプトアウトすると、オプトアウト信号が DSP とパブリッシャーに送信され、DSP とパブリッシャーが入札時にオプトアウトを処理します。広告主やデータプロバイダーは、POST /identity/map エンドポイントを通じて、ユーザーがオプトアウトしたかどうかを定期的に確認することを勧めます。
広告主やデータプロバイダーは、raw UID2 に対するオプトアウトステータスを確認するために、POST /optout/status エンドポイントを使用することもできます。
ウェブサイトを通じてユーザーがオプトアウトした場合、オプトアウトを処理するための内部手順に従ってください。たとえば、そのユーザーの UID2 を生成しないことを選択することもできます。
同じ DII は常に同じ raw UID2 になりますか？
一般的にその通りです。DII から raw UID2 を生成するプロセスは同じであり、誰がリクエストを送信したかに関係なく、結果は同じ値になります。 2 人の UID2 参加者が同じメールアドレスを POST /identity/map エンドポイントに同時に送信した場合、応答として両方とも同じ raw UID2 を取得します。
ただし、raw UID2 の生成に使用される ソルト 値という可変要素があります。ソルト値は定期的にローテーションされます(詳細は How often should UID2s be refreshed for incremental updates?) を参照してください)。あるリクエストと別のリクエストの間でソルト値が変化する場合、DII が同じであっても、これら 2 つのリクエストは 2 つの異なる raw UID2 になります。
詳細については、Advertiser/Data Provider Integration Guideの Monitor for salt bucket rotations related to your stored raw UID2s を参照してください。
2 つの Operator が同じ DII を処理した場合、結果は同じになりますか？
はい、リクエストが raw UID2 に対するものである場合は、同じです。前の FAQ で説明したように、同じ DII は常に同じ raw UID2 になりますか？、広告主やデータプロバイダーが同時に同じ DII を UID2 Operator に送信する場合、SDK または POST /identity/map エンドポイントを使用して、同じ raw UID2 が生成されます。
Operator に関係なく、また、Private Operator と Public Operator のどちらであっても、結果は同じです。タイミングが重要なのは、ソルトバケットのローテーションのためです。リクエスト間でソルト値が変化すると、結果は異なる raw UID2 になります。
しかし、パブリッシャーが POST /token/generate または POST /token/refresh エンドポイント経由、または SDK 経由で UID2 Token のリクエストに DII を送信した場合、生成される UID2 Token には同じ暗号化された raw UID が含まれます。ただし、トークン自体は常に一意です。
demand-side platform (DSP) に関するよくある質問を紹介します。
- UID2 に適用する復号キーを知るには？
- 復号キーはどこで入手できますか？
- メモリ上に存在する復号鍵の数は？
- ソルトバケットがローテーションしたかどうか、あるいはいつローテーションしたかを知るにはどうしたらいいですか？
- DSP はレイテンシーを気にすべきでしょうか？
- UID2 で DSP はどのように適切なフリクエンシーキャッピング周波数キャッピングを維持すべきでしょうか？
- ユーザーのオプトアウトトラフィックはすべて DSP に送られますか？
- DSP は、すでに保存している UID2 についてのみオプトアウトシグナルを処理することを期待されているのか？
- DSP はオプトアウトリストをどれくらいの期間保管すべきですか？
- オプトアウトされたユーザーの UID2 は、暗号化された形式でオプトアウトエンドポイントに送信されますか？
- オプトアウトされたユーザーの UID2 は、どのような形式で Webhook に送信されますか？
- オプトアウトはどのリクエストタイプを使いますか？
- オプトアウトに応じるための条件はどの程度厳しいのですか？
- ユーザーがオプトアウトしたかどうかを確認するにはどうすればよいですか？
- SDK のエラーは DSP の入札対応能力にどのような影響を与えますか？
UID2 に適用する復号キーを知るには？
各 Server-Side SDK (SDKs: Summary を参照)は、復号鍵を自動的に更新します。UID2 Token と共に提供されるメタデータは、使用する復号鍵の ID を示します。
復号キーはどこで入手できますか？
Server-Side SDK のいずれか(SDK を参照してください) を使用して UID2 Service と通信し、最新の鍵を取得することができます。鍵を確実に最新に保つため、1 時間に 1 回など、定期的に鍵を取得することを推奨します。
メモリ上に存在する復号鍵の数は？
システムには、ある時点で何千もの復号鍵が存在する可能性があります。
ソルトバケットがローテーションしたかどうか、あるいはいつローテーションしたかを知るにはどうしたらいいですか？
DSP は、UID2 ソルトバケットがいつローテーションしたかを知ることができません。これは、ユーザーが Cookie をクリアしても DSP が気づかないのと同じです。ソルトバケットのローテーションは、DSP に大きな影響を与えません。
DSP はレイテンシーを気にすべきでしょうか？
UID2 Service は、入札プロセスに遅延を生じさせることはありません。発生した遅延は、UID2 Service ではなく、ネットワークに起因すると考えられます
UID2 で DSP はどのように適切なフリクエンシーキャッピング周波数キャッピングを維持すべきでしょうか？
UID2 は、クッキーと同じように古くなる可能性があります。したがって、DSP は、クッキーまたは Device ID ベースのフリークエンシーキャッピングに現在使用されているものと同じインフラを UID2 に適応させることができます。詳細は How do I know when to refresh the UID2 due to salt bucket rotation? を参照してください。
ユーザーのオプトアウトトラフィックはすべて DSP に送られますか？
はい、UID2 Transparency and Control Portal からのすべてのオプトアウトは、オプトアウトエンドポイントに到達します。DSP は、ユーザーのオプトアウトを受け入れるように構成する必要があります。
DSP は、すでに保存している UID2 についてのみオプトアウトシグナルを処理することを期待されているのか？
場合によっては、DSP は、オプトアウトタイムスタンプ以前に生成された、新たに保管された UID2 に対する UID2 Token を受け取ることがあります。DSP はこのようなトークンに入札することはできません。したがって、対応する UID2 が現在 DSP によって保存されているかどうかにかかわらず、すべてのオプトアウトシグナルを保存することが推奨されます。詳細は Bidding Opt-Out Logic の図を参照してください。
DSP はオプトアウトリストをどれくらいの期間保管すべきですか？
オプトアウト情報は無期限に保管することを勧めます。
オプトアウトされたユーザーの UID2 は、暗号化された形式でオプトアウトエンドポイントに送信されますか？
暗号化されていない (raw)UID2 として送信されます。
オプトアウトされたユーザーの UID2 は、どのような形式で Webhook に送信されますか？
ユーザーがオプトアウトした場合、UID2 Operator は raw UID2 を URL エンコードされたクエリパラメータとして返します。
DSP のオプトアウトプロセスの詳細は Honor User Opt-Outs を参照してください。
オプトアウトはどのリクエストタイプを使いますか？
一般的には GET リクエストですが、DSP によって異なるタイプを使用することがあります。
オプトアウトに応じるための条件はどの程度厳しいのですか？
オプトアウトは常に受け入れなければなりません。オプトアウトリクエストがシステムを通じて伝播するまでに時間がかかる場合があり、その間に一部の入札がオプトアウトを受け入れないことがあります。
ユーザーがオプトアウトしたかどうかを確認するにはどうすればよいですか？
DSP は、POST /optout/status エンドポイントを使用して、生 UID2 に対するオプトアウトステータスを確認できます。
SDK のエラーは DSP の入札対応能力にどのような影響を与えますか？
エラーが発生した場合、SDK は UID2 Token を UID2 に復号化しません。