メインコンテンツまでスキップ

Frequently Asked Questions

UID2 に関するよくある質問は、以下のカテゴリーに分かれています:

FAQs—General

UID2 フレームワークに関するよくある質問を紹介します。

EUID インフラストラクチャのすべてのインテグレーションパートナー (SSP、第三者データプロバイダー、測定プロバイダー)は、自動的に UID2 にインテグレーションされるのでしょうか?

いいえ。UID2 は EUID とは別の独自のフレームワークとして機能します。そのため、EUID フレームワークへのアクセスや使用に関する事務手続きは、UID2 フレームワークへの使用やアクセスを自動的に許可するものではありません。新規契約を UID2 用に締結する必要があります。

ユーザーは、UID2 ID に関連するターゲティング広告の配信を拒否できますか?

はい。Transparency and Control Portal を通して、ユーザーは自分の UID2 ID に関連するターゲティング広告の配信をオプトアウトできます。各リクエストは、UID2 Opt-Opt Service と UID2 Operator を通じて配信され、UID2 Operator はオプトアウト情報を関連するすべての参加者に公開します。

オプトアウトポータルにアクセスする場所をユーザーが知るにはどうすればよいですか?

パブリッシャー、SSO プロバイダー、または同意管理プラットフォームは、ログインフロー、同意フロー、プライバシーポリシー、およびその他の手段で、Transparency and Control Portalへのリンクを開示します。

UID2 では、HIPAA で規制されているデータを処理できますか?

いいえ。UID2 の参加者は、HIPAA (Health Insurance Portability and Accountability Act of 1996;医療保険の携行性と責任に関する法律) で定義されている、保護対象保険情報 (PHI: Protected Health Information) から UID2 を生成してはなりません。

FAQs for Publishers

UID2 フレームワークを使用するパブリッシャーからのよくある質問です。

送信された DII と返されたトークンが一致していることをテストするにはどうすればよいですか?

POST /token/validate エンドポイントを使用して、POST /token/generate で送信している DII が有効かどうかをチェックできます。POST /token/validate は主にテスト目的で使用されます。

詳細は、Using POST /token/validate to Test を参照してください。

トークンを復号化する必要がありますか?

いいえ、パブリッシャーは UID2 Token を復号化する必要はありません。しかし、社内でのみ使用するために raw UID2 にアクセスしたい場合は、UID2 support と協力してアクセスしてください。

ユーザーの out-out はどのように通知されますか?

ユーザーがオプトアウトした場合、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のどちらでも生成できます。詳細については、以下を参照してください:

Client-Side からトークンのリフレッシュを呼び出すことはできますか?

はい。POST /token/refresh は、API Key を使用する必要がないため、Client-Side (例えば、ブラウザやモバイルアプリ) から呼び出すことができます。

リフレッシュトークンのワークフローをテストするにはどうすればよいですか?

refresh-optout@example.com のメールアドレスまたは +00000000002 の電話番号を使用して、トークンリフレッシュのワークフローをテストすることができます。どちらかのパラメータ値をリクエストに使用すると、常に refresh_token を含む identity レスポンスが生成され、ログアウトレスポンスが返されます。

SDKを使うかどうかで手順は少し異なります。

With SDK:
  1. DII がメールアドレスか電話番号かに応じて、以下の値のいずれかを使用して POST /token/generate リクエストを送信します:
    • email の値として refresh-optout@example.com を指定します。
    • ``refresh-optout@example.comのハッシュをemail_hash` 値として指定します。
    • phone の値として +00000000002 を指定します。
    • phone_hash 値として +00000000002 のハッシュを指定します。
  2. SDK の background auto-refresh が Advertising Token のリフレッシュを試み(これには数時間かかることがあります)、リフレッシュの試みが OPTOUT ステータスで失敗するのを観察するまで待ちます。この時点で SDK はファーストパーティクッキーもクリアします。
Without SDK:
  1. DII がメールアドレスか電話番号かに応じて、以下の値のいずれかを使用して POST /token/generate リクエストを送信します:
    • email の値として refresh-optout@example.com を指定します。
    • refresh-optout@example.com のハッシュを email_hash 値として指定します。
    • phone の値として +00000000002 を指定します。
    • phone_hash 値として +00000000002 のハッシュを指定します。
  2. 返された refresh_token を次のステップで使用するために保存します。
  3. 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 がビッドストリームでどのように渡されるかを示すコードスニペットの一例です:

{
"user":{
"ext":{
"eids":[
{
"source":"uidapi.com",
"uids":[
{
"id":"AgAAAHcy2ka1tSweERARV/wgwM+zM5wK98b9XItZGVgHaU23Eh0XOmAixO6VBcMd3k2ir/TGHLf7O7kQGLyeRPC5/VBSPmugOblMlzgy0B1ZfHQ7ccVurbyzgL1ZZOZ5cBvPDrvfR9MsKqPgWvrIKRkKVTYyUkG5YRAc++xRKfbL/ZSYxQ==",
"rtiPartner":"UID2"
}
]
}
]
}
}
}

FAQs for Advertisers and Data Providers

UID2 フレームワークを使用する広告主やデータプロバイダーによくある質問を紹介します。

ソルトバケットのローテーションにより、UID2 を更新するタイミングを知るにはどうすればよいですか?

UID2 生成リクエストで提供されるメタデータには、UID2 の生成に使用されるソルトバケットが含まれます。ソルトバケットは持続し、UID2 の生成に使用された基礎的な DII に対応します。指定されたタイムスタンプ以降にローテーションしたソルトバケットを得るには、POST /identity/buckets エンドポイントを使用します。返されたローテーションしたソルトバケットは、どの UID2 をリフレッシュすべきかを教えてくれます。

注記

ローテーションがいつ行われるかについては、いかなる約束もいたしません。可能な限り最新の状態を保つため、1 時間に 1 回のチェックをお勧めします。

リフレッシュされたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられるのでしょうか?

必ずしもそうとは限りません。特定のバケット ID に関連付けられたメールアドレスを再マッピングした後、そのメールが異なるバケット ID に割り当てられる可能性があります。バケット ID を確認するには、マッピング関数を呼び出す そして返された UID2 とバケット ID を再び保存してください。

備考

メールアドレスのマッピングや再マッピングを行う際には、バケットの数やローテーションする日、メールアドレスが割り当てられる特定のバケットについて、いかなる仮定も行わないようにしてください。

インクリメンタルアップデートの場合、UID2 はどれくらいの頻度で更新されるべきですか?

オーディエンスの更新は、毎日行うことが推奨されています。

ソルトバケットは 1 年に 1 回程度更新されますが、個々のバケットの更新は 1 年に分散して行われます。これは、全バケットの約 1/365 が毎日ローテーションされることを意味します。もし忠実さが重要であれば、POST /identity/buckets エンドポイントをもっと頻繁に、例えば 1 時間ごとに呼び出すことを検討してください。

マッピング用の DII の SHA-256 はどのように生成すればよいですか?

システムはメールアドレス正規化ルールにしたがって、salt せずにハッシュ化する必要があります。

大量のメールアドレスや電話番号、またはそれらのハッシュマッピングを保存する必要がありますか?

はい。何百万ものメールアドレスや電話番号をマッピングする必要がある場合、マッピングを保存しないことで処理時間が大幅に増加する可能性があります。しかし、実際に更新が必要なマッピングだけを再計算すると、毎日更新する必要があるのは UID2 の約 365 分の 1 なので、総処理時間が短縮されます。

備考

Private Operator を使用している場合を除き、メールアドレス、電話番号、ハッシュのマッピングは、単一の HTTP 接続を使用して、一度に 5,000件 ずつ連続して行う必要があります。言い換えれば、複数の並列接続を作成せずにマッピングを行うことです。

ユーザーのオプトアウトはどのように処理すればよいですか?

ユーザーが Transparency and Control Portal を通じて UID2 ベースのターゲティング広告をオプトアウトすると、オプトアウト信号が DSP とパブリッシャーに送信され、DSP とパブリッシャーが入札時にオプトアウトを処理します。広告主やデータプロバイダーは、POST /identity/map エンドポイントを通じて、ユーザーがオプトアウトしたかどうかを定期的に確認することを勧めます。

ウェブサイトを通じてユーザーがオプトアウトした場合、オプトアウトを処理するための内部手順に従ってください。たとえば、そのユーザーの UID2 を生成しないことを選択することもできます。

FAQs for DSPs

demand-side platform (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 に適応させることができます。詳細は、ソルトバケットのローテーションにより、UID2 を更新するタイミングを知るにはどうすればよいですか? を参照してください。

ユーザーのオプトアウトのトラフィックはすべて DSP に送信されるのでしょうか?

はい、UID2 Transparency and Control Portal からのすべてのオプトアウトは、オプトアウト エンドポイントに到達します。DSP は、ユーザーのオプトアウトを受け入れるように構成する必要があります。

DSP は、既に記憶している UID2 に対してのみオプトアウト信号を処理することを想定しているのでしょうか?

場合によっては、DSP は、オプトアウト・タイムスタンプ以前に生成された、新たに保管された UID2 に対する UID2 Token を受け取ることがあります。DSP はこのようなトークンに入札することはできません。したがって、対応する UID2 が現在 DSP によって保存されているかどうかにかかわらず、すべてのオプトアウト信号を保存することが推奨されます。詳細は、Bidding Opt-Out Logic の図を参照してください。

オプトアウトリストはいつまで保存しておくべきですか?

オプトアウト情報は無期限に保管することを勧めます。

オプトアウトしたユーザーの UID2 は、暗号化された形でオプトアウトエンドポイントに送信されますか?

暗号化されていない (raw)UID2 として送信されます。

オプトアウトされたユーザーの UID2 は、どのような形式で Webhook に送信されますか?

ユーザーがオプトアウトした場合、UID2 Operator は raw UID2 を URL エンコードされたクエリパラメータとして返します。

DSP のオプトアウトプロセスの詳細については、Honor User Opt-Outs を参照してください。

オプトアウトはどのようなリクエストタイプを使用するのですか?

一般的には GET リクエストですが、DSP によって異なるタイプを使用することがあります。

オプトアウトに対応するための要件はどの程度厳しいのでしょうか?

オプトアウトは常に受け入れなければなりません。オプトアウトリクエストがシステムを通じて伝播するまでに時間がかかる場合があり、その間に一部の入札がオプトアウトを受け入れないことがあります。

SDK のエラーは、DSP の入札対応にどのような影響を与えるのでしょうか?

エラーが発生した場合、SDK は UID2 Token を UID2 に復号化しません。