更新时间：2025年8月19号
如果你的网站面向欧洲用户，并接入了Google Ad Manager、广告交易平台、DSP、再营销标签或第三方分析工具，通常会遇到一个现实问题：
用户没有同意之前，哪些Cookie、像素和广告标签可以加载？用户改变选择后，广告技术供应商如何立刻知道？
GDPR规定了个人数据处理应遵守的法律原则，但程序化广告涉及Publisher、CMP、SSP、Ad Exchange、DSP 和数百家第三方供应商。每一方都有自己的数据处理目的和用户 ID，单靠一份隐私政策，很难让所有参与者以一致方式读取和执行用户选择。
TCF（Transparency and Consent Framework，透明度与同意框架）就是为解决这类问题而设计的行业框架。
本文会解释TCF、GDPR 和 CMP的关系，TCF 2.2的主要变化，以及企业实施时真正需要检查的内容。
什么是 TCF？
TCF 是由 IAB Europe 推动的行业框架，用于让网站、CMP 和广告技术供应商以统一方式披露、记录、传递和尊重用户的隐私选择。
它主要解决两件事：
- 让用户知道哪些数据处理目的和第三方供应商可能参与；
- 将用户的同意或反对选择，以标准化信号传递给广告和分析技术供应商。
- 你可以把它理解为程序化广告生态中的一套“隐私选择通信协议”。
例如，用户访问一个新闻网站时，CMP 会展示同意弹窗。用户选择“同意个性化广告”或拒绝某些供应商后，CMP 会生成一段标准化的 TC String（Transparency & Consent String）。页面上的广告技术供应商读取该信号后，决定是否可以为相应目的处理数据。
简化的数据流如下：
- 用户打开网站；
- CMP 展示隐私选择界面；
- 用户同意、拒绝或调整特定目的和供应商；
- CMP 生成或更新 TC String；
- 广告、分析和测量供应商读取该信号；
- 供应商按其适用的目的和法律依据决定是否处理数据。
为什么GDPR之外还需要TCF？
GDPR 是法律，规定了个人数据处理的原则、合法性基础、透明度义务和用户权利。但程序化广告链路中的参与方非常多，实际执行会遇到几个难题。
广告链路参与者太多
一个页面可能同时加载广告服务器、竞价平台、测量工具、再营销像素和内容推荐服务。每家供应商都有不同的用途、Cookie、设备标识符和隐私政策。
如果没有统一的信号格式，Publisher 很难把用户选择准确传递给每一个供应商。
用户选择需要持续生效
用户不仅需要在首次访问时作出选择，也应能在之后修改或撤回同意。
这意味着供应商不能只在页面加载时读取一次状态，而要能在用户更新选择后及时获取最新信号。
不同市场的执法重点可能不同
GDPR 在欧盟层面适用，但各成员国的数据保护机构、法院判例和 ePrivacy 相关要求，可能会影响具体实施判断。
TCF 可以统一广告技术中的信息披露和信号传递方式，但不能消除所有法律差异，更不能替企业完成合法性评估。
GDPR、TCF 和 CMP 的关系
| 概念 | 它解决什么问题 | 企业需要做什么 |
|---|---|---|
| GDPR | 个人数据处理的法律要求 | 确定处理目的、法律依据、数据主体权利和责任分工 |
| TCF | 广告技术生态中传递用户选择的行业框架 | 按框架规则披露目的、供应商和选择，并传递信号 |
| CMP | 展示同意界面、保存用户选择并生成信号的工具 | 配置供应商、语言、地区规则、隐私入口和标签拦截逻辑 |
简单理解：
GDPR 是法律要求；TCF 是行业框架；CMP 是执行同意管理的工具。
但这三个概念不能互相替代。比如，CMP 可以帮助你记录和传递同意状态，但数据删除请求、数据处理协议、跨境传输评估和供应商合同管理，仍需要由企业单独处理。
TCF版本演进
TCF 的主要版本包括：
- TCF v1.x：建立早期的同意信号和供应商沟通机制；
- TCF v2.0：在 2019 年推出，增加更细化的处理目的、供应商和法律依据表达；
- TCF v2.1：进一步调整框架政策和技术要求；
- TCF v2.2：于 2023 年发布，参与方需要在 2023 年 11 月 20 日前完成相关政策和技术更新。
目前，新的 TCF 实施应以 TCF v2.2 为基准。旧版本的实施逻辑，尤其是读取 TC String 的方式，不应直接照搬到新项目中。
TCF2.2 的核心变化
TCF 2.2 的重点不是简单增加一个弹窗，而是提高用户选择的透明度，并要求供应商更及时地尊重选择变化。
个性化广告和内容不再使用“合法利益”作为 TCF 法律依据
在 TCF 2.2 范围内，以下目的不再允许供应商以“合法利益”（Legitimate Interest）作为注册层面的法律依据：
- 创建个性化广告资料；
- 选择个性化广告；
- 创建个性化内容资料；
- 选择个性化内容。
这些目的在 TCF 中应以用户同意作为基础。
但这不代表 TCF 中完全取消了合法利益。对于部分其他目的，供应商仍可能声明使用合法利益。企业不能只看“供应商是否在 GVL 中”，还要查看其具体目的、法律依据和数据处理说明。
CMP需要提供更多用户可理解的信息
TCF2.2 要求 CMP 提升用户界面的透明度，包括：
- 在第一层或适当位置披露请求建立法律依据的供应商总数；
- 使用更易理解的目的说明和示例，而不是只展示法律术语；
- 在供应商详情层展示数据类别、数据保留期限及适用的合法利益说明；
- 尽可能提供与用户语言相匹配的供应商隐私文档链接。
这里的重点是“用户能看懂并能找到信息”，不是把更多文本塞进弹窗。
用户应能方便地修改或撤回同意
用户必须能够再次打开 CMP 设置页面，调整目的或供应商选择。
实践中，通常会在以下位置提供入口：
- 网站页脚的「Privacy Settings」「Cookie Settings」或「管理隐私选择」链接；
- 页面悬浮的隐私图标；
- App 设置页面中的隐私管理入口。
如果你在首次弹窗中提供“一键全部同意”，重新打开设置页后也应提供同等容易的一键撤回方式。
需要特别区分：
- 撤回同意：影响后续依赖该同意的处理；
- 删除个人数据：是 GDPR 数据主体权利的一部分，需要企业建立独立的请求和处理流程。
CMP 的“撤回同意”按钮，本身通常不能替代数据删除申请渠道。
Vendor 需要通过事件监听读取最新选择
TCF 2.2 中，网页端供应商应通过事件监听方式获取 TC String 的变化，而不是继续依赖旧的 getTCData 查询方式。
这样，当用户在页面中修改隐私选择时，供应商可以获取更新后的 TC String，而不是继续按旧状态处理数据。
这只是 TCF API 的示意代码。实际是否加载标签、写入 Cookie 或发送数据，还要根据供应商要求、你的网站架构和当地法规判断。
GVL 用于统一供应商声明
GVL（Global Vendor List，全球供应商列表）记录参与 TCF 的 Vendor 及其声明的信息，例如：
- 供应商 ID；
- 支持的数据处理目的；
- 适用的法律依据；
- 数据类别；
- 数据保留期限；
- 隐私政策和合法利益说明链接。
对 Publisher 来说，GVL 不是“允许名单”。某个 Vendor 出现在 GVL 中，说明它参与 TCF 并提交了相关声明；但你仍应判断该供应商是否确实被部署在你的网站上、是否与业务相关、是否应当出现在用户的选择界面中。
企业如何实施TCF 2.2？
如果你的站点面向欧洲用户，并且有程序化广告、再营销或大量第三方营销标签，可以按以下思路实施。
先盘点页面上实际加载的第三方
不要先安装 CMP，再猜测该配置哪些供应商。
先使用浏览器开发者工具、Tag Manager、Consent Mode 设置和网络请求，整理：
- 广告服务器、SSP、DSP 和 Ad Exchange；
- 再营销和转化测量标签；
- 分析、A/B 测试、热图和客户数据平台；
- 被第三方脚本再次加载的子供应商。
最终形成一份“页面实际加载的供应商清单”。CMP 中配置的 Vendor 应尽量与这份清单一致。
选择支持 TCF 2.2 的 CMP
选择 CMP 时，至少检查以下内容：
| 检查项 | 为什么重要 |
| 支持 TCF v2.2 | 避免继续使用旧 API 或旧政策逻辑 |
| 已纳入 IAB Europe 的 CMP 相关计划或验证范围 | 降低技术兼容性风险，但不等于法律合规认证 |
| 支持按地区展示不同规则 | 欧洲用户与其他地区用户可能需要不同流程 |
| 可配置 Vendor 和处理目的 | 避免展示与网站无关的供应商 |
| 支持同意撤回入口 | 满足用户持续管理选择的需要 |
| 可与 GTM、广告标签和 Consent Mode 集成 | 让用户选择真正影响标签加载和数据发送 |
| 提供审计记录与导出能力 | 便于排查同意状态和供应商配置问题 |
不建议为了节省工具成本而随意自建 CMP。难点不仅是弹窗界面，还包括 TC String、GVL 更新、用户选择变更、跨设备或跨域场景、标签拦截和供应商兼容性。
配置目的、供应商和地区范围
配置时，不要默认勾选 CMP 中的全部 Vendor。
建议按以下逻辑处理：
- 只启用实际使用、且业务确有需要的供应商；
- 检查每个供应商在 GVL 中声明的用途和法律依据；
- 为欧洲经济区、英国、瑞士等目标地区设置相应规则；
- 提供清晰的隐私政策、Cookie 政策和隐私设置入口；
- 确保用户拒绝或撤回后，依赖同意的标签不会继续按原方式处理数据。
验证“拒绝”和“撤回”是否真的生效
CMP 显示成功，不等于实施成功。至少测试以下场景：
| 测试场景 | 应检查的结果 |
| 首次访问且未选择 | 不应提前写入或发送需要同意的标识符和请求 |
| 用户全部拒绝 | 相应广告和再营销标签不应继续按已同意状态运行 |
| 用户只同意部分目的或 Vendor | 只有符合该选择的处理才继续 |
| 用户从同意改为拒绝 | TC String 更新；相关标签和供应商读取到新状态 |
| 用户重新访问网站 | CMP 能正确恢复并执行当前选择 |
| 用户打开隐私设置 | 能够容易查看、修改或撤回选择 |
验证工具可以包括浏览器 Network 面板、Cookie/Application 面板、GTM Preview、CMP 调试工具和供应商请求参数。
常见误区
误区一：有 Cookie Banner 就等于符合 TCF
普通 Cookie Banner 可能只负责展示“接受”或“拒绝”。只有在其支持并正确配置 TCF 时，才会生成和传递符合 TCF 规范的信号。
误区二：Vendor 在 GVL 中，就可以自动加载
GVL 不是自动授权名单。Vendor 是否可以处理数据，仍取决于用户选择、该 Vendor 声明的目的和法律依据，以及你自己的部署与法律评估。
误区三：用户撤回同意后，历史数据会自动删除
撤回通常影响未来处理。若用户提出访问、删除或限制处理请求，企业还需要按 GDPR 的相关要求，通过隐私请求流程和供应商协作处理。
误区四：TCF 能解决所有 GDPR 问题
TCF 主要解决广告技术生态中的透明度、选择和信号传递问题。它不能代替数据处理协议、数据最小化、保留期限管理、跨境传输评估或安全措施。
总结
如果你运营面向欧洲用户的网站，且接入程序化广告、再营销或多个第三方营销技术，TCF 2.2 是一套值得理解的基础框架。
它的核心价值不是“多一个 Cookie 弹窗”，而是让用户选择能够以统一格式传递给广告技术供应商，并在选择改变后被及时尊重。
实施时，优先完成这四件事：
- 盘点实际加载的第三方供应商；
- 选择支持 TCF 2.2 的 CMP；
- 只配置真正需要的目的和 Vendor；
- 用真实浏览器测试拒绝、部分同意和撤回后的标签行为。
最后，TCF 可以降低程序化广告中的合规与技术协作风险，但不能替代 GDPR 合规工作。涉及法律依据、数据主体请求或跨境传输时，建议由隐私和法律团队共同确认。
