Blog · Privacy
GPP keeps growing: new sections and what bid requests must carry
The Global Privacy Platform closed out 2025 by finalizing sections for Maryland, Indiana, Kentucky, and Rhode Island, with Indiana, Kentucky, and Rhode Island taking effect January 1, 2026. IAB Tech Lab has also said it will move to a biannual GPP release cycle starting this year. For anyone parsing regs.gpp, that means the set of section IDs a bidder needs to recognize is not fixed. It grows on a schedule now.
What regs.gpp and regs.gpp_sid actually carry
OpenRTB added GPP support in the 2.6-202211 update, promoting it to the Regs object alongside coppa, gdpr, and us_privacy. Two fields do the work:
regs.gpp(string): the encoded GPP consent string, which can bundle multiple regional sections into one value.regs.gpp_sid(integer array): the section ID or IDs of that string which apply to this transaction. Per the spec it will generally contain one and only one value, and sections 3 (Header) and 4 (Signal Integrity) do not need to be listed since they carry no consent state of their own.
The two fields only mean something together. regs.gpp without regs.gpp_sid is a string a bidder cannot interpret: there is no way to know which section governs the transaction, or whether a US state string sits next to an EU TCF string in the same value. Full field-level detail is on the privacy signals in OpenRTB doc.
The section list keeps getting longer
GPP assigns each privacy framework a numeric section ID, published in the Section Information file of the Global Privacy Platform repository. IDs 1 and 2 cover EU TCF, 5 covers the Canadian TCF, and 6 is the legacy US Privacy string. Everything from 7 upward is US state and national MSPA-based sections, and that range has been extending continuously since the first state sections (California, Virginia, Colorado, Utah, Connecticut) landed in 2023:
| Section ID | Section(s) | Note |
|---|---|---|
| 6 | US Privacy (uspv1) | Legacy CCPA string; deprecated by IAB Tech Lab |
| 7 | US National (usnat) | MSPA-based national baseline |
| 8-16 | California, Virginia, Colorado, Utah, Connecticut, Florida, Montana, Oregon, Texas | First wave of state sections, 2023-2024 |
| 17-22 | Delaware, Iowa, Nebraska, New Hampshire, New Jersey, Tennessee | Added through 2024 into 2025 |
| 23 | Minnesota (usmn) | Finalized after public comment, mid-2025 |
| 24 | Maryland (usmd) | Effective October 1, 2025 |
| 25-27 | Indiana, Kentucky, Rhode Island | Effective January 1, 2026 |
IAB Tech Lab has also announced a rearchitecture initiative for the US sections aimed at improving how supported and applicable sections are signaled, alongside the move to a biannual release cadence beginning in 2026. Treat the section list as a moving target, not a fixed enum: new state privacy laws keep arriving, and each one gets its own GPP section rather than being folded into an existing one.
The operational problem: parsing sections you have never seen
A bidder that hardcodes a switch statement over known gpp_sid values will eventually receive one it does not recognize, most likely from a state whose section went live after the code was last updated. That is not a hypothetical: it happened with Minnesota in mid-2025 and is happening again with Indiana, Kentucky, and Rhode Island in January 2026. The correct behavior is to treat an unrecognized section ID as "there is a privacy obligation here I do not understand" and default to the most conservative handling (no targeted advertising, no sale/share of data) rather than silently ignoring the signal or, worse, silently bidding as if no regulation applied.
The same logic applies upstream. Exchanges assembling the GPP string need to include the section IDs for every jurisdiction that actually applies to the request, not just the ones their consent management platform shipped support for last quarter.
Common mistakes in live traffic
- regs.gpp without regs.gpp_sid, or the reverse. Either half without the other is unusable, and rtblint flags a present
gppstring with an empty or missinggpp_sidarray. - Stale regs.us_privacy contradicting the GPP string. IAB Tech Lab deprecated the US Privacy signal on January 31, 2024, but plenty of pipelines still emit it out of inertia. When it disagrees with what the GPP string says for the same user, downstream systems have to pick a source of truth, and most will not pick the legacy one.
- Sending us_privacy alone with no GPP string at all for traffic that originates in a state with its own section (Colorado, Connecticut, and the rest). The legacy string was never designed to represent state-specific opt-out mechanics beyond California, so it cannot stand in for GPP no matter how current it is.
- Typing gpp_sid as a single integer instead of an array, or as a comma-separated string. The field is an integer array even when exactly one section applies.
What to check this week
Paste a sample bid request into the bid request tester to confirm regs.gpp and regs.gpp_sid are both present, correctly typed, and not contradicted by a stale regs.us_privacy value. The same checks run in CI through the Rust CLI. If your consent management platform added Maryland, Indiana, Kentucky, or Rhode Island support this cycle, confirm the corresponding section ID actually shows up in gpp_sid for traffic from those states rather than only in the encoded string. Field-level reference for every privacy path in a 2.6 request is on privacy signals in OpenRTB.