在 TCF 中,TC 字符串用于封装有关如何建立和编码透明度和同意的相关详细信息,因为它适用于策略定义的每个目的、特殊用途、功能和特殊功能以及参与供应商。本文档指定必须如何设置该字符串的格式、谁应使用它以及如何使用它。
有关与 TCF政策和本文档中描述的技术相关的具体定义,请参阅以下链接中的 IAB 欧洲透明度和用户意见征求框架政策:
IAB Europe Transparency & Consent Framework Policies - IAB Europe
TC 字符串的主要目的是封装和编码向用户披露的所有信息,以及他们根据 GDPR 表达对个人数据处理的偏好。使用同意管理平台 (CMP),将信息捕获到编码且紧凑的 HTTP 可传输字符串中。此字符串允许将透明度和同意信息传达给处理用户个人数据的实体或“供应商”。供应商解码 TC 字符串以确定他们是否有必要的法律依据来处理用户的个人数据以达到其目的。简洁的字符串数据格式使 CMP 能够在需要时保留和检索用户的首选项,并将该信息传输给需要它的任何供应商。
TC 字符串包含以下信息:
透明度和用户意见征求字符串只能由 IAB Europe TCF 注册的 CMP 根据政策使用其分配的 CMP ID 号创建。供应商或任何其他第三方服务提供商不得创建或更改 TC 字符串。这些和其他要求在政策中阐明,包括 CMP、发布者和供应商在内的所有各方都必须遵守这些要求。
在用户采取明确的肯定操作以明确表示该用户的同意之前,不得创建包含肯定同意信号的 TC 字符串。但是,如果已根据政策建立了合法利益透明度,则可以仅使用合法利益建立信号创建TC字符串。
CMP 必须在特定于服务或特定于组的配置中运行。此上下文中的 TC 字符串仅适用于服务或一组服务,例如运行它的站点或应用程序。为给定网站/应用或网站/应用组上的每个用户创建一个。它们可能包含发布者限制和发布者 TC段(当由 CMP API 返回时)。
TCF 策略以前允许在框架中建立具有全局范围的法律基础,这意味着法律基础不仅适用于获取和管理它的服务或服务组(特定于服务和特定于组的范围),而且适用于所有实现全局范围首选项的服务。在全局范围的上下文中,TC 字符串存储在与“consensu.org”域关联的第三方 cookie 中,该 cookie 使同意管理提供商 (CMP) 能够跨不同服务从其子域 [cmp-name].mgr.consensu.org 读取“TC 字符串”。已于 2021 年 6 月 22 日宣布弃用全局范围支持。除了弃用全局范围外,还弃用了对带外 (OOB) 的支持,OOB 是指尚未在全局范围上下文中使用 TCF 建立法律依据的情况。自 2021 年 9 月 1 日起,使用全局范围建立的 TC 字符串被视为无效。
该框架的2.0版引入了发布商对供应商如何处理个人数据发出限制的能力。限制可以有两种类型:
发布者限制是由发布者指定的自定义要求。为了使供应商确定是否允许出于特定目的进行处理,或者哪种法律依据适用(如果他们在GVL中表示灵活性),必须遵守限制。
为免生疑问:
如果供应商已声明某个目的的灵活性,并且没有法律依据限制信号,则除了注册为灵活之外,它必须始终应用注册目的的默认法律依据。这意味着,如果供应商将某个目的声明为合法利益,并且还声明该目的具有灵活性,则在没有法律依据限制信号的情况下,不得应用“同意”信号以要求同意。
广告素材呈现后,可能包含多个像素下注。例如,从浏览器向供应商 A 的域触发 HTTP GET 请求。
由于像素位于 antag 中,无法执行 JavaScript,因此 CMP API 不能用于获取 TC 字符串。广告供应链中所有使用 URL 进行交易的各方都必须在其插入 TC 字符串的 URL 中添加宏。任何有权访问适用 TC 字符串的调用方都必须将其插入包含宏的 URL 中,其中接收 TC 字符串的供应商的数字供应商 ID。${GDPR_CONSENT_XXXXX}
XXXXX
例如,对于 ID 为 123 的供应商 A 要接收 TC 字符串,图像 URL 必须包含带有 URL 参数和宏的键值对。gdpr_consent=${GDPR_CONSENT_123}
生成的网址为:
http://vendor-a.com/key1=val1&key2=val2&gdpr_consent=${GDPR_CONSENT_123}
如果 TC 字符串为:COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw
然后,调用方将 URL 中的宏替换为实际的 TC 字符串,以便在调用指定服务器时按如下方式修改最初放置的包含宏的像素。
http://vendor-a.com/key1=val1&key2=val2&gdpr_consent=COvFyGBOvFyGBAbAAAENAPCAAOAAAAAAAAAAAEEUACCKAAA.IFoEUQQgAIQwgIwQABAEAAAAOIAACAIAAAAQAIAgEAACEAAAAAgAQBAAAAAAAGBAAgAAAAAAAFAAECAAAgAAQARAEQAAAAAJAAIAAgAAAYQEAAAQmAgBC3ZAYzUw
TC 字符串必须始终按原样传播,而不是修改。供应链中的其他 URL 与其他供应商的处理方式相同。
以下部分列出了用于在供应链中中继信息的可用 URL 参数和宏。
完整的 TC 字符串传递
使用用户浏览器中的 URL 调用的服务(如 Cookie 订书器、用户 ID 关联器和跟踪像素(“被调用方”))在 URL 中作为宏传递,格式为:
&url_parameter=${macro_name}
支持的 URL 参数和相应的宏定义如下:
网址参数 | 对应宏 | 网址中的表示形式 |
gdpr |
GDPR |
&gdpr=${GDPR} |
gdpr_consent |
GDPR_CONSENT_XXXXX ( |
&gdpr_consent=${GDPR_CONSENT_XXXXX} 例如,供应商 ID 123. |
gdpr_pd |
GDPR_PD |
&gdpr_pd=${GDPR_PD} |
进行调用的服务必须将宏替换为下表中所述的适当值。对于宏,在替换宏之前,进行调用的服务还必须检查宏名称是否包含有效的供应商 ID。URL 的创建者应确保这些参数仅添加一次,并传递给需要它们并且可以正确处理它们的服务。${GDPR_CONSENT_XXXXX}
宏观 | 可能的值 | 目的 |
${GDPR} |
0 / 1 |
0 GDPR 不适用;适用通用数据保护条例。如果 不存在,被叫方应进行地理IP查找,并且GDPR适用于欧盟 IP 地址1 |
${GDPR_CONSENT_XXXXX} |
URL 安全的 base64 编码的透明度和同意字符串。只 有意义的如果gdpr=1 |
对从 CMP JS API 或 OpenRTB 获得的 TC 字符串进行编码。 |
${GDPR_PD} |
0 / 1 (可选,默认值:1 ) |
对于通用 URL 参数,表示没有 它们包含个人数据(从被叫方的角度来看)。为 “定义的”URL参数,其定义应定义是否 它们包括个人数据。gdpr_pd=0 |
注意:其他个人数据,如IP地址或被叫方cookie,可能会作为请求的一部分传递,被叫方使用这些数据来确定是否可以设置和/或使用标识符cookie或其他个人数据。gdpr
gdpr_consent_xxxxx
政策要求在“需要征得同意的情况下”在设备上存储和/或访问信息,目的 1 要求征得用户同意,而出版商和供应商则有责任确定是否需要征得这些管辖区的同意。
如果发布商在不需要同意即可在设备上存储和/或访问信息的管辖区内运营 CMP,因此不代表供应商出于目的 1 征求同意,则 CMP 将在“目的同意”字段中写入相应的位。尽管在该司法管辖区内,不就目的 1 征求同意是有效的,但供应商会将其解释为“不同意”信号,并且无法知道发布商运营所在的司法管辖区不需要同意。缺乏透明度最终会导致该发布商的广告收入损失。0
0
为了适应目的 1 根据司法管辖区的不同而对同意进行不同管理的情况,TC 字符串对于发布者的运营治理以及用途 1 是否向用户披露是透明的。然后,供应商可以使用这些详细信息来确定他们是否有足够的法律依据来处理该给定上下文中的个人数据。为了支持这一点,TC String:PublisherCC中有两个字段,它表示发布者的国家/地区代码和一个标志,用于指示是否已在名为PurposeOneTreatment的用途1上提供任何披露。每个字段的详细信息列在TC 字符串中使用的字段中。
“已创建”和“上次更新时间”字段以前对应于分秒时间戳。考虑 DPA 就数据控制者可用于提供所获得的同意及其有效性的证据的各种手段的实际指导,以及“创建”字段对发布商及其 CMP 的有限相关性,以便酌情至少每 13 个月提供一次, “已创建”和“上次更新”字段已更新为具有与上次更新 TC 字符串时的日级时间戳相同的值。
以下详细信息提供有关创建、存储和管理 TC 字符串的信息。
在 TCF 规范版本 2 中,用于特定于服务和特定于组的 TC 字符串的存储机制最高为 CMP,包括任何非 cookie 存储机制。
IAB 欧洲透明度和用户意见征求框架政策定义了用途、特殊用途、功能、特殊功能和堆栈(目的和/或特殊功能的分组)。您可以在以下 URL 中找到的文档中引用这些用途和功能的详细信息:
IAB Europe Transparency & Consent Framework Policies - IAB Europe
管理冲突的字符串版本
2020 年 9 月 30 日之后,v1.x 字符串被视为无效。如果 CMP 遇到 v1.x 字符串和 v2.0 字符串同时错误存在的情况,CMP 应删除 v1.x 字符串,以确保字符串的使用者只有一个真实来源。
注意:TCF 版本 2.0 引入了“发布者限制”,如果发布者用尽了限制,可能会导致 TC 字符串大于 Cookie 的大小限制。虽然这种可能性很小,但应该加以防范——CMP 应该与出版商合作,帮助他们实现目标。CMP 在决定这些 TC 字符串的存储机制时可能需要考虑到这一点。