Frequently Asked Questions
UID2 に関するよくある質問は、以下のカテゴリーに分かれています:
FAQs—General
UID2 フレームワークに関するよくある質問を紹介します。
- EUID インフラのすべてのインテグレーションパートナー(SSP、サードパーティデータプロバイダー、測定プロバイダー)は、自動的に UID2 にインテグレーションされますか?
- ユーザーは、自分の UID2 ID に基づいたターゲティング広告をオプトアウトできますか?
- UID2 に DII を送信すると、UID2 はその情報を保存しますか?
- UID2 は HIPAA で規制されているデータの処理を許可しますか?
- パブリックオペレーターとプライベートオペレーターのどちらを使用すべきですか?
モバイルパブリッシャーインテグレーションに関する 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 用に締結する必要があります。
Can users opt out of targeted advertising tied to their UID2?
ユーザーは、自分の UID2 ID に基づいたターゲティング広告をオプトアウトできますか?
はい。Transparency and Control Portal を通して、ユーザーは自分の UID2 に関連するターゲティング広告の配信をオプトアウトできます。各リクエストは、UID2 Opt-Opt Service と UID2 Operator を通じて配信され、UID2 Operator はオプトアウト情報を関連するすべての参加者に公開します。
When I send DII to UID2, does UID2 store the information?
UID2 に DII を送信すると、UID2 はその情報を保存しますか?
いいえ。UID2 service のコンポーネントは、DII を保存しません。
さらに、ほとんどの場合、UID2 は、POST /token/generate、POST /token/refresh、ま たは POST /identity/map の呼び出しが完了すると、値を全く保存しません。必要な例外は、ユーザーがオプトアウトした場合です。この場合、UID2 は、オプトアウトしたユーザーを示すハッシュ化された不透明な値を保存します。保存された値は、DII から生成された同じ UID2 に関する将来のリクエストを識別するために使用され、そのため拒否されます。
Does UID2 allow the processing of HIPAA-regulated data?
UID2 は HIPAA で規制されているデータの処理を許可しますか?
いいえ。UID2 の参加者は、HIPAA (Health Insurance Portability and Accountability Act of 1996;医療保険の携行性と責任に関する法律) で定義されている、保護対象保険情報 (PHI: Protected Health Information) から UID2 を生成してはなりません。
Should I use a Public Operator or a Private Operator?
パブリックオペレーターとプライベートオペレーターのどちらを使用すべきですか?
ほとんどの参加者にとって、Public Operator が最もシンプルなソリューションです。Public Operator のインテグレーションは、独自の Private Operator をホストするよりも簡単なオプションです。Private Operator インスタンスを持つことにはいくつかの利点がありますが、追加の複雑さとコストがかかります。
最適な選択肢は、自身の状況やニーズによって異なります。決定に役立つ情報については、以下を参照してください:
FAQs for Publishers
UID2 フレームワークを使用するパブリッシャーからのよくある質問です。
- 送信した DII と返されたトークンが一致していることをテストするにはどうすればよいですか?
- トークンを復号化する必要がありますか?
- ユーザーのオプトアウトはどのように通知されますか?
- トークン生成の呼び出しは、Server-Side と Client-Side のどちらで行うべきですか?
- Client-Side からトークンのリフレッシュを呼び出すことはできますか?
- トークンを手動でリフレッシュする場合、リフレッシュのタイミングをどう判断すればよいですか?
- Refresh Token のワークフローをテストするにはどうすればよいですか?
- UID2 Token の一意性とローテーションポリシーは何ですか?
- UID2 Token は、ビッドストリームではどのように見えますか?
- UID2 をシングルサインオン (SSO) とインテグレーションすることはできますか?
How can I test that the DII sent and the returned token match up?
送信した DII と返されたトークンが一致していることをテストするにはどうすればよいですか?
POST /token/validate エンドポイントを使用して、POST /token/generate で送信している DII が有効かどうかをチェックできます。POST /token/validate
は主にテスト目的で使用されます。
詳細は Using POST /token/validate to Test を参照してくださ い。
Do I need to decrypt tokens?
トークンを復号化する必要がありますか?
いいえ、パブリッシャーは UID2 token を復号化する必要はありません。しかし、社内でのみ使用するために raw UID2 にアクセスしたい場合は、UID2 support と協力してアクセスしてください。
How will I be notified of user opt-out?
ユーザーのオプトアウトはどのように通知されますか?
ユーザーがオプトアウトした場合、API レスポンスは以下のいずれかのケースで通知します:
- 直接または UID2 SDK のいずれかで POST /token/generate エンドポイントを呼び出し、UID2 Token を生成する場合、必須の
optout_check
パラメータに1
を指定します。 - 直接または UID2 SDK のいずれかで POST /token/refresh エンドポイントを呼び出し、UID2 Token をリフレッシュした場合。
Where should I make token generation calls—from the server side or the client side?
トークン生成の呼び出しは、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.
Can I make token refresh calls from the client side?
Client-Side からトークンのリフレッシュを呼び出すことはできますか?
はい。POST /token/refresh は、API Key を使用する必要がないため、Client-Side (たとえば、ブラウザやモバイルアプリ) から呼び出すことができます。
If I choose to manually refresh the token, how will I know when to refresh the token?
トークンを手動でリフレッシュする場合、リフレッシュのタイミングをどう判断すればよいですか?
推奨されるリフレッシュ間隔は 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 を参照してください。
How can I test the refresh token workflow?
Refresh Token のワークフローをテストするにはどうすればよいですか?
refresh-optout@example.com
のメールアドレスまたは +00000000002
の電話番号を使用して、トークンリフレッシュのワークフローをテストすることができます。どちらかのパラメータ値をリクエストに使用すると、常に refresh_token
を含む identity レスポンスが生成され、ログアウトレスポンスが返されます。
メールアドレスの正規化、ハッシュ化、Base64 エンコードされたハッシュ値、または、電話番号のハッシュ化、Base64 エンコードされたハッシュ値を取得するには、ハッシングツールを使用できます。詳細は、UID2 Hashing Tool を参照してください。
SDKを使うかどうかで手順は少し異なります。
With 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 はファーストパーティクッキーもクリアします。
Without 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
でなければなりません。
What is the uniqueness and rotation policy for UID2 tokens?
UID2 Token の一意性とローテーションポリシーは何ですか?
UID2 Service は、ランダムな初期化ベクトルを使用して UID2 Token を暗号化します。UID2 Token は、ユーザーがインターネットを閲覧する際に、特定のユーザーに対して一意になります。つまり、UID2 Token が生成されるたびに、同じ UID2 であっても常に異なるトークンが生成されます。トークンが更新されるたびに新しいトークンが生成され、暗号化されます。
What does a UID2 token look like in the bidstream?
UID2 Token は、ビッドストリームではどのように見えますか?
UID2 実装のアプローチにはさまざまな方法があります。以下は、UID2 Token がビッドストリームでどのように渡されるかを示すコードスニペットの一例です:
{
"user": {
"ext": {
"eids": [
{
"source": "uidapi.com",
"uids": [
{
"id": "A4AAAABlh75XmviGJi-hkLGs96duivRhMd3a3pe7yTIwbAHudfB9wFTj2FtJTdMW5TXXd1KAb-Z3ekQ_KImZ5Mi7xP75jRNeD6Mt6opWwXCCpQxYejP0R6WnCGnWawx9rLu59LsHv6YEA_ARNIUUl9koobfA9pLmnxE3dRedDgCKm4xHXYk01Fr8rOts6iJj2AhYISR3XkyBpqzT-vqBjsHH0g",
"rtiPartner": "UID2"
}
]
}
]
}
}
}
Can I integrate UID2 with Single Sign-On (SSO)?
UID2 をシングルサインオン (SSO) とインテグレーションすることはできますか?
はい。Google、Facebook ログイン、Apple ログイン、または OpenPass などの人気のある SSO インテグレーションオプションを使用すると、メールアドレスを取得して UID2 を生成できます。 詳細は、Publisher Integration with SSO Providers を参照してください。
FAQs for Advertisers and Data Providers
UID2 フレームワークを使用する広告主やデータプロバイダーによくある質問を紹介します。
- ソルトバケットのローテーションによって UID2 をリフレッシュするタイミングを知るには?
- 更新されたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられますか?
- インクリメンタルアップデートの場合、UID2 はどのくらいの頻度で更新するべきですか?
- マッピング用の DII の SHA-256 はどのように生成すればよいですか?
- メールアドレス、電話番号、または対応するハッシュと raw UID2 のマッピングを、自身のデータセットに保存すべきでしょうか?
- ユーザーのオプトアウトはどのように処理すればよいですか?
- 同じ DII は常に同じ生UID2になりますか?
- 2 つの Operator が同じ DII を処理した場合、結果は同じになりますか?
How do I know when to refresh the UID2 due to salt bucket rotation?
ソルトバケットのローテーションによって UID2 をリフレッシュするタイミングを知るには?
UID2 生成リクエストで提 供されるメタデータには、UID2 の生成に使用される salt bucket が含まれます。ソルトバケットは持続し、UID2 の生成に使用された基礎となる DII に対応します。指定されたタイムスタンプ以降にローテーションしたソルトバケットを得るには、POST /identity/buckets エンドポイントを使用します。返されたローテーションしたソルトバケットは、どの UID2 をリフレッシュすべきかを教えてくれます。
ローテーションがいつ行われるかについては、いかなる約束もいたしません。可能な限り最新の状態を保つため、1 時間に 1 回のチェックを勧めます。
Do refreshed emails get assigned to the same bucket with which they were previously associated?
更新されたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられますか?
必ずしもそうとは限りません。特定のバケット ID に関連付けられたメールアドレスを再マッピングした後、そのメールが異なるバケット ID に割り当てられる可能性があります。バケット ID を確認するには、マッピング関数を呼び出す そして返された raw UID2 とバケット ID を再び保存してください。
メールアドレスのマッピングや再マッピングを行う際には、バケットの数やローテーションする日、メールアドレスが割り当てられる特定のバケットについて、いかなる仮定も行わないようにしてください。
How often should UID2s be refreshed for incremental updates?
インクリメンタルアップデートの場合、UID2 はどのくらいの頻度で更新するべきですか?
オーディエンスの更新は、毎日行うことが推奨されています。
ソルトバケットは 1 年に 1 回程度更新されますが、個々のバケットの更新は 1 年に分散して行われます。これは、全バケットの約 1/365 が毎日ローテーションされることを意味します。もし忠実さが重要であれば、POST /identity/buckets エンドポイントをもっと頻繁に、たとえば 1 時間ごとに呼び出すことを検討してください。
How should I generate the SHA-256 of DII for mapping?
マッピング用の 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 なので、総処理時間が短縮されます。
Private Operator を使用していない場合は、単一の HTTP 接続を使用して、バッチあたり最大 5,000 アイテムのバッチサイズで、メールアドレス、電話番号、またはハッシュを連続してマッピングする必要があります。つまり、複数の並行接続を作成せずにマッピングを行ってください。
How should I handle user opt-outs?
ユーザーのオプトアウトはどのように処理すればよいですか?
ユーザーが Transparency and Control Portal を通じて UID2 ベースのターゲティング広告をオプトアウトすると、オプトアウト信号が DSP とパブリッシャーに送信され、DSP とパブリッシャーが入札時にオプトアウトを処理します。広告主やデータプロバイダーは、POST /identity/map エンドポイントを通じて、ユーザーがオプトアウトしたかどうかを定期的に確認することを勧めます。
広告主やデータプロバイダーは、raw UID2 に対するオプトアウトステータスを確認するために、POST /optout/status エンドポイントを使用することもできます。
ウェブサイトを通じてユーザーがオプトアウトした場合、オプトアウトを処理するための内部手順に従ってください。たとえば、そのユーザーの UID2 を生成しないことを選択することもできます。
Does the same DII always result in the same raw 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 for Your Stored Raw UID2s を参照してください。
If two operators process the same DII, are the results the same?
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 が含まれます。ただし、トークン自体は常に一意です。
FAQs for DSPs
demand-side platform (DSP) に関するよくある質問を紹介します。
- UID2 に適用する復号キーを知るには?
- 復号キーはどこで入手できますか?
- メモリ上に存在する復号鍵の数は?
- ソルトバケットがローテーションしたかどうか、あるいはいつローテーションしたかを知るにはどうし たらいいですか?
- DSP はレイテンシーを気にすべきでしょうか?
- UID2 で DSP はどのように適切なフリクエンシーキャッピング周波数キャッピングを維持すべきでしょうか?
- ユーザーのオプトアウトトラフィックはすべて DSP に送られますか?
- DSP は、すでに保存している UID2 についてのみオプトアウトシグナルを処理することを期待されているのか?
- DSP はオプトアウトリストをどれくらいの期間保管すべきですか?
- オプトアウトされたユーザーの UID2 は、暗号化された形式でオプトアウトエンドポイントに送信されますか?
- オプトアウトされたユーザーの UID2 は、どのような形式で Webhook に送信されますか?
- オプトアウトはどのリクエストタイプを使いますか?
- オプトアウトに応じるための条件はどの程度厳しいのですか?
- ユーザーがオプトアウトしたかどうかを確認するにはどうすればよいですか?
- SDK のエラーは DSP の入札対応能力にどのような影響 を与えますか?
How do I know which decryption key to apply to a UID2?
UID2 に適用する復号キーを知るには?
各 Server-Side SDK (SDKs: Summary を参照)は、復号鍵を自動的に更新します。UID2 Token と共に提供されるメタデータは、使用する復号鍵の ID を示します。
Where do I get the decryption keys?
復号キーはどこで入手できますか?
Server-Side SDK のいずれか(SDK を参照) を使用して UID2 Service と通信し、最新の鍵を取得することができます。鍵を確実に最新に保つため、1 時間に 1 回など、定期的に鍵を取得することを推奨します。
How many decryption keys may be present in memory at any point?
メモリ上に存在する復号鍵の数は?
システムには、ある時点で 何千もの復号鍵が存在する可能性があります。
How do I know if/when the salt bucket has rotated?
ソルトバケットがローテーションしたかどうか、あるいはいつローテーションしたかを知るにはどうしたらいいですか?
DSP は、UID2 ソルトバケットがいつローテーションしたかを知ることができません。これは、ユーザーが Cookie をクリアしても DSP が気づかないのと同じです。ソルトバケットのローテーションは、DSP に大きな影響を与えません。
Should the DSP be concerned with latency?
DSP はレイテンシーを気にすべきでしょうか?
UID2 Service は、入札プロセスに遅延を生じさせることはありません。発生した遅延は、UID2 Service ではなく、ネットワークに起因すると考えられます