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

Frequently Asked Questions

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

FAQs—General​

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

Will all integration partners in the EUID infrastructure (SSPs, third-party data providers, measurement providers) be automatically integrated with UID2?​

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

Can users opt out of targeted advertising tied to their UID2 identity?​

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

When I send DII to UID2, does UID2 store the information?​

いいえ、UID2 にはは DII を保存しません。さらに、ほとんどの場合、UID2はPOST /token/generate, POST /token/refresh、POST /identity/map が実行されると、値をまったく保存しません。

必要な例外は、ユーザーがオプトアウトした場合です。このシナリオでは、UID2 には、オプトアウトされたユーザーを示すハッシュ化された不透明な値が格納されます。保存された値をリバース エンジニアリングして DII の元の値に戻すことはできませんが、同じ DII から生成された UID2 に対する将来の要求を識別するために使用できるため、これらのリクエストは拒否されます。

Does UID2 allow the processing of HIPAA-regulated data?​

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

FAQs for Publishers​

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

How can I test that the DII sent and the returned token match up?​

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 or client side?​

UID2 Token は、Client-Side、Server-Sideのどちらでも生成できます。詳細については、以下を参照してください:

Can I make token refresh calls from the client side?​

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

How can I test the refresh token workflow?​

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 でなければなりません。

What is the uniqueness and rotation policy for UID2 tokens?​

UID2 Service は、ランダムな初期化ベクトルを使用して UID2 Token を暗号化します。UID2 Token は、ユーザーがインターネットを閲覧する際に、特定のユーザーに対して一意になります。つまり、UID2 Token が生成されるたびに、同じ UID2 であっても常に異なるトークンが生成されます。トークンが更新されるたびに新しいトークンが生成され、暗号化されます。この仕組みにより、信頼できない当事者がユーザーの身元を追跡できないようにすることができます。

What does a UID2 token look like in the bid stream?​

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 フレームワークを使用する広告主やデータプロバイダーによくある質問を紹介します。

How do I know when to refresh the UID2 due to salt bucket rotation?​

UID2 生成リクエストで提供されるメタデータには、UID2 の生成に使用されるソルトバケットが含まれます。ソルトバケットは持続し、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 を確認するには、マッピング関数を呼び出す そして返された UID2 とバケット ID を再び保存してください。

備考

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

How often should UID2s be refreshed for incremental updates?​

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

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

How should I generate the SHA-256 of DII for mapping?​

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

Should I store large volumes of email address, phone number, or their hash mappings?​

はい。何百万ものメールアドレスや電話番号をマッピングする必要がある場合、マッピングを保存しないことで処理時間が大幅に増加する可能性があります。しかし、実際に更新が必要なマッピングだけを再計算すると、毎日更新する必要があるのは 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 エンドポイントを通じて、ユーザーがオプトアウトしたかどうかを定期的に確認することを勧めます。

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

Does the same DII always result in the same 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 を参照してください。

FAQs for DSPs​

demand-side platform (DSP) に関するよくある質問を紹介します。

How do I know which decryption key to apply to a 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?​

UID2 Service は、入札プロセスに遅延を生じさせることはありません。発生した遅延は、UID2 Service ではなく、ネットワークに起因すると考えられます

How should the DSP maintain proper frequency capping with UID2?​

UID2 は、クッキーと同じように古くなる可能性があります。したがって、DSP は、クッキーまたは Device ID ベースのフリークエンシーキャッピングに現在使用されているものと同じインフラを UID2 に適応させることができます。詳細は、How do I know when to refresh the UID2 due to salt bucket rotation? を参照してください。

Will all user opt-out traffic be sent to the DSP?​

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

Is the DSP expected to handle opt-out signals only for the UID2s that they already store?​

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

How long should the DSP keep the opt-out list?​

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

Is the UID2 of an opted-out user sent to the opt-out endpoint in an encrypted form?​

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

In what format is the UID2 of an opted-out user sent to the webhook?​

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

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

What request type do opt-outs use?​

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

How strict are the requirements for honoring opt-outs?​

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

How do SDK errors impact the DSP's ability to respond to a bid?​

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