ORTB
中 / EN
分册导航

Privacy · 隐私与同意信号

GPP String v1.0 · TCF v2.2 基线
本页目录

为什么广告链路需要隐私信号

一次程序化竞价从发布商出发，经供给方平台（Supply-Side Platform，SSP）分发到若干个需求方平台（Demand-Side Platform，DSP），途中由同意管理平台（Consent Management Platform，CMP）提供同意状态，中间还可能有若干次转手。这些系统互不共享数据库、互不信任，却都要在毫秒级的竞价窗口内、以机器可读的方式确认同一件事：这个用户、这次页面浏览，能不能被处理，能处理到什么程度——能不能用于个性化定向、能不能被记录、能不能传给下一跳。

如果这件事靠双边合同解决，链路上有多少方就要签多少份协议，而且合同文本没法在一次竞价请求里被机器读取和校验。隐私信号要解决的正是这个多方协同问题：把「能不能、到什么程度」压缩成一段各方都能解析的字符串，跟着 bid request 一起传递，下游每一跳都能读取、校验，并据此决定是否继续处理。

这也是为什么这类信号天生是「编码格式」而不是「文字条款」——它的读者不是人，是竞价链路里的机器。

这个问题在实践中拆成三类，本域也按同一轴组织信号：

  • 同意类用户是否就某个目的 / 某个供应商给出许可：透明度与同意框架（Transparency & Consent Framework，TCF）以 PurposesConsent / VendorConsents 位集记录
  • 退出类用户是否选择退出出售 / 共享：多州隐私协议（Multi-State Privacy Agreement，MSPA） 以 Int(2) 三值记录、USPrivacy 以第 3 个字符记录
  • 披露类这笔广告需要附带哪些透明度信息：欧盟《数字服务法》（Digital Services Act，DSA）经 regs.ext.dsa / bid.ext.dsa 承载

为什么会有这么多标准

这个域的标准数量不是设计出来的，是辖区立法逐年叠加的结果。按时间读一遍，字母汤就变成了有因果的四幕。

  1. 各管各的（2018–2021）

    两个辖区、两套字符串，互不相干：欧盟用 TCF 表达同意，美国用 USPrivacy 表达退出。

    • 欧盟《通用数据保护条例》（General Data Protection Regulation，GDPR）开始适用；互动广告局（Interactive Advertising Bureau，IAB）的欧洲分支 IAB Europe 以 TCF 承载同意与透明度信号，成为欧盟流量的主流框架。
    • 美国加州《消费者隐私法》（California Consumer Privacy Act，CCPA）生效；IAB Tech Lab 的 USPrivacy String（形如 1YNN）承载退出信号。

  2. 字符串失控，GPP 做容器（2022）

    GPP 不替换任何既有标准，它只做容器——原有标准成为 section 载荷，Header 声明本次带了哪几段。

    • 全球隐私平台（Global Privacy Platform，GPP）字符串 v1.0 发布：Header ~ Section ~ Section 的容器格式定稿。· last-verified 2026-08-31
    • OpenRTB 2.6 将 gdpr / us_privacy / gpp / gpp_sid 纳入 Regs 核心字段。2.5 的 Regs 仅有 coppa 与 ext，此前业界以 regs.ext 私有承载。· last-verified 2026-08-12
    • MSPA US National Section v1.0 发布。· last-verified 2026-08-31

  3. 各州挂入与旧串退场（2023–2024）

    容器稳定之后，新辖区以新增 section 的方式接入，不再各造一条新字符串；同时旧串开始退场。

    • GPP CMP API v1.1：浏览器侧经 __gpp() 队列与 window.__gpp 回调读取。注意这是 CMP API 的版本号，与 GPP 字符串格式版本（仍为 v1.0）无关。· last-verified 2026-08-31
    • TCF 政策版本低于 4 的字符串自本日起失效。· last-verified 2026-08-31
    • USPrivacy String 停止支持。· last-verified 2026-08-31
    • GPP String v1.0 澄清修订（版本号未变，仍为 v1.0）。· last-verified 2026-08-31
    • USPrivacy String 正式废弃，由 GPP §6 承接其未编码形态；存量流量与部分平台参数仍会直接传递。· last-verified 2026-08-31
    • 欧盟 DSA 开始适用，广告透明度披露义务经 regs.ext.dsa / bid.ext.dsa 承载。
    • MSPA US National Section v2.0 发布，依 Second Amended and Restated MSPA 新增 DE / IN / IA / KY / MD / MI / MT / NH / NE / NJ / OR / RI / TN / TX 共 14 州支持。其中 MI（Michigan）在 GPP Section 注册表中没有对应的 section ID。· last-verified 2026-08-31

  4. 现在（2025 起）

    TCF 侧仍在演进，GPP 容器本身自 2023-11 的澄清修订后未再变更。

    • TCF 2.3：DisclosedVendors 段成为强制，用于消除特殊用途下正当利益的歧义。· last-verified 2026-08-31
    • TCF 2.4 处于滚动修订中，尚无发布版——引用时不得写死为已发布版本。· last-verified 2026-08-31

标准之间的关系

同一信号可能同时有多种关系，树状结构表达不了——例如 TCF EU 既是 GPP §2 的载荷（承载关系），又以独立 TC String 的形式与 GPP 并存（并存关系）。下图四条横带是知识层级，连线是关系类型。第三条横带是 GPP 容器本身：整串即 GPP String = Header ~ Section ~ Section，由 Header 声明本次带了哪几段；带内横条是可复用子段（Reusable Subsection），属横向扩展机制而非固定分区。图中其余缩写：全球隐私控制（Global Privacy Control，GPC）；立法驱动带另涉加州隐私权法（California Privacy Rights Act，CPRA）。

立法驱动标准与信号GPP 容器承载与访问欧盟《通用数据保护条例》GDPR欧盟《通用数据保护条例》美国各州隐私法（CCPA / CPRA 等）美国各州隐私法（CCPA / CPRA 等）欧盟《数字服务法》DSA欧盟《数字服务法》IAB Europe TCF v2TCF EUIAB Europe TCF v2Canadian TCFCanadian TCFCanadian TCFUSPrivacy StringUSPrivacyUSPrivacy StringMSPA 技术规范（US National + 各州）MSPAMSPA 技术规范（US National + 各州）Global Privacy ControlGPCGlobal Privacy ControlGoogle Additional ConsentGoogle ACGoogle Additional ConsentDSA 透明度承载约定DSA 承载约定DSA 透明度承载约定Header（目录）HeaderHeader（目录）§2 EU TCF v2§2§2 EU TCF v2§5 Canadian TCF§5§5 Canadian TCF§6 USPrivacy§6§6 USPrivacy§7 US National§7§7 US National§8–27 美国各州§8–27§8–27 美国各州Reusable Subsection · 以 . 分隔可附加到任意 section（SubsectionType Int(2)：0 Core / 1 GPC）Reusable SubsectionReusable Subsection · 以 . 分隔可附加到任意 section（SubsectionType Int(2)：0 Core / 1 GPC）OpenRTB 协议 · regs.gpp · regs.gpp_sid · regs.gdpr · regs.us_privacy · user.consentOpenRTB 协议regs.gppregs.gpp_sidregs.gdprregs.us_privacyuser.consentURL 宏 · ${GPP_STRING} · ${GPP_SID}URL 宏${GPP_STRING}${GPP_SID}CMP JS API · __gpp() · __tcfapi()CMP JS API__gpp()__tcfapi()HTTP 头与 JS 属性 · Sec-GPC · navigator.globalPrivacyControlHTTP 头与 JS 属性Sec-GPCnavigator.globalPrivacyControlOpenRTB ext · regs.ext.dsa · bid.ext.dsaOpenRTB extregs.ext.dsabid.ext.dsa
图例催生承载（容器 → 载荷）整串传递（GPP 容器 → 承载点）并存横切旁路（不经容器）

容器整体如何传递——整条 GPP 字符串经承载层传递 OpenRTB 2.6 的 Regs 核心字段为 regs.gpp（字符串）与 regs.gpp_sid（适用 section 的整数数组），同对象内另有 regs.gdpr 与 regs.us_privacy 两个既有字段；独立 TC String 不经 GPP，经 user.consent 传递并与 regs.gdpr 配套。 URL 侧为 ${GPP_STRING} 宏与 ${GPP_SID} 宏；浏览器侧经 CMP JS API 的 __gpp() 队列与 window.__gpp 回调读取。上图箭头只画到容器正下方的 OpenRTB 与 URL 宏两路，CMP JS API 一路即本注所述。 注意 gpp_sid 在 OpenRTB 中是 integer[]，在 URL 宏中是字符串，且不应包含 section 3（Header）与 4（Signal Integrity）。

关系清单（与上图等价）
从到说明出处
GDPR催生TCF EUGDPR 适用后，IAB Europe 以 TCF 承载同意与透明度信号。—
美国各州隐私法（CCPA / CPRA 等）催生USPrivacy加州 CCPA 催生 USPrivacy String，以 4 个明文字符承载退出信号。—
DSA催生DSA 承载约定欧盟 DSA 的广告透明度义务由 IAB Tech Lab 定义其在 OpenRTB 中的承载约定。—
TCF EU承载（容器 → 载荷）§2TCF EU v2 的 TC String 是 GPP §2 的载荷；位布局由 TCF 规范定义，GPP 不作规定。Global-Privacy-Platform/Sections/Section Information.md — Section ID 2 → Sections/EEA
Canadian TCF承载（容器 → 载荷）§5Canadian TCF 是 GPP §5 的载荷。官方仓库另有 TCF EU / TCF CA 对比文档。Global-Privacy-Platform/Sections/Section Information.md — Section ID 5 → Sections/Canada
USPrivacy承载（容器 → 载荷）§6GPP §6 承载 USPrivacy String 的未编码形态（4 个明文字符，不经 base64）。Global-Privacy-Platform/Sections/Section Information.md — Section ID 6 → USPrivacy String (Unencoded Format)
MSPA承载（容器 → 载荷）§7MSPA US National 是 GPP §7 的载荷；其 Notice / Opt-Out 标量字段为 Int(2) 三值语义，SensitiveDataProcessing 为 N-Bitfield(2,16)。Global-Privacy-Platform/Sections/US-National/IAB Privacy's Multi-State Privacy Agreement (MSPA) US National Technical Specification.md
MSPA承载（容器 → 载荷）§8–2720 个州各占一个 section ID（§8–27），字段集与 N-Bitfield 参数逐州不同，是 US National 的子集而非副本。Global-Privacy-Platform/Sections/Section Information.md（ID 8–27）+ Sections/US-States/<ST>/ 各州技术规范
整串传递（GPP 容器 → 承载点）OpenRTB 协议 regs.gpp regs.gpp_sid regs.gdpr regs.us_privacy user.consent整条 GPP 字符串经 OpenRTB 2.6 的 regs.gpp（字符串）传递，regs.gpp_sid 声明本次适用哪些 section。本站 data/openrtb-spec/v26 Regs.gpp / Regs.gpp_sid（upstream commit 1debba80）
整串传递（GPP 容器 → 承载点）URL 宏 ${GPP_STRING} ${GPP_SID}URL 侧经 ${GPP_STRING} 宏传递整串、${GPP_SID} 宏传递适用 section；带供应商 ID 的变体为 ${GPP_STRING_XXXXX}。本站 data/privacy-spec/spec.json transport.urlParams（采集自 GPP 官方仓库）
TCF EU并存OpenRTB 协议 regs.gpp regs.gpp_sid regs.gdpr regs.us_privacy user.consent独立 TC String 并未被 GPP 取代：EEA 规范明写在其被 IAB Europe 正式废弃前，TC String 必须继续随交易头传递、TCF API 必须实现、供应商必须在所有 GDPR 适用交易中解析它。故 GPP §2 与独立 TC String 并存，站内承载点为 user.consent 与 regs.gdpr 配套。Global-Privacy-Platform/Sections/EEA/GPPExtension: IAB Europe TCF.md — Special note regarding TCF and GPP
GPC横切Reusable SubsectionGPC 是官方列出的第一个 Reusable Subsection：以 SubsectionType Int(2)=1 标识，用 . 分隔符附加到任意 section，载荷为单个 Boolean。是否可用由各 section 自己的文档规定。Global-Privacy-Platform/Sections/Section Information.md — Reusable Subsections；US National 与 CA 规范均含 SubsectionType/Gpc 字段
GPC旁路（不经容器）HTTP 头与 JS 属性 Sec-GPC navigator.globalPrivacyControlGPC 的原始形态不经 GPP 容器：以 Sec-GPC 请求头（0/1）与 navigator.globalPrivacyControl（true/false）直接暴露。Global-Privacy-Platform/Sections/Section Information.md — Reusable Subsections / Global Privacy Control (GPC)
Google AC旁路（不经容器）CMP JS API __gpp() __tcfapi()Additional Consent 不是 GPP section：addtl_consent 经 __tcfapi 的 TCData 返回值携带，属 Google 侧约定。—
DSA 承载约定旁路（不经容器）OpenRTB ext regs.ext.dsa bid.ext.dsaDSA 透明度信息走 OpenRTB 的 ext 扩展位（请求侧 regs.ext.dsa、DSP 回传 bid.ext.dsa），不在 OpenRTB 2.6 核心字段内，站内 OpenRTB 数据模型也未对 ext 子字段建模。—

现行状态一览

实现前先确认信号是否还活着——本域已废弃与将废弃的标准特别多。标「状态待取证」的条目，其存亡本站尚无官方出处，不作断言。

信号GPP section类型状态关键日期发布方
TCF EU v2现行基线为 Final v.2.2，含 2.3 与 2.4 滚动修订；2.4 尚无发布版，引用时不得写死。§2同意类现行2025-04（TCF 2.3：DisclosedVendors 段强制）IAB Europe
Canadian TCF官方仓库另有 TCF EU / TCF CA 对比文档，可作为分册第 7 节的差异素材。本站解码器对该 section 仅读取首字段 Version。§5同意类现行—IAB Canada
USPrivacy String4 个明文字符（version · explicitNotice · optOutSale · lspaCoveredTransaction），不经 base64 编码——它是 section 载荷不必位编码的现成反例。存量流量与部分平台参数仍会直接传递，诚实收录供调试。§6退出类已废弃2023-09-30 停止支持 · 2024-01 由 GPP §6 承接IAB Tech Lab
MSPA US National（§7）消费者维度的 Notice / Opt-Out 标量字段为 Int(2) 三值语义（0 不适用 / 1 是 / 2 否），非布尔；SensitiveDataProcessing 则为 N-Bitfield(2,16)，并非 Int(2)。Notice 与 Opt-Out 之间存在跨字段合法性约束（如 SaleOptOut=0 的成立条件是 SaleOptOutNotice 未提供）。另有 MspaCoveredTransaction / MspaOptOutOptionMode / MspaServiceProviderMode 三个 Int(2) 模式字段描述交易方合同身份，与消费者维度分列。上游不一致US National v2.0（2024-10）声明新增支持 MI（Michigan），但 GPP Section 注册表中没有 MI 对应的 section ID——该州只能经 US National §7 表达，无独立 section。§7退出类现行2022-12 v1.0 · 2024-10 v2.0IAB Tech Lab合同主体 · IAB Privacy, Inc.
美国各州 section（§8–27，共 20 个）每州一份独立技术规范，字段集是 US National 的子集且 N-Bitfield 参数逐州不同（如 California 的 SensitiveDataProcessing 为 N-Bitfield(2,9) 而非 (2,16)），不能共用一份位布局。注册表 20 个州 section 与 v2.0 所依的 14 州名单并不重合：名单中的 MI 无独立 section（仅经 §7 表达），名单外的 CA / CO / CT / UT / VA / FL / MN 七州各有 section。官方 Section Information.md 对 ID 8–27 只列州名，规范链接由本站按 Sections/US-States/<ST>/ 约定补全。上游不一致Texas 的文档命名与其他州不同（IAB Privacy's Texas Privacy Technical Specification.md，而非 GPP Extension: Texas …），批量抽取时不能按统一文件名模式匹配。§8–27退出类现行—IAB Tech Lab合同主体 · IAB Privacy, Inc.
独立 TC String（不经 GPP 容器）与 §2 是同一载荷的两种承载形态，不是两个信号：首字符 C 表示未套 GPP 容器。EEA 规范明写在 IAB Europe 正式废弃前，独立 TC String 必须继续随交易头传递、TCF API 必须实现、供应商必须在所有 GDPR 适用交易中解析它——故与 GPP §2 并存而非被替代。本站解码器已支持（classifyPrivacyString 的 tcf-eu 分支）。—同意类现行—IAB Europe
Google Additional Consentaddtl_consent 经 __tcfapi 返回的 TCData 携带，不是 GPP section。属 Google 侧约定，与本站已收录的 IAB 规范授权链不同，需独立立项取证；其存亡（是否日落）同样须以 Google 官方文档为准，本站不作断言，故状态记为「状态待取证」而非 sunset。—同意类状态待取证—Google
Global Privacy Control双重身份：原始形态是 Sec-GPC 请求头（值为 1，或整个头省略；官方规范未定义 0）与 navigator.globalPrivacyControl（true/false），不经 GPP 容器；GPP 形态是官方列出的第一个 Reusable Subsection（SubsectionType Int(2)=1，载荷为单个 Boolean），可附加到任意 section。本站解码器目前不解析 GPC 子段。—退出类现行—W3C Web Privacy Community Group 与浏览器厂商
DSA 透明度（regs.ext.dsa / bid.ext.dsa）披露类信号，既非同意也非退出：其校验规则与失效形态与同意类完全不同。立法来源是欧盟 DSA，承载约定由 IAB Tech Lab 定义。不在 OpenRTB 2.6 核心字段内，且本站 OpenRTB 字段模型不支持 ext 嵌套子字段，需在 Privacy 侧自建数据并链到既有的 #regs-ext / #bid-ext 锚点。—披露类现行—IAB Tech Lab

谁管什么

隐私域是多个标准组织交错的领域：读任何一份文档前，先确认该问题该信谁。下表发布方多为 IAB 的区域分支；GPC 的原始形态由万维网联盟（World Wide Web Consortium，W3C）的 Web Privacy 社区组与浏览器厂商推进。注意 MSPA 的合同主体与技术规范发布方不是同一实体。

发布方管什么授权
IAB Tech Lab ↗
  • GPP 字符串格式与 Section 注册表
  • USPrivacy String（已废弃）
  • MSPA US National 与各州 section 技术规范
  • GPP CMP API 规范
  • DSA 透明度信息在 OpenRTB 中的承载约定
CC-BY 3.0 (IAB Tech Lab)
IAB Europe ↗
  • TCF（Transparency & Consent Framework）
  • GVL（Global Vendor List）
CC-BY 3.0 (IAB Tech Lab) / IAB Europe
IAB Canada ↗
  • Canadian TCF（GPP §5 载荷）
—
IAB Privacy, Inc. ↗MSPA 的合同主体是 IAB Privacy, Inc.，而各 section 的技术规范由 IAB Tech Lab 发布——两者不是同一实体，引用时须区分。
  • MSPA（Multi-State Privacy Agreement）合同主体
—
Google ↗
  • Additional Consent（addtl_consent）
  • Consent Mode
—
W3C Web Privacy Community Group 与浏览器厂商 ↗
  • GPC（Global Privacy Control）：Sec-GPC 请求头与 navigator.globalPrivacyControl
—

核心术语

读任何一份隐私规范都绕不开这十几个词。其中若干术语在不同标准里含义并不相同，定义中已标明。

  • Purpose

    TCF 对一类处理活动的划分，编号 1–24：1–11 已有官方命名（11 为 TCF 2.2 新增），12–24 保留。同意与正当利益均按 Purpose 维度记录。

  • Special Feature

    TCF 中需单独 opt-in 的两类特殊功能：1 使用精确地理位置数据、2 主动扫描设备特征以进行识别。在 TC String Core 段以 SpecialFeatureOptIns 位集表达（占 12 位，仅前 2 位有意义）。

  • Vendor

    在 GVL 中注册、参与广告链路的处理方。TCF 以 VendorConsents 与 VendorLI 两个变长段按供应商 ID 记录其法律依据，ID 取自 GVL。

  • CMPConsent Management Platform

    同意管理平台。在浏览器侧生成并暴露隐私字符串（经 __gpp() / __tcfapi() 队列），其 ID 与版本号写入 TC String 的 CmpId / CmpVersion 字段。

  • Section

    GPP 字符串中承载某一信号的独立段，以 ~ 分隔，其 ID 序列由 Header 声明。官方注册表现有 ID 1–27；每个 section 的位布局由其自身规范定义，GPP 不作规定。

  • SIDgpp_sid

    本次交易应适用的 section ID 列表。在 OpenRTB 中是 regs.gpp_sid（integer[]），在 URL 宏中是 ${GPP_SID}（字符串）——同一语义、两种类型。通常只有一个取值；section 3（Header）与 4（Signal Integrity）不应出现在其中。

  • MSPAMulti-State Privacy Agreement

    美国多州隐私协议。合同主体是 IAB Privacy, Inc.，技术规范由 IAB Tech Lab 发布——两者不是同一实体，引用时须区分。技术侧体现为 GPP §7（US National）与 §8–27（各州）section。

  • LSPALimited Service Provider Agreement

    IAB Limited Service Provider Agreement。USPrivacy String 的第 4 个字符 lspaCoveredTransaction 标记本次交易是否受该协议覆盖（Y/N）。

  • GVLGlobal Vendor List

    由 IAB Europe 维护的供应商注册表。TC String 的 VendorListVersion 字段记录所用版本；Vendor 与 CMP 的 ID 均取自它。本站尚未收录 GVL schema 与供应商数据。

  • GPCGlobal Privacy Control

    有两种形态：原始形态是 Sec-GPC 请求头（0/1）与 navigator.globalPrivacyControl（true/false），由 W3C Web Privacy CG 与浏览器厂商推进；GPP 形态是官方列出的第一个 Reusable Subsection，可附加到任意 section。

  • Reusable Subsection

    GPP 的横向扩展机制：新信号先以 subsection 形态存在，用 . 分隔符附加到任意 section，采用度上升后才可能升格为独立 section ID；以 SubsectionType Int(2) 自识别（0 Core / 1 GPC）。是否可用由各 section 自己的文档规定。注意 TCF EU（§2）不使用该机制，它用的是 TCF 自有的 Segment（SegmentType Int(3)）——同一个 . 分隔符承载两套不同的自识别方案。

推荐阅读路径

若要系统理解本域，按此顺序读：容器 → 编码原语 → 一个具体信号 → 承载方式 → 动手解码。标记「本期未建」的环节尚未上线，后续补齐。

  1. 1GPP 容器：字符串组成与 Header
  2. 2编码原语：Int / Fibonacci / Bitfield / N-Bitfield 怎么读
  3. 3一个具体信号：TCF EU 的 TC String 逐位布局
  4. 4退出类信号：MSPA US National 的三值字段模型
  5. 5承载方式：OpenRTB 字段、URL 宏与 CMP API
  6. 6动手：解码一条真实字符串
内容忠实于 IAB Tech Lab / IAB Europe 等官方规范（CC-BY 3.0）。