ORTB
中 / EN

GPP / TCF

GPP v1 · TCF 2.2打开字符串解码器 →

GPP（Global Privacy Platform）是 IAB Tech Lab 发布的隐私信号协议：把多个辖区的同意与选择信号封装为单一字符串，沿广告链路传递。理解它只需一个心智模型——GPP 是外层信封，TCF 只是其中一个 section 的载荷。本页先建立这个模型，再拿一条真实字符串走一遍解码，最后铺开完整参考表。

本页目录

心智模型：GPP 是信封，section 是信纸

一条 GPP 字符串就是若干个独立规范的载荷，用 ~ 串起来，前面再附一张目录（Header）。目录只说明装了哪几封信，信的内容各自按自己的规范书写。

DBACNY

Header · 目录

只声明装了哪几封信，不含任何同意信号

CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA

Section 2 · EU TCF v2

载荷 · 位布局由该 section 自己的规范定义

1YNN

Section 6 · USPrivacy String (Unencoded)

载荷 · 位布局由该 section 自己的规范定义

以官方 GPP String Example 2 为例：Header 声明本次携带 section 2 与 section 6，随后依次是它们的载荷。

① Header 只是目录

Header 只有 Type / Version / Sections 三个字段，作用是声明本串携带哪些 section ID，本身不承载任何同意或退出信号。想知道用户到底同意了什么，必须解开对应的 section。

② 位布局归各 section 自己的规范

GPP 不规定 section 内部结构，所以 EU TCF v2、US National 与各州 section 的位布局彼此独立、各自成文。本站目前对 section 2（EU TCF v2）与 section 6（USPrivacy）做字段级解码，其余只识别 ID 与 Version，并给出官方规范链接。

③ 首字符是身份识别约定

首字符 D 表示这是套了信封的 GPP 字符串；首字符 C 表示没有信封，直接就是 IAB Europe TCF v2 的 TC String。这是与旧格式向后兼容的识别约定，也是解码器判断入口的依据。

谁写 · 谁传 · 谁读

  1. 1

    写：CMP

    同意管理平台在浏览器侧生成字符串，经 __gpp() 队列与 window.__gpp 回调对外提供。

  2. 2

    传：广告链路

    随请求携带：URL 宏 gpp / gpp_sid，或 OpenRTB 2.6 起的 regs.gpp / regs.gpp_sid。

  3. 3

    读：供应商

    DSP / Exchange 解出 Header 找到生效 section，再按该 section 的规范解出同意与退出信号，据此决定参竞与投放。

走一遍：一条真实字符串的解码过程

抽象的 Fibonacci 编码与 bitfield，看一次真实字符串怎么被逐位读出来最直观。下面用官方示例串分四个阶段走查：每一步都会高亮当前字段覆盖的 base64 字符与 bit 区间，并给出解出的值。

样本 · 官方 GPP String Example 2DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN

完整样本串

DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN

当前读取的片段

DBACNY~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN
0DBACN5Y~CPX10xRfAP15XxRfA20AfKAB25ENB-C30gAAAA35AAAAA40AYgAA45AAAAA50A~1YN55N
编码类型
modified base64
bit 区间
字符级切分，本步不涉及 bit 读取
字符区间
chars[0..6)

Header

解出的值

DBACNY

整条串被 ~ 切成 3 段：第 1 段是 Header，其余每段是一个 section 的载荷。Header 声明本次携带的 section ID 为 [2, 6]。

字符串所含 Section ID 的有序列表；ID 顺序与其 section 在串中的出现顺序一致。Fibonacci range 编码：先读 int(12) 的条目数 amount，随后每条读一个 single/group 标志位 + 一个 Fibonacci 偏移量（相对上一个 ID，首条以 0 为基准）；若为 group 再读一个 Fibonacci 长度。ENOrdered list of Section IDs contained in the string; IDs appear in the same order as their sections. Fibonacci range: int(12) amount, then per item a single/group bit + Fibonacci offset (from last seen ID, 0-based for the first entry), groups add a Fibonacci length.

步骤 1 / 29聚焦后可用 ← → 方向键切步

第 1 步，共 29 步：Header，modified base64，值 DBACNY

换你自己的字符串

在独立页面打开解码器 →

走查用的是固定官方样本。把下面输入框换成你线上抓到的字符串，即可看到完整的字段级解码结果（含走查未覆盖的变长 Vendor 段）。解析全部在浏览器本地完成，字符串不会上传。

官方示例：

GPP Header

GPP v1
Type3（GPP Header）

Header 声明 sections：[2, 6]

Section 2 · EU TCF v2

tcfeuv2

Core String

TCF v2
Created2022-04-20T22:00:00.000Z
LastUpdated2022-04-20T22:00:00.000Z
CmpId / Version31 / 640
ConsentScreen1
ConsentLanguageEN
VendorListVersion126
TcfPolicyVersion2
PublisherCCDE
IsServiceSpecifictrue
UseNonStandardTextsfalse
PurposeOneTreatmentfalse
NumPubRestrictions0
Purposes Consent—
Purposes 正当利益—
Special Features Opt-in—
Vendor Consent无
Vendor 正当利益无

Section 6 · USPrivacy String (Unencoded)

uspv1
version1
explicitNoticeY
optOutSaleN
lspaCoveredTransactionN

字符串结构与 Header

[Header]~[Discrete Section]~[Discrete Section]…
  • ~ — section 分隔符：把 Header 与各 section 载荷依次串起来
  • . — section 内子段分隔符（如 TC String 的 segments）
  • modified base64（RFC 4648 字符表，每字符 6 bit，右侧补 0 至 6 的倍数）

首字符为 D（bits 000011 → base64 索引 3）即 GPP 字符串；为 C（000010 → 2）即 IAB Europe TCF v2 TC String——与旧格式向后兼容的识别约定。

字段类型描述
TypeInt(6)固定为 3，标识这是 GPP Header 字段。ENFixed to 3 as "GPP Header field".
VersionInt(6)GPP 规范版本号（当前为 1）。ENVersion of the GPP spec (currently 1).
SectionsRange(Fibonacci)字符串所含 Section ID 的有序列表；ID 顺序与其 section 在串中的出现顺序一致。Fibonacci range 编码：先读 int(12) 的条目数 amount，随后每条读一个 single/group 标志位 + 一个 Fibonacci 偏移量（相对上一个 ID，首条以 0 为基准）；若为 group 再读一个 Fibonacci 长度。ENOrdered list of Section IDs contained in the string; IDs appear in the same order as their sections. Fibonacci range: int(12) amount, then per item a single/group bit + Fibonacci offset (from last seen ID, 0-based for the first entry), groups add a Fibonacci length.

编码数据类型

这张表是后面所有字段表的读法基础：TC String 里出现的 Range(Fibonacci)、N-Bitfield、Datetime 等术语都在此定义，建议先扫一遍再往下看。

名称编码描述
Boolean1 bit在 GPP JS API 的输出约定中 0=true、1=false（具体含义由各 section 自己的文档定义）。EN0=true, 1=false in the GPP JS API output convention (section-specific docs define meaning).
Integer (fixed)x bits定长整数；常见位宽为 3、6、12、16、24、36 bit。ENFixed-length integer; usual lengths 3, 6, 12, 16, 24, 36 bits.
Integer (Fibonacci)variableFibonacci 编码整数；位串总以连续两个 1（"11"）结束。ENFibonacci-coded integer; bit sequence always ends with "11".
String (fixed)x×6 bits每个字符占 6 bit，值为 ASCII 码减 65；用于语言码与国家码。ENEach character: ASCII − 65 as Int(6); used for language/country codes.
Datetime36 bits自 1970-01-01 UTC 起的十分之一秒数（即 Math.round(Date.now()/100)）。ENDeciseconds since 1970-01-01 UTC (Math.round(Date.now()/100)).
Bitfield (fixed)x bits每个 ID 占一个布尔位；首位对应 ID 1。ENOne boolean per ID; first bit ↔ ID 1.
N-BitfieldInt(16) length + bitfield变长 bitfield，前置一个 Int(16) 表示其长度。ENVariable-length bitfield prefixed by its length.
Range (Int)variable先读 int(12) 条目数，随后每条：single/group 标志位 + int(16) 起始值（group 再加 int(16) 结束值）；结果不保证有序。ENint(12) count, then per item: single/group bit + int(16) start (+ int(16) end for groups); not necessarily sorted.
Range (Fibonacci)variable先读 int(12) 条目数，随后每条：single/group 标志位 + 相对上一个 ID 的 Fibonacci 偏移（group 再加 Fibonacci 长度）；必须有序。ENint(12) count, then per item: single/group bit + Fibonacci offset from last seen ID (+ Fibonacci group length); must be sorted.
OptimizedRangevariable一个布尔开关：1 → Fibonacci Range；0 → 变长 bitfield。ENBoolean switch: 1 → Fibonacci Range; 0 → variable-length bitfield.
ArrayOfRanges / N-ArrayOfRangesvariable先读 int(12) 记录数；每条记录含 key + type + ID 集合（为向下兼容保留的旧结构）。ENint(12) record count; per record key + type + id collection (legacy downward-compatible shape).

Section 注册表（官方 ID 1–27）

核心 section（ID 1–7）

IDCMP API 前缀名称辖区状态
1tcfeuv1EU TCF v1 ↗EU已废弃
2tcfeuv2EU TCF v2 ↗本站可字段级解码EU/EEA现行
3—GPP Header ↗—必需
4—GPP Signal Integrity ↗—保留
5tcfcav1Canadian TCF ↗CA现行
6uspv1USPrivacy String (Unencoded) ↗本站可字段级解码US已废弃
7usnatMSPA US National ↗US现行
美国各州 section（ID 8–27，共 20 个）8–27

各州 section 的位布局独立成文、结构高度相似，本站尚未收录字段级解码；点开可查 ID、CMP API 前缀与官方规范链接。

TCF EU v2 · TC String

IAB Europe TCF v2（TCF 2.2 起政策版本为 4；政策版本低于 4 的字符串自 2023-09-30 起无效）

[Core String].[Disclosed Vendors].[Publisher TC] —— Core 之后的各段以 "." 分隔，并各自以一个 3-bit 的 SegmentType 自我标识

段（Segment）

CoreSegmentType=0必填

供应商透明度与同意的基础信息；总是第一段，且不带 SegmentType 前缀。ENBasic vendor transparency & consent; always first, no SegmentType prefix.

DisclosedVendorsSegmentType=1必填

CMP 向用户披露过的供应商列表。自 TCF 2.3（2025 年 4 月）起为强制段，用于消除特殊用途下正当利益（LI）的歧义。ENVendors disclosed to the user by the CMP. Mandatory since TCF 2.3 (Apr 2025) to resolve special-purpose LI ambiguity.

PublisherTCSegmentType=3

媒体方自身的用途透明度与同意，含自定义用途（custom purposes）。ENPublisher's own purposes transparency & consent, incl. custom purposes.

Core String 字段布局

bit 区间由上表位宽累加得出，与前面走查的第四阶段完全同源；末条为变长三段，位宽由数据本身决定。

字段位宽bit 区间描述
Version6bits[0..6)编码格式版本（值为 2）。ENEncoding format version (2).
Created36bits[6..42)TC String 首次创建时刻的 epoch 十分之一秒数。ENEpoch deciseconds when the TC string was first created.
LastUpdated36bits[42..78)最后一次更新的 epoch 十分之一秒数（2021 年 12 月起按天级精度与 Created 保持一致）。ENEpoch deciseconds of the last update (since Dec 2021 kept equal to Created at day-level resolution).
CmpId12bits[78..90)最后更新该字符串的 CMP 的 ID。ENID of the CMP that last updated the string.
CmpVersion12bits[90..102)该 CMP 的版本号。ENVersion of that CMP.
ConsentScreen6bits[102..108)用户给出同意时所在的 CMP 界面屏号。ENCMP screen number where consent was given.
ConsentLanguage12bits[108..120)CMP 界面的 ISO 639-1 语言码（2×6 bit，a=0…z=25）。ENISO 639-1 language of the CMP UI (2×6 bits, a=0…z=25).
VendorListVersion12bits[120..132)所使用的 Global Vendor List 版本。ENGlobal Vendor List version used.
TcfPolicyVersion6bits[132..138)GVL 对应的 TCF 政策版本（TCF 2.2 起为 4）。ENTCF policy version of the GVL (4 since TCF 2.2).
IsServiceSpecific1bits[138..139)必须为 1；值为 0 的字符串会被供应商判为无效。ENMust be 1; a string with 0 is considered invalid by vendors.
UseNonStandardTexts1bits[139..140)CMP 改动了标准的 stack / illustration 文案。ENCMP modified standard stack/illustration texts.
SpecialFeatureOptIns12bits[140..152)各 Special Feature（1–2）的 opt-in 状态。ENOpt-in per Special Feature (1–2).
PurposesConsent24bits[152..176)Purpose 1–24 的同意状态（法律依据：同意）。ENConsent per Purpose 1–24 (legal basis: consent).
PurposesLITransparency24bits[176..200)Purpose 维度的正当利益（LI）状态；TCF 2.2 已废弃 Purpose 3–6 的 LI（对应位必须为 0）。ENLegitimate interest per Purpose; TCF 2.2 deprecated LI for purposes 3–6 (bits must be 0).
PurposeOneTreatment1bits[200..201)1 表示不披露 Purpose 1（按辖区施行的特殊处理）。EN1 = Purpose 1 not disclosed (special treatment by jurisdiction).
PublisherCC12bits[201..213)ISO 3166-1 alpha-2 国家码，决定参照的立法辖区。ENISO 3166-1 alpha-2 country determining the legislation of reference.
VendorConsents + VendorLI + PubRestrictions变长bits[213..)依次为 Vendor Consent Section 与 Vendor Legitimate Interest Section（各为 MaxVendorId int(16) + bitfield 或 range），再接 NumPubRestrictions int(12) 与可选的限制条目（PurposeId 6 bit + RestrictionType 2 bit + 供应商 range）。三段均为变长，位宽由数据本身决定，无法静态推算。ENVendor Consent Section and Vendor Legitimate Interest Section (MaxVendorId int(16) + bitfield or range), then NumPubRestrictions int(12) with optional restriction entries (PurposeId 6 + RestrictionType 2 + vendor range).

Purpose 命名（TCF 2.2）

  • P1在设备上存储和/或读取信息ENStore and/or access information on a device
  • P2使用有限数据选择广告ENUse limited data to select advertising
  • P3为个性化广告建立用户画像ENCreate profiles for personalised advertising
  • P4使用用户画像选择个性化广告ENUse profiles to select personalised advertising
  • P5为个性化内容建立用户画像ENCreate profiles to personalise content
  • P6使用用户画像选择个性化内容ENUse profiles to select personalised content
  • P7衡量广告效果ENMeasure advertising performance
  • P8衡量内容效果ENMeasure content performance
  • P9通过统计数据或跨来源数据组合理解受众ENUnderstand audiences through statistics or combinations of data from different sources
  • P10开发与改进服务ENDevelop and improve services
  • P11使用有限数据选择内容ENUse limited data to select content

Special Feature（TCF 2.2）

  • SF1使用精确地理位置数据ENUse precise geolocation data
  • SF2主动扫描设备特征以进行识别ENActively scan device characteristics for identification

Purpose 命名取 IAB Europe TCF Policies / Global Vendor List 官方措辞（TCF 2.2 修订版）；11 为 2.2 新增，12–24 保留。

USPrivacy String（已废弃）2024-01

IAB 已于 2024-01 废弃并由 GPP section 6 承接；存量流量与部分平台参数仍会直接传递，诚实收录供调试。它是 section 载荷不必位编码的现成例子：4 个明文字符逐位对应 4 个字段。

4 个字符：version · explicitNotice · optOutSale · lspaCoveredTransaction
#字段类型描述
1version1字符串规范版本（恒为 1）。ENString specification version (always 1).
2explicitNoticeY / N / -是否已提供明确的告知与选择机会：Y 是，N 否，- 不适用。ENExplicit notice/opportunity provided: Y yes, N no, - not applicable.
3optOutSaleY / N / -用户是否已选择退出（opt out）数据出售/共享：Y 已退出，N 未退出，- 不适用。ENUser opted out of sale/sharing: Y opted out, N did not, - not applicable.
4lspaCoveredTransactionY / N该交易是否受 IAB Limited Service Provider Agreement（LSPA）覆盖。ENTransaction covered by the IAB Limited Service Provider Agreement.

传输：URL 宏 · OpenRTB · CMP API

URLMacro描述
gpp${GPP_STRING_XXXXX}URL-safe 编码的 GPP 字符串；XXXXX 为接收方供应商的 GPP ID。没有 GPP ID 的供应商可接收 ${GPP_STRING}。ENURL-safe encoded GPP string; XXXXX is the receiving vendor's GPP ID. Vendors without a GPP ID may receive ${GPP_STRING}.
gpp_sid${GPP_SID}本次交易生效的 Section ID；通常为单个 ID，少数情况下为逗号分隔的两个。ENSection ID(s) in force for the transaction; normally a single ID, rarely two comma-separated.
  • OpenRTB · OpenRTB 2.6-202211 起：regs.gpp（字符串）与 regs.gpp_sid（section ID 数组）；此前各平台以 regs.ext.gdpr_consent / user.ext.consent 等私有字段承载。
  • CMP API · 浏览器侧经 __gpp() 队列与 window.__gpp 回调读取（GPP CMP API v1.1，2023-06）；TCF 2.2 之前为 __tcfapi()。

数据源与基线

收录基线

GPP String v1.0（2022-09-28 发布，2023-11-03 澄清修订）+ TCF EU v2 TC String（Final v.2.2 基线，含 2.3/2.4 修订）。Section 注册表收录至官方 Section Information.md 最新（ID 1–27）。

官方仓库与采集记录

GPP 字符串格式与 Section 注册表：官方仓库 InteractiveAdvertisingBureau/Global-Privacy-Platform · commit 03fdf03 · 采集 2026-08-31 · CC-BY 3.0 (IAB Tech Lab)

TCF EU v2 TC String 字段布局：TCFv2/IAB Tech Lab - Consent string and vendor list formats v2.md（Final v.2.2 基线，含 2.3/2.4 修订）· 采集 2026-08-31 · CC-BY 3.0 (IAB Tech Lab) / IAB Europe

字段描述以 IAB 官方英文原文为准，中文为本站译文；zh 页面可用顶部的中英对照开关隐藏英文附注。

内容忠实于 IAB Tech Lab GPP / TCF 官方规范（CC-BY 3.0）。