この記事の内容
- 追加同意の構成要素
- 「追加同意」（AC）文字列の形式
- 追加同意をサポートしている CMP
- CMP API の拡張
- AC 文字列が保存される仕組み
- デジタル広告チェーンを介して AC 文字列を渡す方法
- 関連リソース
このドキュメントでは、「追加同意」と呼ばれる技術仕様について説明します。追加同意は、IAB ヨーロッパの透明性と同意に関するフレームワーク（TCF）v2 との併用でのみ使用され、IAB ヨーロッパのグローバル ベンダー リスト（GVL）に未登録のベンダーに対し、透明性や同意のシグナルを送信できるようにすることを目的としています。この仕様により、パブリッシャー様、同意管理プラットフォーム（CMP）およびパートナーは、自らの TCF 対応の取り組みに沿って、IAB ヨーロッパの GVL には未登録ながら Google の広告技術プロバイダ（ATP）リストには登録されている企業のために、追加の同意を取得、反映できます。
追加同意の構成要素
「追加同意」では、次の両方がサポートされます。
- IAB TCF v2 の仕様で定義される透明性と同意の文字列（TC 文字列）。これには、IAB の GVL に登録されているベンダー向けに定められた透明性と同意が含まれます。および、
- シンプルな
addtl_consent文字列（AC 文字列）。これには、IAB には未登録であり、同意または開示された Google の ATP のリストが含まれます。
この仕様で定義されている内容は次のとおりです。
-
AC 文字列の形式。
-
TCF と広告主の同意モードの両方が設定されている場合に、AC 文字列とその制御をサポートするための TCF v2 CMP API の拡張。
-
AC 文字列が保存される仕組み。
-
デジタル広告チェーンを介して 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 に未登録の ATP とその ID のリストは、次の場所で公開されます。
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
AC 文字列が作成されるタイミング
いかなる場合も、AC 文字列を作成できるのは、パブリッシャー様が Google の EU ユーザーの同意ポリシーに準拠している場合に限られます。
同意済みのベンダーを含めることができるのは、以下についてユーザーから法的に有効な同意が得られている場合に限ります。
-
Cookie またはその他のローカル ストレージの使用（法律で義務付けられている場合）
-
ATP による広告のパーソナライズを目的とする個人データの収集、共有、使用、ならびに Google の「EU ユーザーの同意ポリシー」のその他のすべての条項への準拠
開示されたベンダーは、各 ATP の ID について適切な透明性がユーザーに提供されている場合にのみ含めることができます。これには、Google の ATP リストで提供されている ATP のプライバシー ポリシーへのリンクも含まれます。同意済みのベンダーのリストに含まれるベンダーを、開示されたベンダーのリストに含める必要はありません。
AC 文字列は、TC 文字列を補足する文字列としてのみ作成できます。TC 文字列の代用とすることはできません。Google は、受け取ったリクエストで TC 文字列を使用できない場合にそのリクエストを処理せず、リクエストの AC 文字列を破棄します。
CMP がこの仕様を実装する際は、作成する AC 文字列に、公開済みの Google ATP ファイルにある（つまり GVL 未登録のベンダーの）ID のみを含める必要があります。Google は TC 文字列を受け取ると、それに含まれる GVL のバージョンを確認します。その GVL のバージョンにベンダーが登録されていれば、当該ベンダーは TC 文字列の制御対象となり、AC 文字列のエントリは無視されます。Google は、AC 文字列のこうした「重複」エントリを削除し、変更済みの AC 文字列を TC 文字列と一緒に渡す権限を有します。Google 以外のベンダーは、AC 文字列を変更することができません。
追加同意 v2 の変更点
追加同意の v2 の仕様は、2023 年 12 月よりサポートされています。主な変更点は次のとおりです。
- CMP で開示されるベンダーをサポートするための追加同意（AC）文字列の更新。
- TCF と広告主の同意モードの両方をサポートする CMP の相互運用性を確保するための CMP API の更新。
追加同意をサポートしている認定 CMP
このリストには、Google の追加同意の技術仕様をサポートしている認定 CMP と、認定 CMP がサポートしている追加同意のバージョンが記載されています。
追加同意をサポートする CMP を提供しているが、（1）該当の CMP がこのリストに含まれていない場合、または（2）記載されている追加同意のバージョンが間違っている場合は、CMP 登録フォームにアクセスして、[I'd like to ask a question or update my status]（質問またはステータスの更新）リクエスト タイプを選択してください。できるだけすみやかにリストを更新し、正しい状態を反映いたします。
このリストの情報に関するガイド
このリストには、各認定 CMP に関する次の情報が含まれています。
- 認定 CMP: 認定 CMP の名前。
- TCF CMP ID: IAB が TCF 承認済みの CMP に割り当てた固有識別子。
- 追加同意: CMP がサポートしている追加同意のバージョン。
追加同意をサポートしている認定 CMP のリスト
CMP API の拡張
既存の TCF v2 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 文字列を持続させる
-
AC 文字列を CMP 間で移植する。これにより、パブリッシャー様は CMP SDK を柔軟に置き換えられるようになります
アプリから CMP SDK を削除する場合、作成された AC 文字列をベンダーが引き続き使用することがないように、パブリッシャー様は責任を持ってユーザーの AddtlConsent の値を消去する必要があります。
| NSUserDefaults と SharedPreferences のストレージとルックアップ キー | 値 |
IABTCF_AddtlConsent |
文字列: 仕様のバージョンと同意済みのATP ID を含む AC 文字列 |
デジタル広告チェーンを介して AC 文字列を渡す方法
入札リクエスト
Google は、ConsentedProvidersSettings を再利用して、GVL 未登録のベンダーをダウンストリームに反映させます。
- OpenRTB 拡張プロトコル
- 以前のプロトコル バッファのバージョン
message ConsentedProvidersSettings {
// プロバイダの ID セット。該当するのは、パブリッシャー様が
// Google に対し、EEA ユーザーが以下の事項について法的に有効な同意を与えていると通知したプロバイダとなります。
// 1）法的に必要な場合に Cookie などのローカル ストレージを使用すること、および
// 2）広告のパーソナライズを目的として、ATP が Google の EU ユーザーの同意ポリシーに沿って、個人データを収集、共有、使用すること。
// プロバイダ 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