IAB Global Privacy Platform (GPP): The Complete Guide for Publishers in 2026
For years, publishers and ad tech vendors have juggled an ever-growing stack of consent strings: the TCF v2.2 string for European traffic, the US Privacy (USP) string for California, plus ad-hoc GPC flags and vendor-specific signals for every new state law. The IAB Global Privacy Platform (GPP) collapses that mess into a single encoded header that carries every jurisdiction's consent status at once. By 2026, GPP is no longer optional — Google Ad Manager, major SSPs, and leading CMPs now require GPP support for US state privacy signals, and the TCF-only era is effectively over for any publisher monetizing across borders.
What the Global Privacy Platform actually is
GPP is a transport protocol, not a new consent framework. It is a container that encodes multiple region-specific consent signals into one Base64 string, exposed through a standard JavaScript API (__gpp()) that SSPs, DSPs, and measurement vendors can query. Each region has its own section inside the GPP string: Section 2 carries TCF EU v2, Section 6 carries US Privacy (deprecated), Section 7 covers USNat, and Sections 8 through 12 cover California, Virginia, Colorado, Utah, and Connecticut respectively. Additional sections for Texas, Oregon, Montana, and other states are being added as their laws take effect.
The key design choice is that a single GPP string can carry multiple sections simultaneously. A European visitor gets TCF EU data; a California visitor gets US-CA data; a user whose IP geolocates to both jurisdictions (rare but possible via VPN) can have both sections populated. Ad tech vendors read only the sections relevant to them and ignore the rest.
Why GPP exists and why it matters now
Before GPP, every new US state privacy law forced publishers to implement yet another signal. California had USP. Virginia's VCDPA required different opt-out semantics. Colorado's CPA recognised the Global Privacy Control browser signal. Utah and Connecticut each added more nuance. Ad tech vendors had to parse half a dozen formats, often inconsistently, and the risk of signalling "user consented" in one channel while the user had opted out in another became a real compliance exposure.
GPP standardises the transport. Once a CMP sets the GPP string, every downstream vendor reads the same encoding. For publishers, this matters for three reasons: Google's 2024 policy now requires GPP support for US state signals on Google Ad Manager inventory; Prebid.js 8.x and most major SSP adapters expect GPP; and regulators increasingly reference GPP compliance as evidence of good-faith signal propagation.
GPP sections and what they mean
Each GPP section has its own encoding rules, mirroring the underlying framework:
Section 2: TCF EU v2
Identical to the standalone TCF v2.2 string you already generate for European traffic. If your CMP is TCF-certified, you are already producing this section — GPP simply wraps it.
Section 7: US National (USNat)
The newest section, designed as a single signal covering all US federal and state privacy laws. It encodes notice given, sale opt-out, sharing opt-out, targeted advertising opt-out, sensitive data opt-out, and known-child data handling. Vendors operating across multiple US states should prefer USNat over the per-state sections when possible.
Sections 8-12: Per-state US signals
California (US-CA), Virginia (US-VA), Colorado (US-CO), Utah (US-UT), and Connecticut (US-CT). Each section carries fields specific to that state's law — for example, US-CA retains the older CCPA/CPRA sale and share opt-outs, while US-CO adds the sensitive data consent flag required by the Colorado Privacy Act. Texas (US-TX under CPA section 13) and Oregon (US-OR under CPA section 14) were added after their laws took effect in July 2024.
How publishers should migrate
Most publishers will already have a CMP generating TCF strings for EU traffic and USP strings for California. The migration path to GPP looks like this:
Step 1: Upgrade your CMP
Confirm your CMP vendor is listed on the IAB GPP-certified CMP list. FlexyConsent, OneTrust, Didomi, Sourcepoint, Usercentrics, and most Google-certified CMPs now produce valid GPP strings. If your CMP still outputs only TCF or USP, request a roadmap for GPP support — any vendor without a plan here will be left behind in 2026.
Step 2: Configure GPP sections by geography
Your CMP should automatically decide which GPP sections to populate based on IP geolocation. European visitors get Section 2 (TCF EU); US visitors get Section 7 (USNat) or per-state sections depending on how your vendor stack reads the signal. Do not populate every section for every visitor — that is a common misconfiguration that leaks jurisdiction-irrelevant data.
Step 3: Verify downstream propagation
The GPP string is only useful if SSPs, DSPs, analytics, and pixel vendors read it. Audit your ad stack: in Prebid.js, confirm the gppControl module is enabled; in Google Ad Manager, confirm the GPP string is being passed via the GAM consent API; in Google Analytics 4, confirm Consent Mode v2 is reading GPP alongside TCF. Any vendor that silently ignores GPP is a compliance gap.
GPP, Consent Mode v2, and Google's requirements
Google's December 2024 policy update made GPP support mandatory for publishers monetizing US inventory through Google Ad Manager. This change is subtle but important: Consent Mode v2 still uses its own ad_storage and analytics_storage signals, but GAM now expects the GPP string to be present in the ad request for any US state-law traffic. Missing or malformed GPP strings can result in ads being served in restricted mode — with significant fill and revenue impact — or, for repeat offenders, in inventory being excluded from auction.
The practical implication: even publishers who historically ignored US state laws because their revenue was California-only now need GPP. Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and Iowa all have laws in force as of 2026, and Google reads the GPP string to determine whether your ad request is compliant with each.
Common migration pitfalls
Four mistakes we see repeatedly when publishers add GPP:
Duplicate signals. Some publishers keep standalone TCF and USP strings alongside GPP, creating three sources of truth that can disagree. Once GPP is live, retire the standalone strings.
Wrong section population. Populating US-CA for every US visitor regardless of actual state leaks geography and can falsely claim CCPA opt-out rights for non-California residents. Use IP geolocation to pick the right section.
Ignoring GPC. The Global Privacy Control browser signal is not a GPP section — it is a separate HTTP header and JS property. Your CMP must read GPC on page load and reflect it as an opt-out in the relevant GPP sections, or you violate Colorado, Connecticut, and California law.
Stale vendor adapters. Older Prebid adapters and SSP integrations may strip the GPP string before it reaches the bidder. Test every vendor in your ad stack with the IAB GPP validator before declaring migration complete.
The long view: GPP beyond the US
GPP is designed to extend beyond TCF EU and US state laws. New sections for Canada (PIPEDA plus Quebec's Law 25), Brazil (LGPD), South Korea (PIPA), and other jurisdictions are under active IAB working group development. For publishers serving global inventory, GPP is becoming the single consent transport that replaces every regional protocol. Investing in GPP today positions your stack to absorb the next wave of regional privacy laws without another integration sprint.