この記事の内容
- 追加同意の構成要素
- 「追加同意」（AC）文字列の形式
- 追加同意をサポートしている CMP
- CMP API の拡張
- AC 文字列が保存される仕組み
- デジタル広告チェーンを介して AC 文字列を渡す方法
- 関連リソース
このドキュメントでは、「追加同意」と呼ばれる技術仕様について説明します。追加同意は、IAB ヨーロッパの透明性と同意に関するフレームワーク（TCF）v2 との併用でのみ使用され、IAB ヨーロッパのグローバル ベンダー リスト（GVL）に未登録のベンダーに対し、透明性や同意のシグナルを送信できるようにすることを目的としています。この仕様により、パブリッシャー様、同意管理プラットフォーム（CMP）およびパートナーは、自らの TCF 対応の取り組みに沿って、IAB ヨーロッパの GVL には未登録ながら Google の広告技術プロバイダ（ATP）リストには登録されている企業のために、追加の同意を取得、反映できます。
追加同意の構成要素
追加同意は、シンプルな addtl_consent 文字列（AC 文字列）で構成されます。これには、IAB の GVL には未登録であり、同意または開示された Google の ATP のリストが含まれます。
「追加同意」バージョン 2（ACv2）文字列を生成する方法
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 文字列の例
1、2、3、4、10 の ID を持つ ATP ベンダーがユーザーに開示されていると仮定します。
- ユーザーがこれらのベンダーを開示する CMP メッセージを確認したが、同意するかどうかをまだ決定していない場合、対応する ACv2 文字列は
2~~dv.1.2.3.4.10になります。 -
ユーザーがすべてのベンダーについて同意した場合、対応する ACv2 文字列は
2~1.2.3.4.10~dv.になります。この場合のみ、dv の後の「.」は省略可能です。したがって、2~1.2.3.4.10~dvも有効な ACv2 文字列です。 - ユーザーがすべてのベンダーについて同意を拒否した場合、対応する ACv2 文字列では、すべてのベンダーが開示されているが、同意は得られていないことを示す必要があります。対応する ACv2 文字列は
2~~dv.1.2.3.4.10になります。 - ベンダー
1と10についてはユーザーが同意し、他のすべてのベンダーについては同意を拒否した場合、対応する ACv2 文字列は2~1.10~dv.2.3.4になります。
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 文字列を変更することができません。
追加同意 v1 文字列のサポートについて
追加同意 v2 は、2023 年 12 月より追加同意の標準バージョンとなっています。v1 の仕様に基づいて生成された追加の同意文字列も引き続きサポートされます。ただし、そうした文字列では、ATP で透明性が確立されているかどうかを示すことはできません。同意を必要としないユースケースに対応するには、CMP を v2 仕様に移行する必要があります。
追加同意をサポートしている認定 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 の拡張
追加同意をサポートする CMP は、既存の TCF v2 CMP JavaScript API JSON オブジェクト（TCData と InAppTCData）の一部として追加の同意文字列を返す必要があります。
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
AC 文字列が保存される仕組み
ウェブ
保存のメカニズムは CMP によって選択されます。
アプリ内
TCFv2 のアプリ内 API と同様に、CMP SDK が生成した AC 文字列は NSUserDefaults（iOS）または SharedPreferences（Android）を使用して保存されます。これにより、次のことが可能になります。
-
ベンダーが AC 文字列に簡単にアクセスする
-
アプリのセッション間で AC 文字列を持続させる
-
パブリッシャー様が CMP を変更した場合に AC 文字列を移植する
注: アプリから CMP SDK を削除する場合、作成された AC 文字列をベンダーが引き続き使用することがないように、パブリッシャー様は責任を持ってユーザーの AddtlConsent の値を消去する必要があります。
| NSUserDefaults と SharedPreferences のストレージとルックアップ キー | 値 |
IABTCF_AddtlConsent |
文字列: 仕様のバージョンと同意済みの広告技術プロバイダ ID を含んだ AC 文字列 |
デジタル広告チェーンを介して AC 文字列を渡す方法
入札リクエスト
ConsentedProvidersSettings を使用して、GVL 未登録のベンダーをダウンストリームに反映させます。
- OpenRTB 拡張プロトコル
- 以前のプロトコル バッファのバージョン
message ConsentedProvidersSettings {
// Set of IDs corresponding to providers for whom the publisher has told
// Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local
// storage where legally required; and 2) the collection, sharing, and use of personal data for
// personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.
// A mapping of provider ID to provider name is posted at providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Information about the providers for whom the publisher has told Google
// that its EEA users have consented to the use of their personal data for
// ads personalization in accordance with Google's EU User Consent Policy.
// This field will only be populated when regs_gdpr is 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 文字列が「2~1.35.41.101~dv.」と仮定します。
クリエイティブの呼び出し元またはレンダリング元では、URL 内のマクロを実際の AC 文字列で置き換えます。これにより、指定されたサーバーに対して呼び出しを行うと、最初に配置されていた、マクロを含んだピクセルは次のように変更されます。
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.