Chapter navigation
Privacy · consent & privacy signals
GPP String v1.0 · TCF v2.2 baselineOn this page
Why the ad chain needs privacy signals
A programmatic bid travels from the publisher through a Supply-Side Platform (SSP) to several Demand-Side Platforms (DSP), with a Consent Management Platform (CMP) supplying consent state along the way, and it may change hands a few more times in between. These systems share no database and trust none of each other, yet each must confirm the same thing in machine-readable form inside a millisecond-scale auction window: whether this user and this page view may be processed, and to what degree — may it be used for personalised targeting, may it be recorded, may it be passed on to the next hop?
Solving this with bilateral contracts would mean one agreement per party on the path, and contract text cannot be read or validated by a machine inside a bid request. Privacy signals exist for exactly this multi-party coordination problem: they compress “may I, and how far” into a string every party can parse, travel with the bid request, and are read and checked at each downstream hop to decide whether to keep processing.
This is also why such a signal is natively an encoding format rather than contractual wording — its reader is not a person but the machines along the auction path.
In practice the question splits into three kinds, and this domain organises its signals along the same axis:
- consentdid the user grant permission for a purpose / a vendor: the Transparency & Consent Framework (TCF) records it in the PurposesConsent / VendorConsents bitfields
- opt-outdid the user opt out of sale / sharing: the Multi-State Privacy Agreement (MSPA) records it as Int(2) three-valued fields, USPrivacy as its third character
- disclosurewhich transparency information travels with this ad: the EU Digital Services Act (DSA) carries it in regs.ext.dsa / bid.ext.dsa
Why there are so many standards
The number of standards in this domain was not designed; it accumulated as jurisdictions legislated year after year. Read it once in date order and the alphabet soup becomes a causal story in four acts.
Each jurisdiction on its own (2018–2021)
Two jurisdictions, two strings, no relation: the TCF expressed consent in Europe while USPrivacy expressed opt-out in the US.
- The General Data Protection Regulation (GDPR) became applicable; the Interactive Advertising Bureau (IAB)'s European branch IAB Europe used the TCF to carry consent and transparency signals and became the mainstream framework on EU traffic.
- The California Consumer Privacy Act (CCPA) took effect; IAB Tech Lab's USPrivacy String (of the form 1YNN) carried the opt-out signal.
String sprawl, and GPP as the container (2022)
GPP replaced no existing standard; it is only a container — the prior standards became section payloads, with the Header declaring which ones are present.
- The Global Privacy Platform (GPP) string v1.0 was published: the Header ~ Section ~ Section container format was finalised.· last-verified 2026-08-31
- OpenRTB 2.6 promoted gdpr / us_privacy / gpp / gpp_sid into the core Regs fields. In 2.5 Regs held only coppa and ext, so the industry had carried these in regs.ext privately.· last-verified 2026-08-12
- MSPA US National Section v1.0 released.· last-verified 2026-08-31
States plug in, legacy strings retire (2023–2024)
Once the container stabilised, new jurisdictions joined by adding a section rather than inventing another string, while the legacy strings began to retire.
- GPP CMP API v1.1: read in the browser via the __gpp() queue and the window.__gpp callback. Note this is the CMP API's own version number, unrelated to the GPP string format version (still v1.0).· last-verified 2026-08-31
- TC strings with a policy version below 4 became invalid as of this date.· last-verified 2026-08-31
- Support for the USPrivacy String ended.· last-verified 2026-08-31
- Clarifying revision of GPP String v1.0 (the version number did not change; still v1.0).· last-verified 2026-08-31
- The USPrivacy String was formally deprecated and superseded by GPP section 6 carrying its unencoded form; legacy traffic and some platform parameters still pass it directly.· last-verified 2026-08-31
- The EU DSA became applicable; ad-transparency disclosure obligations are carried via regs.ext.dsa / bid.ext.dsa.
- MSPA US National Section v2.0 released, adding support for 14 states (DE / IN / IA / KY / MD / MI / MT / NH / NE / NJ / OR / RI / TN / TX) under the Second Amended and Restated MSPA. MI (Michigan) has no corresponding section ID in the GPP Section registry.· last-verified 2026-08-31
Now (2025 onward)
The TCF side is still evolving; the GPP container itself has not changed since the November 2023 clarifying revision.
- TCF 2.3: the DisclosedVendors segment became mandatory, resolving legitimate-interest ambiguity for special purposes.· last-verified 2026-08-31
- TCF 2.4 is in rolling revision with no released version — it must not be cited as a published release.· last-verified 2026-08-31
How the standards relate
One signal can hold several relations at once, which a tree cannot express — TCF EU is both the payload of GPP section 2 (a carrying relation) and, as the standalone TC string, coexists with GPP (a coexistence relation). The four horizontal bands below are knowledge layers; the connecting lines are relation types. The third band is the GPP container itself: the whole string is GPP String = Header ~ Section ~ Section, with the Header declaring which sections travel in this bid; the full-width strip inside it is the Reusable Subsection, a horizontal extension mechanism rather than a fixed partition. Remaining abbreviations in the graph: Global Privacy Control (GPC); the legislative band also involves the California Privacy Rights Act (CPRA).
How the container as a whole travels——The whole GPP string travels through the carriage layer In OpenRTB 2.6 the Regs core fields are regs.gpp (the string) and regs.gpp_sid (integer array of applicable sections), alongside the pre-existing regs.gdpr and regs.us_privacy in the same object; The standalone TC string bypasses GPP and travels in user.consent, paired with regs.gdpr. On the URL side via the ${GPP_STRING} and ${GPP_SID} macros; In the browser via the CMP JS API's __gpp() queue and the window.__gpp callback. The graph above draws arrows only to the two carriage points directly beneath the container (OpenRTB and the URL macros); the CMP JS API route is this note's. Note that gpp_sid is an integer[] in OpenRTB but a string in the URL macros, and should not contain section 3 (Header) or 4 (Signal Integrity).
| From | To | Note | Source |
|---|---|---|---|
| GDPR | originatesTCF EU | Once GDPR became applicable, IAB Europe used the TCF to carry consent and transparency signals. | — |
| US state privacy laws (CCPA / CPRA etc.) | originatesUSPrivacy | California's CCPA drove the USPrivacy String: four plaintext characters carrying the opt-out signal. | — |
| DSA | originatesDSA 承载约定 | The EU DSA ad-transparency obligations are carried in OpenRTB per a convention defined by IAB Tech Lab. | — |
| TCF EU | carries (container → payload)§2 | The TCF EU v2 TC string is the payload of GPP section 2; its bit layout is defined by the TCF spec, not by GPP. | Global-Privacy-Platform/Sections/Section Information.md — Section ID 2 → Sections/EEA |
| Canadian TCF | carries (container → payload)§5 | Canadian TCF is the payload of GPP section 5. The official repo also ships a TCF EU / TCF CA comparison document. | Global-Privacy-Platform/Sections/Section Information.md — Section ID 5 → Sections/Canada |
| USPrivacy | carries (container → payload)§6 | GPP section 6 carries the USPrivacy String in unencoded form (four plaintext characters, not base64). | Global-Privacy-Platform/Sections/Section Information.md — Section ID 6 → USPrivacy String (Unencoded Format) |
| MSPA | carries (container → payload)§7 | MSPA US National is the payload of GPP section 7; its Notice / Opt-Out scalar fields use Int(2) three-valued semantics while SensitiveDataProcessing is an N-Bitfield(2,16). | Global-Privacy-Platform/Sections/US-National/IAB Privacy's Multi-State Privacy Agreement (MSPA) US National Technical Specification.md |
| MSPA | carries (container → payload)§8–27 | Twenty states each occupy a section ID (§8–27); their field sets and N-Bitfield parameters differ per state — subsets of US National, not copies. | Global-Privacy-Platform/Sections/Section Information.md（ID 8–27）+ Sections/US-States/<ST>/ 各州技术规范 |
| travels (GPP container → carriage point)OpenRTB regs.gpp regs.gpp_sid regs.gdpr regs.us_privacy user.consent | The whole GPP string travels in OpenRTB 2.6 as regs.gpp (a string), with regs.gpp_sid declaring which sections apply to this transaction. | 本站 data/openrtb-spec/v26 Regs.gpp / Regs.gpp_sid（upstream commit 1debba80） | |
| travels (GPP container → carriage point)URL macros ${GPP_STRING} ${GPP_SID} | On the URL side the whole string travels in the ${GPP_STRING} macro and the applicable sections in ${GPP_SID}; the vendor-ID variant is ${GPP_STRING_XXXXX}. | 本站 data/privacy-spec/spec.json transport.urlParams（采集自 GPP 官方仓库） | |
| TCF EU | coexistsOpenRTB regs.gpp regs.gpp_sid regs.gdpr regs.us_privacy user.consent | The standalone TC string has not been superseded by GPP: the EEA spec states that until IAB Europe officially deprecates it, the TC string must still be included in transaction headers, the TCF API must be implemented, and vendors must interpret it for all GDPR-applicable transactions. GPP section 2 and the standalone TC string therefore coexist; on this site the carriage point is user.consent alongside regs.gdpr. | Global-Privacy-Platform/Sections/EEA/GPPExtension: IAB Europe TCF.md — Special note regarding TCF and GPP |
| GPC | crosscutsReusable Subsection | GPC is the first officially listed Reusable Subsection: identified by SubsectionType Int(2)=1, attached to any section with the . delimiter, payload a single Boolean. Availability is defined by each section's own document. | Global-Privacy-Platform/Sections/Section Information.md — Reusable Subsections；US National 与 CA 规范均含 SubsectionType/Gpc 字段 |
| GPC | bypasses (outside the container)HTTP & JS surface Sec-GPC navigator.globalPrivacyControl | GPC's native form bypasses the GPP container: it is exposed directly as the Sec-GPC request header (0/1) and navigator.globalPrivacyControl (true/false). | Global-Privacy-Platform/Sections/Section Information.md — Reusable Subsections / Global Privacy Control (GPC) |
| Google AC | bypasses (outside the container)CMP JS API __gpp() __tcfapi() | Additional Consent is not a GPP section: addtl_consent travels in the TCData returned by __tcfapi, as a Google-side convention. | — |
| DSA 承载约定 | bypasses (outside the container)OpenRTB ext regs.ext.dsa bid.ext.dsa | DSA transparency info travels in OpenRTB ext slots (regs.ext.dsa on the request side, bid.ext.dsa returned by the DSP); it is not part of the OpenRTB 2.6 core fields, and this site's OpenRTB data model does not model ext sub-fields either. | — |
Current status at a glance
Confirm a signal is still alive before implementing it — this domain has an unusual number of deprecated and deprecating standards. An entry marked “pending evidence” has no official source on this site for whether it is still alive, so nothing is asserted about it.
| Signal | GPP section | Type | Status | Key date | Publisher |
|---|---|---|---|---|---|
| TCF EU v2The current baseline is Final v.2.2 with the rolling 2.3 and 2.4 revisions; 2.4 has no released version and must not be cited as one. | §2 | consent | current | 2025-04（TCF 2.3：DisclosedVendors 段强制） | IAB Europe |
| Canadian TCFThe official repo also ships a TCF EU / TCF CA comparison document, usable as the diff material for section 7 of its chapter. This site's decoder only reads the leading Version field for this section. | §5 | consent | current | — | IAB Canada |
| USPrivacy StringFour plaintext characters (version · explicitNotice · optOutSale · lspaCoveredTransaction), not base64-encoded — a ready-made counter-example to the assumption that section payloads must be bit-encoded. Legacy traffic and some platform parameters still pass it directly, so it is honestly kept for debugging. | §6 | opt-out | deprecated | 2023-09-30 停止支持 · 2024-01 由 GPP §6 承接 | IAB Tech Lab |
| MSPA US National (§7)The consumer-facing Notice / Opt-Out scalar fields use Int(2) three-valued semantics (0 not applicable / 1 yes / 2 no), not booleans, while SensitiveDataProcessing is an N-Bitfield(2,16) rather than an Int(2). Notice and Opt-Out fields are bound by cross-field validity constraints (e.g. SaleOptOut=0 requires that SaleOptOutNotice was not provided). Three further Int(2) mode fields — MspaCoveredTransaction, MspaOptOutOptionMode and MspaServiceProviderMode — describe a party's contracting status and belong to a different dimension from the consumer-facing ones.upstream inconsistencyUS National v2.0 (2024-10) declares support for MI (Michigan), but the GPP Section registry has no section ID for MI — that state can only be expressed via US National §7, with no discrete section. | §7 | opt-out | current | 2022-12 v1.0 · 2024-10 v2.0 | IAB Tech LabContracting entity · IAB Privacy, Inc. |
| US state sections (§8–27, 20 in total)Each state has its own technical specification; the field set is a subset of US National and the N-Bitfield parameters differ per state (California, for instance, uses N-Bitfield(2,9) rather than (2,16)), so no single bit layout can be shared. The registry's 20 state sections do not coincide with the 14-state list behind v2.0: MI in that list has no section of its own (it is expressed only via §7), while seven states outside the list — CA, CO, CT, UT, VA, FL and MN — each have one. The official Section Information.md lists only state names for IDs 8–27; this site resolves the spec links by the Sections/US-States/<ST>/ convention.upstream inconsistencyTexas's document is named differently from the other states (IAB Privacy's Texas Privacy Technical Specification.md rather than GPP Extension: Texas …), so batch extraction cannot rely on a single filename pattern. | §8–27 | opt-out | current | — | IAB Tech LabContracting entity · IAB Privacy, Inc. |
| Standalone TC string (outside the GPP container)Two carriage forms of the same payload as §2, not two signals: a leading C means no GPP container. The EEA spec states that until IAB Europe officially deprecates it, the standalone TC string must still be included in transaction headers, the TCF API must be implemented, and vendors must interpret it for all GDPR-applicable transactions — so it coexists with GPP §2 rather than being superseded. This site's decoder supports it (the tcf-eu branch of classifyPrivacyString). | — | consent | current | — | IAB Europe |
| Google Additional Consentaddtl_consent travels in the TCData returned by __tcfapi and is not a GPP section. A Google-side convention whose licensing chain differs from the IAB specs already collected here, so it needs its own sourcing effort; whether it is sunsetting must likewise come from Google's own documentation. This site asserts nothing here, so the status is recorded as pending evidence rather than sunset. | — | consent | pending evidence | — | |
| Global Privacy ControlDual identity: natively the Sec-GPC request header (value 1, or the header omitted entirely; the official spec defines no 0) and navigator.globalPrivacyControl (true/false), bypassing the GPP container; within GPP it is the first officially listed Reusable Subsection (SubsectionType Int(2)=1, payload a single Boolean), attachable to any section. This site's decoder does not currently parse the GPC subsection. | — | opt-out | current | — | W3C Web Privacy Community Group & browser vendors |
| DSA transparency (regs.ext.dsa / bid.ext.dsa)A disclosure signal — neither consent nor opt-out — so its validation rules and invalid forms differ entirely from the consent family. The legislation is the EU DSA; the carriage convention is defined by IAB Tech Lab. Not part of the OpenRTB 2.6 core fields, and this site's OpenRTB field model cannot nest ext sub-fields, so the data must be built on the Privacy side and linked to the existing #regs-ext / #bid-ext anchors. | — | disclosure | current | — | IAB Tech Lab |
Who owns what
Privacy is a domain where several standards bodies overlap: before reading any document, work out which body to trust for which question. Most publishers below are IAB regional branches; GPC's native form is advanced by the World Wide Web Consortium (W3C) Web Privacy Community Group together with browser vendors. Note that the MSPA contracting entity and the publisher of its technical specifications are not the same organisation.
| Publisher | Owns | License |
|---|---|---|
| IAB Tech Lab ↗ |
| CC-BY 3.0 (IAB Tech Lab) |
| IAB Europe ↗ |
| CC-BY 3.0 (IAB Tech Lab) / IAB Europe |
| IAB Canada ↗ |
| — |
| IAB Privacy, Inc. ↗The MSPA contracting entity is IAB Privacy, Inc., while the section technical specifications are published by IAB Tech Lab — two distinct entities that must not be conflated when citing. |
| — |
| Google ↗ |
| — |
| W3C Web Privacy Community Group & browser vendors ↗ |
| — |
Core terms
No privacy specification can be read without these dozen-odd words. Several of them do not mean the same thing across standards, and the definitions say so where that is the case.
Consent
Permission given by the data subject for a processing purpose. In the TCF it is expressed as two bitfields — PurposesConsent by purpose and VendorConsents by vendor. It is a different legal basis from Legitimate Interest, whose legal rationale this site does not interpret.
Purpose
The TCF's division of processing activities, numbered 1–24: 1–11 carry official names (11 added in TCF 2.2), 12–24 are reserved. Both consent and legitimate interest are recorded per Purpose.
Special Feature
Two TCF features requiring a separate opt-in: 1 use precise geolocation data, 2 actively scan device characteristics for identification. Carried in the TC String core segment as the SpecialFeatureOptIns bitfield (12 bits wide, only the first 2 meaningful).
Vendor
A processor registered in the GVL and participating in the ad chain. The TCF records its legal basis per vendor ID in two variable-length sections, VendorConsents and VendorLI; the IDs come from the GVL.
CMPConsent Management Platform
Consent Management Platform. It produces and exposes privacy strings in the browser (via the __gpp() / __tcfapi() queues); its ID and version are written into the TC String's CmpId / CmpVersion fields.
Section
An independent payload within a GPP string carrying one signal, delimited by ~ and declared by ID in the Header. The official registry currently spans IDs 1–27; each section's bit layout is defined by its own specification, not by GPP.
SIDgpp_sid
The section IDs applicable to this transaction. An integer[] as regs.gpp_sid in OpenRTB, but a string as the ${GPP_SID} URL macro — one semantics, two types. Usually a single value; section 3 (Header) and 4 (Signal Integrity) should not appear in it.
MSPAMulti-State Privacy Agreement
The Multi-State Privacy Agreement. Its contracting entity is IAB Privacy, Inc. while the technical specifications are published by IAB Tech Lab — two distinct entities that must not be conflated. Technically it materialises as GPP sections 7 (US National) and 8–27 (the states).
LSPALimited Service Provider Agreement
The IAB Limited Service Provider Agreement. The fourth character of the USPrivacy String, lspaCoveredTransaction, marks whether the transaction is covered by it (Y/N).
GVLGlobal Vendor List
The Global Vendor List maintained by IAB Europe. The TC String's VendorListVersion field records the version used; Vendor and CMP IDs come from it. This site has not yet collected the GVL schema or vendor data.
GPCGlobal Privacy Control
Two forms: natively the Sec-GPC request header (0/1) and navigator.globalPrivacyControl (true/false), advanced by the W3C Web Privacy CG and browser vendors; within GPP it is the first officially listed Reusable Subsection, attachable to any section.
Reusable Subsection
GPP's horizontal extension mechanism: a new signal starts as a subsection attached to any section with the . delimiter and may be promoted to its own section ID as adoption grows; self-identified by SubsectionType Int(2) (0 Core / 1 GPC). Availability is defined by each section's own document. Note that TCF EU (§2) does not use this mechanism — it uses the TCF-native Segment (SegmentType Int(3)): the same . delimiter carries two different self-identification schemes.
Suggested reading path
To understand the domain systematically, read in this order: container → encoding primitives → one concrete signal → carriage → decode something real. Steps marked “not built yet” are not live and will follow.
- 1The GPP container: string composition and the Header
- 2Encoding primitives: how to read Int / Fibonacci / Bitfield / N-Bitfield
- 3One concrete signal: the bit layout of TCF EU's TC String
- 4Opt-out signals: MSPA US National's three-valued field model
- 5Carriage: OpenRTB fields, URL macros and the CMP API
- 6Hands on: decode a real string