GDPR の概要とガイダンス

Google の追加同意の技術仕様

TCF 未登録の広告技術プロバイダ（ATP）を利用されるパブリッシャー様は、当該プロバイダの CMP と直接連携していただく必要があります。

このドキュメントでは、「追加同意」と呼ばれる技術仕様について説明します。追加同意は、IAB ヨーロッパの透明性と同意に関するフレームワーク（TCF）v2 への対応のみにおいて、IAB ヨーロッパのグローバル ベンダー リスト（GVL）に未登録のベンダーに透明性や同意のシグナルを送信できるようにすることを目的とします。この仕様により、パブリッシャー様、同意管理プラットフォーム（CMP）、およびパートナーは、自らの TCF 対応の取り組みに沿って、IAB ヨーロッパの GVL には未登録でも Google の広告技術プロバイダ（ATP）リストには登録されている企業のために追加の同意を取得し反映できます。

追加同意 v2 の変更点

追加同意の v2 の仕様は、2023 年 12 月よりサポートされています。主な変更点は次のとおりです。

  • CMP で開示されるベンダーをサポートするための追加同意（AC）文字列の更新。
  • TCF と広告主の同意モードの両方をサポートする CMP の相互運用性を確保するための CMP API の更新。
v1 の仕様に基づいて生成された AC 文字列も引き続きサポートされます。

追加同意の構成要素

「追加同意」では、次の両方がサポートされます。

  • IAB TCF v2.2 の仕様で定義される透明性と同意の文字列（TC 文字列）。これには、IAB のグローバル ベンダー リスト（GVL）に登録されているベンダー向けに定められた透明性と同意が含まれます。
  • シンプルな addtl_consent 文字列（AC 文字列）。これには、IAB には未登録であり、同意または開示された（あるいはその両方）Google の広告技術プロバイダ（ATP）のリストが含まれます。

この仕様で定義されている内容は次のとおりです。

  1. AC 文字列の形式。

  2. TCF と広告主の同意モードの両方が設定されている場合に、AC 文字列とその制御をサポートするための TCF v2.2 CMP API の拡張。

  3. AC 文字列が保存される仕組み。

  4. デジタル広告チェーンを介して AC 文字列を渡す方法。

「追加同意」（AC）文字列の形式

AC 文字列に含まれる情報

AC 文字列には次の要素が含まれます。

  • 第 1 要素: 仕様のバージョン番号（「2」など）

  • 第 2 要素: 区切り記号（「~」）

  • 第 3 要素: ユーザーが同意している Google の広告技術プロバイダ（ATP）の ID で構成される、ドット区切りのリスト（「1.35.41.101」など）

  • 第 4 要素: 区切り記号（「~」）

  • 第 5 要素: 「dv.」に続く、開示された Google 広告技術プロバイダ（ATP）の ID で構成される、ドット区切りのリスト（「dv.9.21.81」など）

    文字列を短くするために、第 3 要素に含まれるベンダーを第 5 要素に含めないでください。

AC 文字列の例

AC 文字列が「2~1.35.41.101~dv.9.21.81」の場合、ユーザーは 1、35、41、101 の ID を持つ ATP に対して同意しており、9、21、81 の ID を持つ ATP がユーザーに開示され、文字列は v2 の仕様で定義される形式で作成されていることを示します。

AC 文字列の作成者

AC 文字列を作成できるのは、IAB ヨーロッパの TCF に登録されている CMP のみで、割り当てられた CMP ID 番号を使用して、IAB のポリシーに沿って作成します。ベンダーやその他の第三者サービス プロバイダが独自に AC 文字列を作成することはできません。

Google ATP の公開場所

IAB に未登録の広告技術プロバイダとその ID のリストは、次の場所で公開されます。

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

AC 文字列が作成されるタイミング

いかなる場合も、AC 文字列を作成できるのは、パブリッシャー様が Google の EU ユーザーの同意ポリシーに準拠している場合に限られます。

同意済みのベンダーを含めることができるのは、以下についてユーザーから法的に有効な同意が得られている場合に限ります。

  1. Cookie またはその他のローカル ストレージの使用（法律で義務付けられている場合）

  2. ATP による広告のパーソナライズを目的とする個人データの収集、共有、使用、ならびに Google の「EU ユーザーの同意ポリシー」のその他のすべての条項への準拠

以下について同意が得られていない開示されたベンダーは、各 ATP の ID について、適切な透明性がユーザーに提供されている場合にのみ含めることができます。これには、Google の ATP リストで提供されている ATP のプライバシー ポリシーへのリンクも含まれます。

  1. Cookie またはその他のローカル ストレージの使用（法律で義務付けられている場合）

  2. 広告のパーソナライズを目的とする、個人データの収集、共有、利用

AC 文字列は、TC 文字列を補足する文字列としてのみ作成できます。TC 文字列の代用とすることはできません。Google では、受け取ったリクエストで TC 文字列が使用できない場合、そのリクエストは処理されず、リクエストの AC 文字列は破棄されます。

CMP がこの仕様を実装する際は、作成する AC 文字列に、公開済みの Google ATP ファイルにある（つまり GVL 未登録のベンダーの）ID のみを含める必要があります。Google は TC 文字列を受け取ると、TC 文字列に含まれる GVL のバージョンを確認します。GVL のそのバージョンにベンダーが登録されていれば、そのベンダーは TC 文字列の制御対象となり、ベンダーの AC 文字列のエントリは無視されます。Google は、AC 文字列のこうした「重複」エントリを削除し、変更済みの AC 文字列を TC 文字列と一緒に渡す権限を有します。Google 以外のベンダーは AC 文字列を変更できません。

関連リソース

CMP API の拡張

既存の TCF v2.2 CMP JavaScript API を拡張して、AC 文字列を返せるようにすることをおすすめします。具体的には、JSON オブジェクトの TCData と InAppTCData を拡張して、次のデータを返せるようにします。

TCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

 

InAppTCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’
}

AC 文字列が保存される仕組み

ウェブ

保存のメカニズムは CMP によって選択されます。

アプリ内

CMP SDK では NSUserDefaults（iOS）または SharedPreferences（Android）を使用して AC 文字列を保存します。これにより、次のことが可能になります。

  • ベンダーが AC 文字列に簡単にアクセスする

  • アプリのセッション間で AC 文字列を持続させる

  • CMP 間で AC 文字列の可搬性を実現する。これにより、パブリッシャー様は CMP SDK を柔軟に置き換えられるようになります

アプリから CMP SDK を削除する場合、作成された AC 文字列をベンダーが引き続き使用することがないように、パブリッシャー様は責任を持ってユーザーの AddtlConsent の値を消去する必要があります。

NSUserDefaults と SharedPreferences のストレージとルックアップ キー 値
IABTCF_AddtlConsent

文字列: 仕様のバージョンと同意済みの広告技術プロバイダ ID を含んだ AC 文字列

デジタル広告チェーンを介して AC 文字列を渡す方法

入札リクエスト

Google では、ConsentedProvidersSettings を再使用して、GVL 未登録のベンダーをダウンストリームに反映させます。

  • OpenRTB 拡張プロトコル
  • 以前のプロトコル バッファのバージョン

message ConsentedProvidersSettings {
 // プロバイダの ID セット。このプロバイダは、
 // パブリッシャー様が Google に通知した、ATP が Google の EU ユーザーの同意ポリシーに沿って、 
 // 1）法的に必要な場合に Cookie などのローカル ストレージを使用すること、および 
 // 2）広告のパーソナライズを目的として個人データを収集、共有、使用することについて、EEA ユーザーが法的に有効な同意を与えているプロバイダになります。
 // プロバイダ ID とプロバイダ名の対応付けは providers.csv で公開されています。
 repeated int64 consented_providers = 2 [packed = true];
}

 // プロバイダに関する情報。このプロバイダは、パブリッシャー様が Google に通知した、
 // Google の EU ユーザーの同意ポリシーに沿って広告のパーソナライズを目的として
 // 個人データを使用することについて、EEA ユーザーが同意しているプロバイダになります。
 // このフィールドは、regs_gdpr が true の場合にのみ入力されます。
 optional ConsentedProvidersSettings consented_providers_settings = 42;

URL ベースのサービス

クリエイティブのレンダリング時、<img> タグ下のピクセルが多数含まれることがあります。たとえば、<img src="http://vendor-a.com/key1=val1&key2=val2"> となっている場合、ブラウザからベンダーのドメインに HTTP GET リクエストが送信されます。

ピクセルは JavaScript を実行できない <img> タグ下にあるため、CMP API を使用して TC 文字列を取得することはできません。TC 文字列での対応と同様、AC 文字列が挿入されるピクセル URL 内で、標準の URL パラメータとマクロを使用できます。

URL パラメータ 対応するマクロ URL での記述方法
addtl_consent ADDTL_CONSENT &addtl_consent=${ADDTL_CONSENT}

例 1

ベンダー A が AC 文字列を受け取るには、画像 URL に Key-Value ペアとともに、URL パラメータとマクロ（&addtl_consent=${ADDTL_CONSENT}）を含める必要があります。最終的な URL は次のようになります。

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

例 2

リクエストの AC 文字列が「1~1.35.41.101」であると仮定します。

クリエイティブの呼び出し元またはレンダリング元では、URL 内のマクロを実際の AC 文字列で置き換えます。これにより、指定されたサーバーに対して呼び出しを行うと、最初に配置されていた、マクロを含んだピクセルは次のように変更されます。

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

この情報は役に立ちましたか？

改善できる点がありましたらお聞かせください。

さらにサポートが必要な場合

次の手順をお試しください。

ヘルプ コミュニティに投稿する コミュニティ メンバーから回答を得る
お問い合わせ 詳しい情報をお知らせください。解決に向けてサポートいたします
true
リリースノート

アド マネージャーの最新の機能とヘルプセンターの更新情報を紹介しています。

最新情報をご覧ください

検索
検索をクリア
検索を終了
メインメニュー
8850806920825981853
true
ヘルプセンターを検索
true
true
true
true
true
148
false
false