本文内容
本文档介绍了 Google 的“额外同意模式”技术规范，此规范只能与 IAB Europe 透明度和用户意见征求框架 (TCF) v2 搭配使用，向尚未注册加入 IAB Europe 全球供应商列表 (GVL) 的供应商发送透明度和/或同意情况信号。通过遵循此规范，发布商、意见征求管理平台 (CMP) 和合作伙伴可在实施 TCF 的同时，为那些尚未注册加入 IAB Europe 全球供应商列表但已列入 Google 广告技术提供商 (ATP) 列表的公司征集并传播额外同意情况。
“额外同意模式”的组成部分
“额外同意模式”由一个轻量的 addl_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 字符串示例
如果 ID 为 1、2、3、4 和 10 的 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 字符串应该由谁创建？
只有已向 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 隐私权政策），才能纳入已披露的供应商。已征得用户同意的供应商列表中的供应商无需同时包含在已披露的供应商列表中。
创建的 AC 字符串只能作为 TC 字符串的补充，不能替代 TC 字符串。如果 Google 收到的请求中没有可用的 TC 字符串，Google 便不会处理相应请求，并会舍弃其中的 AC 字符串。
那些实施此规范的 CMP 必须确保其创建的 AC 字符串中仅包含已发布的 Google ATP 文件中的 ID（即非 GVL 供应商）。在收到 TC 字符串后，Google 会检查其中所列的 GVL 版本。如果此 GVL 版本包含某供应商的注册信息，系统会忽略此供应商的 TC 字符串控件，以及此供应商的所有 AC 字符串条目。在这种情况下，Google 有权从 AC 字符串中移除此类“重复”条目，并随 TC 字符串传递经过修改的相应 AC 字符串。Google 之外的供应商不得修改 AC 字符串。
“额外同意模式”v1 字符串是否仍受支持？
自 2023 年 12 月以来，“额外同意模式”v2 一直是标准的“额外同意模式”版本。根据 v1 版规范生成的“额外同意模式”字符串将仍受支持。不过，此类字符串无法指明是否已针对相应 ATP 公开透明地提供相关信息。为了支持不需要征得用户同意的使用情形，CMP 应迁移到 v2 规范。
支持“额外同意模式”的认证 CMP
此名单包含经过认证且支持 Google“额外同意模式”技术规范的意见征求管理平台 (CMP)，以及它们支持的“额外同意模式”版本。
如果您提供的 CMP 支持“额外同意模式”，但 (1) 未包含在此名单中，或 (2) 所列的“额外同意模式”版本有误，请前往 CMP 信息登记表单，然后选择“我想提问或更新状态”请求类型。我们将尽快更新此名单，以及时反映您的平台状态。
针对此名单中相关信息的指南
此名单包含每个经认证的 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 自行选择。
应用内
NSUserDefaults (iOS) 或 SharedPreferences (Android) 用于存储由 CMP SDK 生成的 AC 字符串，类似于 TCFv2 的应用内 API。此机制的作用如下：
-
让供应商能够轻松地访问 AC 字符串
-
让 AC 字符串可在不同的应用会话间留存
-
使 AC 字符串具有可移植性，方便发布商更换 CMP
注意：发布商如果选择从其应用中移除 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 字符串为：2~1.35.41.101~dv.
广告素材的调用方或呈现程序会使用实际 AC 字符串来替换网址中的宏，以便在调用指定服务器时按以下方式修改最初放置的包含此宏的像素：
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.