Role & classification

The registry of all 27 official Global Privacy Platform (GPP) Section IDs, rendered dynamically from the GitHub registry with no hard-coded upper bound; high-frequency sections (§2/§5/§6/§7/§8/§9/§10) can expand into payload summaries.

GPP section: §1–§27
Framework-level: §1–§7
US states: §8–§27 (20)
Field-level decoding: §2 (TCF EU) · §6 (USPrivacy)

String & field layout

Core sections (IDs 1–7)

ID	CMP API prefix	Name	Jurisdiction	Status
1	tcfeuv1	EU TCF v1 ↗	EU	deprecated
2	tcfeuv2	EU TCF v2 ↗decoded to field level here	EU/EEA	current
3	—	GPP Header ↗	—	required
4	—	GPP Signal Integrity ↗	—	reserved
5	tcfcav1	Canadian TCF ↗	CA	current
6	uspv1	USPrivacy String (Unencoded) ↗decoded to field level here	US	deprecated
7	usnat	MSPA US National ↗	US	current

US state sections (IDs 8–27, 20 in total)8–27

Each US state section has its own, structurally very similar bit layout; field-level decoding is not collected here yet. Expand for IDs, CMP API prefixes and official spec links.

Carriage & access

Which sections actually travel in a given transaction is declared by gpp_sid at the carriage point — regs.gpp_sid (an integer array) in OpenRTB, ${GPP_SID} (a string) in URL macros. §3 (the Header itself) and §4 (Signal Integrity) never appear in gpp_sid. gpp_sid semantics & multi-section use →

Version deltas

The registry evolves with the official Section Information.md; new sections are allocated IDs by the official registry, and this page renders without a hard-coded upper bound. This site's snapshot: 03fdf03 · 2026-08-31

Invalid forms

The Header's Sections list declares an ID outside the official registry (IDs 1–27)
The same section ID appears more than once in the string
The number of sections declared in the Header does not match the actual ~ segment count