什么是 IAB Transparency & Consent Framework (TCF)？
TCF 主要应用于欧洲的数字广告生态系统。它提供了标准化的政策、技术规范、同意信号、供应商信息和 API，帮助参与的组织传达用户在个人数据处理以及设备存储或访问方面所作的选择。
当前的框架版本为 TCF v2.3。该版本于 2025 年推出，将 Disclosed Vendors 分段确立为 TC String 的强制组成部分，以解决特定供应商是否已向用户披露这一问题上的模糊性。TCF v2.3 的过渡截止日期为 2026 年 2 月 28 日。
IAB TCF 是什么意思？
IAB TCF 是 IAB Europe Transparency & Consent Framework 的缩写。
它为数字广告生态系统提供了一套通用框架，其参与者包括：
- 发布商
- 媒体公司
- 广告主
- 广告代理公司
- 同意管理平台
- 广告技术供应商
- 需求方平台（DSP）
- 供应方平台（SSP）
- 广告服务器
- 效果衡量服务提供商
- 其他技术合作伙伴
典型的广告生态系统可能涉及众多供应商。TCF 提供了一种标准化的方式，用以传达关于这些供应商、其所声明的处理目的、适用的合法性基础以及用户选择的信息。
IAB Europe 将 TCF 描述为一项跨行业的自愿性标准，旨在让发布商与技术合作伙伴能够协同工作，同时为用户提供标准化的隐私选择体验。
IAB TCF 是一部法律吗？
不是。
IAB Transparency & Consent Framework 是一套行业框架，而不是立法。
它并不能取代：
- GDPR
- ePrivacy 指令
- UK GDPR
- 各国的隐私法律
- 监管指引
- 法院判决
- 其他适用的数据保护要求
IAB Europe 现行政策明确指出，参与 TCF 并不能替代各参与方自身遵守适用法律的责任。
因此，使用兼容 TCF 的 CMP 并不会自动让网站符合 GDPR 要求。
相反，TCF 提供的是一套标准化机制，可以为特定的隐私与广告工作流程提供支持。
IAB TCF 的目的是什么？
TCF 的首要目的，是在数字广告供应链内部为隐私选择建立一套共通的语言。
设想某家发布商与数十家广告和效果衡量供应商开展合作。
如果没有标准化的框架，该发布商可能需要通过各不相同的技术机制，向每一家供应商传达隐私选择。
TCF 将这一传达过程中的重要环节加以标准化。
简化后的工作流程是：
- 用户
- CMP
- TCF 信号
- 广告供应商
- 处理
这可以帮助参与的组织了解：
- 涉及哪些供应商
- 供应商声明了哪些目的
- 框架内正在使用哪些合法性基础
- 用户作出了什么选择
- 哪些供应商已被披露
- 适用哪些发布商限制
- 用户的隐私状态应当如何被传达
什么是 TCF v2.3？
TCF v2.3 是 IAB Europe Transparency & Consent Framework 的当前版本。
IAB Europe 于 2025 年推出了 TCF v2.3。其关键变化，是把 Disclosed Vendors 部分确立为 TC String 的强制组成部分。
引入这一变化，是为了消除特定供应商是否确实已向用户披露这一问题上的模糊性，尤其是在涉及 Special Purposes 合法利益处理的场景中。
过渡期已于 2026 年 2 月 28 日结束，这意味着当前的 TCF 实现方案应当支持 v2.3，而不应继续沿用较早的 v2.2 实现。
TCF 版本沿革
TCF 的主要版本包括：
- TCF v1.12018
- TCF v2.02019
- TCF v2.12020
- TCF v2.22023
- TCF v2.32025
在当前的术语内容和实施指引中，应当以 TCF v2.3 作为参照版本。
TCF v2.3 有哪些变化？
v2.3 最重要的变化，是强制性的 Disclosed Vendors 分段。
该分段用于传达某一供应商是否已通过 CMP 界面向用户披露。
其技术结构包括：
- 核心分段
- Disclosed Vendors 分段
- 可选的 Publisher TC 分段
IAB Tech Lab 说明，Disclosed Vendors 分段提供了一个二元信号，用以表明某一供应商是否已向用户披露。
当供应商就特定处理活动依赖合法利益，并且需要知悉用户是否已被恰当告知其参与情况时，这一点尤为相关。
为什么这一点很重要
供应商披露是一项重要的透明度要求。
供应商不应当只能靠猜测来判断自己是否确实被呈现给了用户。
TCF v2.3 提供了一个标准化的信号，以减少这种模糊性。
什么是 TC String？
Transparency and Consent String（通常简称 TC String）是 TCF 生态系统内相关信息与用户选择的机器可读表示形式。
它可以传达与以下方面相关的信息：
- 用户同意
- 用户反对
- 供应商
- 目的
- 合法性基础
- 发布商限制
- 已披露的供应商
- 框架元数据
TC String 让参与的供应商能够收到关于通过 CMP 所确立的隐私状态的标准化信息。
因此，TC String 是 TCF 最重要的技术组成部分之一。
TC String 就等于同意吗？
不是。
TC String 是隐私信息与用户选择的技术表示形式。
它本身并不能在法律上替代有效的同意。
同意在法律上是否有效，取决于以下因素：
- 提供了哪些信息
- 该选择是否是自由作出的
- 处理目的是否足够具体
- 在必要情形下用户是否主动表示了同意
- 是否可以撤回同意
- 是否满足了适用的法律要求
- 实际的处理活动是否与所披露的处理活动相符
TCF 提供的是技术上的标准化；它本身并不能为处理活动创设合法性基础。
什么是 Disclosed Vendors 分段？
Disclosed Vendors 分段是 TCF v2.3 中的一项关键新增内容。
它用于传达各供应商是否已通过相应的 CMP 界面向用户披露。
其目的在于，消除供应商在判断自己是否确实被呈现给用户时所面临的模糊性。
这一点对于在特定合法利益场景下处理数据的供应商尤为重要。
TCF v2.3 要求在 TC String 中包含 Disclosed Vendors 分段。
什么是 Global Vendor List（GVL）？
Global Vendor List（GVL，全球供应商名单）是参与 TCF 生态系统的供应商的标准化名单。
它提供的信息，可供 CMP 和其他参与方用来了解参与的供应商及其所声明的活动。
供应商信息可以包括：
- 供应商 ID
- 供应商名称
- 所声明的目的
- 特殊目的
- 功能
- 特殊功能
- 合法性基础
- 数据类别
- 其他框架信息
GVL 之所以重要，是因为 TC String 和 CMP 界面都需要标准化的供应商信息。
IAB Europe 现行的 TCF 资源仍将 GVL 列为该框架的核心组成部分。
它让 CMP 和其他参与方能够基于关于参与供应商的标准化信息开展工作。
GVL 有助于支持：
- 供应商识别
- 目的声明
- 特殊目的声明
- 功能信息
- 合法性基础信息
- 供应商披露
GVL 是让 TCF 标准化供应商信息传达成为可能的核心资源之一。
什么是 TCF CMP？
TCF CMP 是参与 IAB Europe TCF 生态系统的同意管理平台。
TCF CMP 可以提供面向用户的界面和技术基础设施，用以：
- 呈现隐私信息。
- 披露适用的供应商与目的。
- 收集用户选择。
- 生成 TC String。
- 把该信号提供给参与的供应商。
- 支持适用的 CMP API。
- 管理偏好变更。
- 遵循相关的 TCF 政策与规范。
普通的 Cookie 横幅并不会自动成为 TCF CMP。
参与 TCF 涉及特定的注册、政策、技术和合规方面的要求。
TCF 与 CMP 的对比
TCF 与 CMP 彼此相关，但并不是同一回事。
| TCF | CMP |
|---|---|
| 行业框架 | 软件/平台 |
| 定义政策与标准 | 实现隐私选择工作流程 |
| 定义标准化的目的与供应商概念 | 向用户呈现信息 |
| 定义技术信号传递机制 | 生成并传达信号 |
| 定义参与要求 | 提供具体的实现 |
| 由 IAB Europe 管理，并开展技术协作 | 由各家 CMP 公司提供 |
简单来说：
- TCF 是框架。
- CMP 是可以实现该框架的软件。
TCF CMP 做些什么？
TCF CMP 通常负责处理同意流程中的若干阶段。
透明度
CMP 说明相关的目的、供应商和处理活动。
选择
用户可以作出适用的同意或偏好选择。
信号生成
CMP 生成相应的 TC String。
信号可用性
CMP 把相关信号提供给参与的供应商。
偏好管理
用户之后可以修改或撤回适用的选择。
技术执行
网站整体的实现方案应当确保实际的处理活动与由此产生的隐私状态相符。
最后一点至关重要。
生成 TC String 与阻止未经授权的处理并不是一回事。
什么是 TCF Purposes？
TCF 使用标准化的 Purposes（目的）来描述参与的供应商为何处理个人数据或开展相关活动。
现行的 TCF 政策包含以下标准化目的：
- 在设备上存储和/或访问信息
- 使用有限的数据来选择广告
- 为个性化广告创建画像
- 使用画像来选择个性化广告
- 创建画像以实现内容个性化
- 使用画像来选择个性化内容
- 衡量广告效果
- 衡量内容效果
现行的 TCF 政策文档对这些目的及相关的框架概念作出了定义。
目的结构之所以重要，是因为它为 CMP 界面和供应商声明提供了一套标准化的表述。
什么是 Special Purposes？
Special Purposes（特殊目的）是 TCF 中另行定义的一类标准化处理目的。
它们在框架中的处理方式与普通 Purposes 不同，并有其特定的要求。
因此，网站不应当把 TCF 简化成：
“用户接受或拒绝 Cookie。”
TCF 所涵盖的是一个更为广泛的广告与数据处理生态系统，其中涉及目的、供应商、功能、特殊目的和合法性基础。
什么是 TCF Features 与 Special Features？
TCF 还定义了 Features（功能）与 Special Features（特殊功能）。
它们用于描述与供应商处理活动相关的特定能力或特征。
在 TCF 政策下，Special Features 会受到额外的处理要求。
这些区分之所以重要，是因为 TCF CMP 必须按照现行的框架要求来呈现和传达相关信息，而不能把每一项供应商活动都当作普通的 Cookie 来对待。
TCF 中的同意与合法利益
TCF 在历史上支持多种合法性基础概念，其中包括同意与合法利益。
不过，该框架随着时间推移已发生了实质性的变化。
TCF v2.2 取消了将合法利益作为 Purposes 3–6 的合法性基础。
随后，TCF v2.3 引入了强制性的 Disclosed Vendors 分段，以消除在特定合法利益场景下供应商是否已向用户披露的模糊性。
供应商声明采用合法利益，并不意味着它自动获得了不受限制地处理个人数据的许可。
适用的法律以及具体的处理活动仍然十分重要。
TCF 是否意味着用户已经给予同意？
不是。
TCF 是一套用于透明度和隐私选择信号传递的框架。
它本身并不能创设有效的同意。
合规的同意工作流程仍然需要满足适用的法律要求。
例如，当同意作为合法性基础时，组织应当考虑该同意是否：
- 自由作出
- 具体明确
- 知情作出
- 含义明确
- 基于适当的信息
- 可以撤回
实际的用户界面与技术行为，也必须与其所主张的合法性基础相符。
采用 TCF 就能让网站符合 GDPR 吗？
不能。
TCF 可以为隐私与广告合规工作流程中的部分环节提供支持，但它并不是一张 GDPR 合规证书。
IAB Europe 自身的政策明确指出，参与 TCF 并不能替代各参与方自行承担其法律义务的责任。
一套更完整的 GDPR 合规方案可能还需要：
- 隐私告知
- 有效的同意机制
- 合法性基础分析
- Cookie 与追踪器控制
- 数据主体权利
- 数据最小化
- 数据留存
- 供应商管理
- 数据处理协议
- 安全控制措施
- 国际传输保障措施
- 处理活动记录
- 治理与问责
TCF 与 GDPR
TCF 是专门为回应欧洲的隐私环境而创设的，旨在帮助参与的组织在数字广告生态系统中应对特定的 GDPR 与 ePrivacy 要求。
IAB Europe 将 TCF 描述为一项问责工具，旨在促进对 GDPR 和 ePrivacy 指令中特定条款的遵守。
然而：
各组织仍需自行确定其应承担的法律义务。
TCF 与 ePrivacy 指令
TCF 也与 ePrivacy 指令相关，尤其涉及在用户设备上存储或访问信息的各类技术。
这意味着欧洲的广告合规可能涉及多个法律层面：
个人数据处理
设备存储/访问及相关技术
标准化的行业信号传递与问责框架
TCF 并不能取代其中任何一套法律框架。
TCF 会拦截 Cookie 吗？
不会。
TCF 主要是一套用于标准化透明度与信号传递的框架。
它并不会自动阻止每一个 Cookie 或追踪器加载。
网站可能还需要其他执行机制，例如：
- 脚本事前拦截
- 代码管理控制
- Cookie 控制措施
- CMP 集成
- 供应商拦截
- 服务器端控制措施
- 同意状态传递
例如，CMP 可能正确生成了一个表明用户未就某一目的给予同意的 TC String，而某个配置不当的代码仍然触发了。
这就属于实施层面的问题。
TCF 与事前同意
事前同意与 TCF 是相互关联但彼此不同的概念。
事前同意是指在相应的处理活动或设备访问发生之前取得同意。
TCF 提供的，是在隐私选择流程之后或作为其组成部分的标准化信号传递。
简化后的工作流程可能如下：
- 用户访问
- CMP 加载
- 呈现隐私信息
- 用户作出选择
- 确立适用的同意状态
- 获准的技术开始运行
- 传达 TC String
具体的顺序取决于网站的技术架构和适用的法律。
TCF 与程序化广告
TCF 对程序化广告尤为重要。
发布商可能与众多广告和效果衡量供应商合作，包括：
- SSP
- DSP
- 广告交易平台
- 广告服务器
- 效果衡量服务提供商
- 受众平台
- 验证服务提供商
- 数据提供商
TCF 为这些参与方提供了一套标准化机制，用以传达相关的隐私信息。
这正是 TCF 对发布商和媒体企业尤为有价值的主要原因之一。
面向发布商的 TCF
使用程序化广告的发布商可能需要管理：
- 供应商披露
- 目的披露
- 用户同意
- 用户反对
- 发布商限制
- TC String 生成
- CMP 配置
- 供应商集成
- 同意撤回
- 追踪器启用
- 隐私合规
IAB Europe 明确将发布商、CMP 和供应商列为 TCF 的核心参与方。
面向供应商的 TCF
TCF 供应商是指参与该框架的技术提供方。
供应商可能包括：
- 广告平台
- 效果衡量服务提供商
- DSP
- SSP
- 广告服务器
- 受众数据提供商
- 其他广告技术公司
参与的供应商借助 TCF 信号来了解与其所声明处理活动相关的隐私状态。
不过，供应商仍需自行承担各自的合规义务。
什么是 TCF CMP API？
TCF CMP API 是一套标准化的技术接口，让参与的供应商和其他组件能够与 TCF CMP 进行交互。
该 API 支持与以下方面相关的功能：
- CMP 可用性
- 同意信息
- TC String 获取
- 同意更新
- 隐私状态传达
TCF 技术规范与实施指引定义了适用的 API 行为。IAB Europe 现行的配套资源页面将 CMP API 列为 TCF 的核心技术规范之一。
getTCData 后来怎么样了？
TCF 的技术规范一直在演进。
TCF v2.2 的 CMP API 已弃用 getTCData 命令。
因此，维护较早期 TCF 集成的开发者，应当查阅现行的实施指引，而不应假定旧有的 API 写法仍然适用。
在把较早的 TCF v2.2 集成更新到当前的 v2.3 环境时，这一点尤为重要。
什么是 GPP？它与 TCF 有何关系？
Global Privacy Platform（GPP）是由 IAB Tech Lab 制定的一套更为宽泛的隐私信号框架。
TCF 与 GPP 彼此相关，但并不是同一回事。
一种简化的区分方式是：
欧洲的 Transparency & Consent Framework
支持多个法域的更宽泛隐私信号框架
GPP 可以在承载各地区隐私分段的同时，一并承载 TCF 分段。
因此，在国际范围内经营的组织，可以在更宽泛的 GPP 架构中使用 TCF。
TCF 与 GPP 的对比
| TCF | GPP |
|---|---|
| IAB Europe 的框架 | IAB Tech Lab 的框架 |
| 主要面向欧洲的广告生态系统 | 跨多个法域的隐私信号传递 |
| 使用 TC String | 使用 GPP 字符串/分段 |
| 将欧洲的供应商与目的信息标准化 | 支持多个地区性隐私框架 |
| 与 GDPR/ePrivacy 广告工作流程密切相关 | 为更广泛的隐私法规信号传递而设计 |
因此，不应当把 TCF 与 GPP 当作可以互换的术语。
TCF 与 Google Consent Mode 的对比
IAB TCF 与 Google Consent Mode 解决的是不同的问题。
TCF 把 TCF 生态系统内的隐私选择信号传递加以标准化。
Google Consent Mode 则把相关的同意状态传达给受支持的 Google 代码与服务，使其行为可以根据这些状态作出调整。
因此，发布商可以同时使用两者：
- CMP
- TCF / TC String
以及：
- CMP
- Google Consent Mode
因此，这两种技术可以相辅相成，而不是彼此竞争的替代方案。
TCF 与 GPC 的对比
Global Privacy Control（GPC）是一种浏览器层面或隐私工具的信号，用于传达特定的退出偏好。
TCF 则是一套面向广告行业的透明度与同意信号传递框架。
两者服务于不同的目的。
网站可以同时具备以下各项：
- GPC
- TCF
- CMP
- Cookie 同意
- Google Consent Mode
- 分地区的隐私规则
并把它们纳入同一套隐私架构之中。
TCF 与 Cookie 同意的对比
Cookie 同意横幅主要是一个用户界面。
TCF 则是一套标准化的行业框架，用以规范其生态系统内隐私选择的传达方式。
因此，简化后的架构可以是：
- Cookie 横幅
- TCF CMP
- TC String
- 参与的供应商
横幅是用户直接进行交互的部分。
TCF 框架则在生态系统背后提供标准化的政策与技术机制。
IAB TCF 如何运作？
简化后的 TCF 工作流程如下：
识别参与的供应商
发布商识别出相关的 TCF 供应商。
配置 CMP
CMP 采用现行的 TCF 政策、规范和 GVL 信息。
呈现透明度信息
CMP 说明相关的目的、供应商及其他必需信息。
记录用户的选择
用户作出适用的同意或反对选择。
生成 TC String
CMP 把相关信息编码进 TC String 之中。
提供该信号
参与的供应商可以通过适用的技术机制访问该信号。
供应商解读该信号
供应商依据 TCF 框架及其所声明的活动，判定相关的处理状态。
落实由此产生的状态
网站与供应商必须确保实际的处理活动与适用的隐私状态相符。
IAB TCF 实施清单
在上线或更新 TCF 实现方案之前，发布商应当核实：
- CMP 支持当前的 TCF 版本。
- CMP 已按要求完成 TCF 参与注册。
- 正在遵循现行的 TCF 政策。
- 正在使用现行的技术规范。
- 供应商信息已与适用的 GVL 保持同步。
- 已披露正确的 TCF 目的。
- 已披露相关的供应商。
- Disclosed Vendors 分段已正确实现。
- 同意是通过适当的用户操作收集的。
- 适用的合法利益处理得到了正确处置。
- 已在需要时配置发布商限制。
- 生成了正确的 TC String。
- 供应商能够获取相关信号。
- 追踪器不会违背用户的选择而启用。
- 同意撤回功能正常运作。
- 已对各项供应商集成进行测试。
- 已对 CMP API 的行为进行测试。
- 在框架更新之后已对实现方案进行测试。
IAB Europe 持续维护现行的 TCF 配套资源，涵盖政策、技术规范、实施指引、CMP 注册、供应商注册以及 v2.3 相关资源。
常见的 IAB TCF 实施误区
把 TCF 当作 GDPR 合规
TCF 是一套行业框架，而不是法律合规证书。
让网站停留在 TCF v2.2
当前的实现方案应当对照 TCF v2.3 进行审查。
把 TC String 本身当作同意
TC String 表示的是关于隐私选择的技术信息。它本身并不能创设在法律上有效的同意。
在取得同意之前加载追踪器
对于需要事前同意的处理活动，网站仍然需要适当的技术控制措施。
忽视供应商的实际行为
如果供应商继续以违背由此产生状态的方式处理数据，仅仅生成一个正确的 TC String 是不够的。
把合法利益当作不受限制的许可
供应商所声明的合法性基础，并不能免除组织遵守适用法律的义务。
使用过时的 API 代码
较早期的 TCF 集成中可能包含已弃用的 API 方法，例如 getTCData。
未能维护供应商信息
供应商信息与框架要求都可能发生变化。
只测试“全部接受”
一套认真的 TCF 实现方案，还应当测试拒绝、部分选择、撤回、回访用户以及各地区配置等情形。
应当如何测试 TCF？
一次恰当的 TCF 审计，应当同时检查 CMP 界面与实际的技术行为。
用户界面测试
测试：
- 首次通知
- 供应商披露
- 目的披露
- 接受控件
- 拒绝控件
- 偏好中心
- 撤回
- 移动端显示
- 无障碍访问
- 本地化
技术测试
测试：
- TC String 生成
- CMP API
- 供应商信号传递
- Cookie
- JavaScript 执行
- 网络请求
- 广告像素
- 第三方请求
- 同意状态变更
- 撤回
反向测试
还应测试：
- 全部拒绝
- 部分同意
- 针对特定供应商的拒绝
- 针对特定目的的拒绝
- 不作任何交互
- 撤回
- 回访用户
- 不同地区
- 不同浏览器
- 移动设备
IAB TCF 与 ConsentX
在更广泛的隐私架构中，ConsentX 可以充当同意管理与执行层。
对于使用 TCF 的组织而言，理想的工作流程是：
- 用户选择
- CMP
- TCF 信号
- 供应商控制措施
- 实际的处理活动
ConsentX 可以帮助把同意管理与技术执行连接起来，涵盖以下方面：
Cookie 同意
脚本事前拦截
同意记录
审计证据
分地区的隐私规则
Google Consent Mode
Global Privacy Control
供应商与追踪器控制
隐私偏好管理
重要的原则是：
同意信号的传递，必须辅以技术上的执行。
如果网站仍在继续执行相应的处理活动，那么一个表明用户未授予某项许可的 TC String，就不应被视为已经足够。
ConsentX 会取代 IAB TCF 吗？
不会。
IAB TCF 与 ConsentX 扮演的是不同的角色。
TCF 是行业框架，包含政策、规范、技术信号传递机制以及参与要求。
ConsentX 是一个同意管理平台，可以提供管理隐私选择所需的面向用户的界面与技术控制措施。
使用 TCF 的组织，应当评估其 CMP 实现方案是否满足适用的 TCF 参与要求和技术要求。
要点总结
- IAB TCF 是指 IAB Europe Transparency & Consent Framework。
- TCF 是一套自愿性的行业框架，而不是法律。
- 它把数字广告生态系统内隐私选择的传达方式加以标准化。
- TCF v2.3 是当前的框架版本。
- TCF v2.3 在 TC String 中引入了强制性的 Disclosed Vendors 分段。
- TC String 传达关于隐私选择的标准化信息。
- Global Vendor List（GVL）提供关于参与供应商的标准化信息。
- TCF CMP 负责实现适用的同意管理工作流程。
- TCF 对发布商和程序化广告尤为重要。
- TCF 并不会自动让网站符合 GDPR 要求。
- TCF 本身并不会拦截 Cookie 或追踪器。
- TCF 不同于 GPC、GPP、Google Consent Mode，也不同于普通的 Cookie 横幅。
- 当前的实现方案应当对照最新的 TCF 政策与技术规范进行测试。
- 有效的实施既需要正确的信号传递，也需要实际的技术执行。