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

Frequently asked questions

このドキュメントの UID2 に関するよくある質問は、オーディエンスごとにグループ化され、以下の一般的なカテゴリに分類されています:

パブリッシャー向けの以下の追加の FAQ 情報も利用可能です:

FAQs—general​

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

注記

モバイルパブリッシャーインテグレーションに関する 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-Out 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 インスタンスを持つことにはいくつかの利点がありますが、追加の複雑さとコストがかかります。

最適な選択肢は、自身の状況やニーズによって異なります。決定に役立つ情報は、以下を参照してください:

  1. The UID2 Operator

  2. Private Operator integration overview

FAQs for publishers​

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

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 を生成する場合。
  • 直接または 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 のどちらでも生成できます。詳細は、以下を参照してください:

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:​
  1. 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= です。
  2. SDK の background auto-refresh が Advertising Token のリフレッシュを試み(これには数時間かかることがあります)、リフレッシュの試みが OPTOUT ステータスで失敗するのを観察するまで待ちます。この時点で SDK はファーストパーティクッキーもクリアします。
Without SDK:​

  1. 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= です。

  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 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 が Bidstream でどのように渡されるかを示すコードスニペットの一例です:

{
  "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 を参照してください。

I'm using Prebid with a mobile SDK—what atype value should I use?​

Prebid をモバイル SDK と一緒に使用しています—atype 値は何を使用すればよいですか？

IAB のドキュメントによると、atype (Agent Type) 値は、マッチがどのタイプのユーザーエージェントからのものであるかを示します。IAB はこのプロパティを定義することを推奨しています。

Prebid を SDK for Android または SDK for iOS と一緒に使用している場合、atype 値として 3 を使用します。これは、個人ベースの ID を示します。

詳細は、以下の IAB ドキュメントのセクションを参照してください:

FAQs for advertisers and data providers​

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

How do I know when to refresh a raw UID2?​

raw UID2 をリフレッシュするタイミングはどのように判断すればよいですか？

POST /identity/map エンドポイントは、レスポンス内のリフレッシュタイムスタンプ（rフィールド）を提供します。このタイムスタンプ以降に、各 raw UID2 がリフレッシュされる可能性があります。このタイムスタンプを使用して、保存されたデータの raw UID2 を再生成するタイミングを判断します。

raw UID2 をリフレッシュするかどうかを決定するには：

  1. POST /identity/map のレスポンスから保存したリフレッシュタイムスタンプと現在の時刻を比較します。
  2. 現在の時刻がリフレッシュタイムスタンプ以降であれば、同じ DII を使用して再度 Identity Map エンドポイントを呼び出すことで、raw UID2 を再生成します。
注記

raw UID2 は、リフレッシュタイムスタンプの前では変化しません。リフレッシュタイムスタンプの後、DII を再マッピングすると新しいリフレッシュタイムスタンプが返されますが、raw UID2 は変化する場合もあれば変化しない場合もあります。raw UID2 が複数のリフレッシュ間隔にわたって変化しない可能性もあります。

How often should raw UID2s be refreshed for incremental updates?​

インクリメンタルアップデートの場合、UID2 はどのくらいの頻度でリフレッシュするべきですか？

インクリメンタルアップデートの場合、オーディエンスの更新は毎日行うことを推奨します。

特定のユーザーの raw UID2 は、およそ年に 1 回変化します。POST /identity/map エンドポイントの最新バージョンでは、各 raw UID2 がリフレッシュされる可能性のある時点を示すリフレッシュタイムスタンプが提供されます。オーディエンスターゲティングのために raw UID2 を最新かつ有効な状態に保つために、これらのタイムスタンプを毎日確認することを推奨します。

このエンドポイントの以前のバージョン (POST /v2/identity/map) を参照する実装の場合:

各 ソルトバケット はおよそ年に 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 なので、総処理時間が短縮されます。

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 raw UID2s be refreshed for incremental updates?) を参照)。あるリクエストと別のリクエストの間でソルト値が変化する場合、DII が同じであっても、これら 2 つのリクエストは 2 つの異なる raw UID2 になります。

詳細は、Advertiser/data provider integration guideの Monitor for raw UID2 refresh を参照してください。

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 UID2 が含まれます。ただし、トークン自体は常に一意です。

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

ソルトバケットのローテーションによって UID2 をリフレッシュするタイミングを知るには？

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

注記

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

Do refreshed emails get assigned to the same bucket that they were previously associated with?​

更新されたメールアドレスは、以前関連付けられていたバケットと同じバケットに割り当てられますか？

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

備考

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

FAQs for DSPs​

demand-side platform (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 when to refresh mapped raw UID2s?​

マップされた raw UID2 を更新するタイミングを知るには？

Advertisers and data providers の FAQ の raw UID2 をリフレッシュするタイミングはどのように判断すればよいですか？ を参照してください。

How do I know if/when the raw UID2 has rotated?​

raw UID2 がローテーションしたか、またローテーション時期を確認するには？

DSP は、raw UID2 がローテーションしたかどうかを知ることはできません。これは、ユーザーがクッキーをクリアした場合に DSP がそのことを知らないのと同様です。raw UID2 のローテーションは、DSP にとって大きな影響はありません。

Should the DSP be concerned with latency?​

DSP はレイテンシーを気にすべきでしょうか？

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

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

UID2 で DSP はどのように適切なフリークエンシーキャッピングを維持すべきでしょうか？

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?​

ユーザーのオプトアウトトラフィックはすべて 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 についてのみオプトアウトシグナルを処理することを期待されているのか？

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

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

DSP はオプトアウトリストをどれくらいの期間保管すべきですか？

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

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

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

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

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

オプトアウトされたユーザーの UID2 は、どのような形式で 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 can I check if a user has opted out?​

ユーザーがオプトアウトしたかどうかを確認するにはどうすればよいですか？

DSP は、POST /optout/status エンドポイントを使用して、raw UID2 に対するオプトアウトステータスを確認できます。

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

SDK のエラーは DSP の入札対応能力にどのような影響を与えますか？

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