Google 的“额外同意模式”技术规范

额外同意模式 v2 中的变更

自 2023 年 12 月以来，Google 便一直支持 v2 版“额外同意模式”规范。主要变更如下：

更新了额外同意模式 (AC) 字符串，以支持 CMP 中披露的供应商。
更新了 CMP API，让同时支持 TCF 和广告客户意见征求模式的 CMP 能够协同合作。

根据 v1 版规范生成的 AC 字符串将仍受支持。

额外同意模式的组成部分

在“额外同意模式”中，我们支持以下两种字符串：

IAB TCF v2.2 规范定义的透明度和用户意见征求字符串（TC 字符串），其中包含针对 IAB 全球供应商列表 (GVL) 中的供应商确立的透明度和用户意见征求框架。以及
轻量级的 addtl_consent 字符串（AC 字符串），其中包含未向 IAB 注册但已征得用户同意和/或已披露的 Google 广告技术提供商 (ATP) 的列表。

本规范定义了以下各项：

AC 字符串格式。
扩展 TCF v2.2 CMP API 以支持 AC 字符串以及 TCF 和广告客户意见征求模式并存时的控件。
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 表示用户已同意使用 ID 为 1、35、41 和 101 的 ATP，ID 为 9、21 和 81 的 ATP 则已向用户披露，并且此字符串是使用 v2 规范中定义的格式创建的。

AC 字符串应该由谁创建？

只有已向 IAB Europe TCF 注册的 CMP 才能使用为其分配的 CMP ID 编号根据 IAB 政策创建 AC 字符串。供应商或任何其他第三方服务提供商不得自行创建 AC 字符串。

Google ATP 将在何处发布？

Google 会在下列位置发布未向 IAB 注册的广告技术提供商列表及其 ID：

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

何时应该创建 AC 字符串？

无论何时，都只能在发布商遵循 Google 的欧盟地区用户意见征求政策的前提下创建 AC 字符串。

只有针对以下事项征得用户的具有法律效力的同意时，才能纳入已征得用户同意的供应商：

使用 Cookie 或其他本地存储方式（如果法律要求）；以及
ATP 出于投放个性化广告的目的以及按照 Google 的欧盟地区用户意见征求政策的所有其他条款收集、分享和使用个人数据。

已披露但未针对以下事项征得用户同意的供应商，则只有在适当向用户公开每个 ATP 的身份后（包括链接到 Google ATP 列表中提供的 ATP 隐私权政策）才能纳入：

使用 Cookie 或其他本地存储方式（如果法律要求）；以及
出于投放个性化广告的目的收集、分享和使用个人数据。

只可创建 AC 字符串作为 TC 字符串的补充，而不得使用 AC 字符串替代 TC 字符串。如果 Google 收到的请求中没有可用的 TC 字符串，Google 便不会处理相应请求，并会舍弃其中的 AC 字符串。

那些实施该规范的 CMP 必须确保其创建的 AC 字符串中仅包含已发布的 Google ATP 文件中的 ID（即非 GVL 供应商）。在收到 TC 字符串后，Google 会检查此 TC 字符串中所列的 GVL 版本。如果此 GVL 版本包含某供应商的注册信息，系统会忽略此供应商的 TC 字符串控件，以及此供应商的所有 AC 字符串条目。在这种情况下，Google 有权从 AC 字符串中移除此类“重复”条目，并随 TC 字符串传递此类经过修改的 AC 字符串。Google 之外的供应商不得修改 AC 字符串。

扩展 CMP API

我们建议扩展现有 TCF v2.2 CMP JavaScript API，以便允许返回 AC 字符串。具体而言，我们建议扩展 TCData 和 InAppTCData JSON 对象，以便返回此类数据。

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 字符串？

Web

存储机制由 CMP 自行选择。

应用内

CMP SDK 将使用 NSUserDefaults (iOS) 或 SharedPreferences (Android) 来存储 AC 字符串。此机制的作用如下：

让供应商能够轻松地访问 AC 字符串
让 AC 字符串可在不同的应用会话中留存
让 AC 字符串可在不同 CMP 之间移植，以便发布商能够灵活地使用某一 CMP SDK 替换另一 CMP SDK

如果发布商选择从应用中移除 CMP SDK，则应负责为用户清除 AddtlConsent 值，以免供应商继续使用所包含的 AC 字符串。

NSUserDefaults 和 SharedPreferences 中用于存储和查找的键	值
`IABTCF_AddtlConsent`	字符串：包含规范版本和已征得用户同意的广告技术提供商 ID 的 AC 字符串

如何通过数字广告链传递 AC 字符串

出价请求

我们会复用 ConsentedProvidersSettings 来将非 GVL 供应商信息传播到下游。

在 OpenRTB 扩展 proto 中
旧 Protobuf 版本

message ConsentedProvidersSettings { // 与符合下述条件的提供商对应的一组 ID：相应发布商告知 // Google，他们已针对以下事项征得 EEA 境内用户的具有法律效力的同意：1) 使用 Cookie 或其他本地 // 存储方式（如果法律要求）；以及 2) ATP 出于投放个性化广告的目的 // 按照 Google 的欧盟地区用户意见征求政策收集、分享和使用个人数据。 // 提供商 ID 与提供商名称的映射关系会在 providers.csv 中发布。 repeated int64 consented_providers = 2 [packed = true]; }

// 与符合下述条件的提供商有关的信息：发布商告知 Google， // 他们在 EEA 境内的用户已同意他们 // 出于投放个性化广告的目的按照 Google 的欧盟地区用户意见征求政策使用用户的个人数据。 // 只有当 regs_gdpr 为 true 时，系统才会填充此字段。 optional ConsentedProvidersSettings consented_providers_settings = 42;

基于网址的服务

在某个广告素材呈现后，此广告素材的 <img> 标记中可能会包含一些像素。例如 <img src="http://vendor-a.com/key1=val1&key2=val2">，它会将来自浏览器的 HTTP GET 请求发送到供应商的网域。

由于该像素位于 <img> 标记中，无法执行 JavaScript，所以无法使用 CMP API 来获取 TC 字符串。类似于对 TC 字符串的支持，我们会在应该插入 AC 字符串的像素网址中提供一个标准网址参数和一个宏。

网址参数	对应的宏	网址中的表示法
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

示例 1

若要让供应商 A 能够收到 AC 字符串，图片网址必须包含具有网址参数和宏 &addtl_consent=${ADDTL_CONSENT} 的键值对。得到的网址为：

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

示例 2

在给定的请求中，如果 AC 字符串为：1~1.35.41.101

广告素材的调用方或呈现程序会使用实际 AC 字符串来替换网址中的宏，以便在调用特定服务器时按以下方式修改最初放置的包含此宏的像素：

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

该内容对您有帮助吗？

您有什么改进建议？