简短概述

TCF v2.3是v2.2的演进，而非重新架构。TC String格式保持兼容，现有的目的与功能得到保留，面向出版商的大多数UI要求也原样沿用。有意义的变化集中在四个方面：

• 关于CMP应如何呈现供应商信息和保留期限的规则更加明确。
• 对细粒度二层控件提出了新的要求，这正是自2022年比利时DPA裁决以来监管机构一直在提出的诉求。
• 围绕暗黑模式、同等显著性和预先勾选选项的政策执行被进一步收紧。
• 对全球供应商列表（GVL）模式和供应商披露流程进行了调整。

v2.3为何出现

每一个TCF版本都是三方受众之间的博弈：需要持续变现的出版商、需要稳定技术接口的供应商，以及不断发现具体合规缺口的监管机构。v2.3是对以下三股压力的直接回应：

1. 对v2.2下"合法利益"滥用的执法行动。多家欧洲DPA认定，太多供应商在本应仅以同意为依据的目的上主张LI。v2.3收紧了供应商声明的合法依据披露规则，并将其在同意UI中更早地呈现出来。
2. 对暗黑模式的持续投诉。更新后的政策使同等显著性规则更为明确，并封堵了二层中预先勾选开关相关的漏洞。
3. 来自大型CMP和出版商的运营反馈。v2.2引入的若干必要披露在移动端和CTV上难以干净地实现。v2.3精简了必要披露集合，并允许其中更多内容呈现在分层视图中。

TC String兼容性

TC String本身保持向后兼容。一个v2.3的CMP所产生的字符串可被v2.2的供应商读取，而一个v2.3的供应商在过渡期间也可消费v2.2的字符串。字符串核心段中的版本标识符标明CMP所声明遵守的政策版本，而GVL版本指针则独立向前推进。

这在实践中意味着：您无需同时升级所有供应商，也无需在部署v2.3的那一天强制对每一位用户重新获取同意。分阶段推出是被明确支持的。

关键技术变化

1. 供应商披露与保留期限

v2.3要求CMP在分层UI中展示每个供应商声明的数据保留期限，而不仅仅在单独的供应商列表中展示。保留期限一直是GVL的一部分，但v2.2并未强制要求用户在查看目的的同时看到它。v2.3弥补了这一缺口，因为监管机构认为，用户在不了解数据存续时长的情况下无法做出知情选择。

2. 更严格的二层控件

在二层——即"管理偏好"视图——中，v2.3明确规定非必要目的和供应商的开关必须默认关闭。即便用户从未明确点击"接受"，预先勾选的复选框或预先启用的滑块也属于政策违规。此前依赖"软选择加入"模式的CMP需要重新渲染其二层界面。

3. 同等显著性执行

同等显著性规则自v2.1起就已存在，但v2.3对其做出了更少自由解释空间的界定："全部拒绝"控件必须与"全部接受"处于同一层级，具有相同的视觉权重、相同的色彩对比等级和相同的交互距离。把拒绝隐藏在链接、较小的按钮或二级屏幕之后，现在已成为明确的合规失败，而不再是见仁见智的问题。

4. 合法利益信号传递

在v2.3下声明以合法利益作为合法依据的供应商，现在必须同时声明其已评估的目的，并明确其中哪些目的已完成合法利益评估（LIA）。CMP被要求将此声明传递到用户界面，使用户能够在充分知情的前提下表示反对。在实践中，这意味着"反对"流程现在展示的是供应商特定的LIA状态，而不是一个通用开关。

5. GVL模式更新

全球供应商列表模式新增了用于描述保留期限粒度、LIA状态，以及指向每个供应商针对其声明目的的隐私政策对应部分的机器可读链接的字段。缓存GVL的CMP在指向v2.3 GVL之前，必须先更新其模式解析器以理解新字段。

影响UX的政策变化

TCF既是一份技术规范，也是一套政策。v2.3的多项政策变化直接落在同意UI上：

• 不再允许"不接受继续"作为拒绝的等效操作，除非它在视觉上与接受按钮相匹配，并产生与完全拒绝相同的TC String。
• 语言平等——同意告知必须以网站本身可用的每一种语言提供，而不仅仅是用户浏览器的语言。CMP必须支持区域设置覆盖。
• 持久可访问——用户必须能够从网站的每一页访问偏好中心，而不仅限于落地页，并且访问链接的标注方式必须让非专业用户也能识别出其与同意相关。

出版商必须做的事

1. 确认您的CMP供应商对v2.3的支持。询问其通过v2.3认证的构建版本的确切可用日期，以及该版本将上报的版本字符串。
2. 刷新GVL缓存逻辑。如果您自行托管任何GVL镜像，请在v2.3 GVL上线之前更新模式解析器，否则您的CMP将无法验证新的供应商。
3. 重写您的二层UI，使每个开关默认关闭，在视觉上强制执行同等显著性，并在目的旁展示保留期限。
4. 重新进行一次合规审计。最容易拿下的监管胜利就是v2.3现已明确指出的暗黑模式违规。赶在下一次执法审查之前修复它们。
5. 规划重新提示策略。尽管TC String向后兼容，政策仍鼓励出版商在处理范围或披露发生实质性变化时重新获取同意。请判断您的v2.3推出对于您的受众而言是否构成"实质性变化"。

供应商必须做的事

1. 对每一个声明LI的目的完成合法利益评估，并将结果提交至GVL。
2. 使用v2.3模式字段更新您的GVL条目：保留期限粒度、LIA声明，以及隐私政策深层链接。
3. 用IAB Europe提供的v2.3参考字符串验证您的TC String解析器。
4. 与您的CMP合作伙伴协调一个共同的切换日期，以免首个携带v2.3字符串的买方请求落在一个仅支持v2.2的供应商上。

常见的迁移陷阱

• 把v2.3当作UI重新设计的契机。将品牌更新与v2.3推出捆绑在一起很有诱惑力，但这样做会让合规测试变得复杂。先发布一个仅涉及合规的v2.3版本，再在其基础上迭代设计。
• 遗漏保留期限展示要求。团队常常更新了供应商列表视图，却忘记保留期限现在也必须出现在逐项目的的分层视图中。
• 认为TC String本身已经足够。一个由不合规UI产生的合规字符串仍然是不合规的。监管机构已多次对那些字符串看似正常、但横幅却隐藏了拒绝按钮的运营商处以罚款。
• 将CTV和移动端排除在范围之外。v2.3适用于产生TCF信号的每一个表面。只更新网页却忽视CTV或移动应用的出版商，将制造出一个混合型不合规环境。

结语

TCF v2.3并不是与v2.2的颠覆性决裂，但它是对支撑欧洲程序化生态系统的规则的一次有意义的收紧。前进方向是清晰的：更高的透明度、更少的暗黑模式、更细粒度的用户控制，以及对以往蒙混过关的边缘情形更低的容忍度。把v2.3视作一次速效补丁的CMP和出版商，会发现自己很快又被推到监管机构面前。把这次迁移用来清理二层UX、摒弃合法利益的捷径、重建真正的同等显著性同意流程的一方，则将带着真正能在v2.3时代顺利出清的库存走出彼岸——以及一种能够经得住无论v2.4带来什么挑战的同意姿态。