AdMob および AdSense のプログラム ポリシー

Google の追加同意モードの技術仕様

このドキュメントでは、「追加同意モード」という一時的な技術仕様を定義しています。これは、IAB ヨーロッパの透明性と同意に関するフレームワーク(TCF)v2.0 への対応において、IAB ヨーロッパのグローバル ベンダー リスト(GVL)に未登録のベンダーを暫定的に使用できるようにすることを目的としたものです。この仕様により、パブリッシャー様、同意管理プロバイダ(CMP)、およびパートナーは、IAB ヨーロッパの GVL に未登録で、Google の広告技術プロバイダ(ATP)リストに登録されている企業について、TCF v2.0 対応の取り組みに沿って、追加の同意を取得し反映できます。

関連リソース

追加同意モードの構成要素

「追加同意モード」では、次の要素を両方とも使用できます。

  • IAB TCF v2.0 の仕様で定義される透明性と同意の文字列(TC 文字列)。これには、IAB のグローバル ベンダー リスト(GVL)に登録されているベンダー向けに定められた透明性と同意が含まれます。および、
  • シンプルな addtl_consent 文字列(AC 文字列)。これには、IAB に登録されていない同意済みの Google の広告技術プロバイダのリストが含まれます。

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

  1. AC 文字列の形式
  2. AC 文字列に対応するための TCF v2.0 CMP API の拡張
  3. AC 文字列が保存される仕組み
  4. デジタル広告チェーンを介して AC 文字列を渡す方法

「追加同意」(AC)文字列の形式

AC 文字列に含まれる情報

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

  • 第 1 要素: 仕様のバージョン番号(「1」など)
  • 第 2 要素: 区切り記号(「~」)
  • 第 3 要素: ユーザーが同意している Google の広告技術プロバイダ(ATP)の ID で構成される、ドット区切りのリスト(「1.35.41.101」など)

たとえば、AC 文字列が「1~1.35.41.101」の場合、ユーザーは 13541101 の ID を持つ ATP に対して同意していて、文字列は v1.0 の仕様で定義される形式で作成されていることを示します。

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 ユーザーの同意ポリシーを遵守している場合に限られます。特に、ATP が Google の EU ユーザーの同意ポリシーに沿って、1)法的に必要な場合に Cookie などのローカル ストレージを使用すること、および 2)広告のパーソナライズを目的として個人データを収集、共有、使用することについて、ユーザーが法的に有効な同意を与える前に、AC 文字列を作成することはできません。

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.0 CMP JavaScript API を拡張して、AC 文字列を返せるようにすることをおすすめします。具体的には、JSON オブジェクトの TCDataInAppTCData を拡張して、このデータを返せるようにします。

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 文字列を持続させる
  • AC 文字列を CMP 間で移植する。これにより、パブリッシャー様は 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 リクエストが送信されます。

<img> タグ内のピクセルは JavaScript を実行できないため、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

この情報は役に立ちましたか?
改善できる点がありましたらお聞かせください。

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

問題を迅速に解決できるよう、ログインして追加のサポート オプションをご利用ください。