GPP, MSPA & US State Signals: A Publisher's Guide

The signal you built for CCPA is being phased out

If your ad stack still passes a US Privacy String like 1YNN, you're speaking a language the industry has moved off. On January 31, 2024, the IAB Tech Lab deprecated the US Privacy String and pointed publishers to the Global Privacy Platform instead. The old string only ever encoded the original 2020 CCPA signal. It has no way to represent Virginia, Colorado, Connecticut, Utah, or the dozen states that have since passed opt-out laws, each with its own wrinkles.

For publishers this isn't a nice-to-have migration. The privacy signal is what tells every SSP and bidder in your auction whether a given impression can be monetized with targeted demand. Send the wrong signal, or no signal, and you either leak compliance risk downstream or watch your CPMs collapse as buyers treat the impression as non-consented. This guide covers what GPP is, the MSPA trap sitting inside it, and how the signal actually travels.

GPP is one envelope for many signals

The Global Privacy Platform (GPP) is an IAB Tech Lab protocol that carries privacy, consent, and opt-out signals from your site or app to every ad tech vendor downstream. Think of it as an envelope. Inside, it holds one or more sections, each a self-contained string for a specific regime.

A single GPP string can carry the EU TCF signal, the Canadian TCF signal, a US National section, and any number of US state sections at once. Your CMP builds the envelope, sets the applicable sections based on where the visitor is, and exposes it through a JavaScript API called __gpp(), the direct successor to the __tcfapi() and __uspapi() calls your vendors already know how to read. The Global Privacy Working Group finalized GPP implementation guidelines in February 2025, so the spec is settled, not moving under you.

If you already run TCF 2.2 for European traffic, GPP is the layer that lets one CMP speak both the EU and the US dialects. See our TCF 2.2 implementation walkthrough for the European half.

The US National string and the MSPA trap

The headline US section is usnat, the US National string (section ID 7). It's designed to signal compliance across multiple state laws at once, which sounds like exactly what a national publisher wants. There's a catch that trips people up.

The US National string was built specifically to support the Multi-State Privacy Agreement (MSPA), IAB Privacy's contractual framework that allocates responsibilities among publishers, ad tech, and buyers under US state laws. Because of that, only MSPA signatories and their certified partners are supposed to send the usnat string. If you're not a signatory and you transmit it anyway, you're representing that you've agreed to obligations you actually haven't, which the IAB itself flags as a material misrepresentation risk.

So the decision tree is real: either join the MSPA and use the US National string, or don't join and signal through the individual US state sections instead. Pick deliberately. Don't let a CMP default emit usnat for you if you never signed the MSPA.

The US state sections

Where the national string doesn't fit, GPP provides per-state sections that encode the specifics of each law. The core set maps to the states with active opt-out regimes:

• usca (section 8), California, CCPA/CPRA
• usva (section 9), Virginia
• usco (section 10), Colorado
• usut (section 11), Utah
• usct (section 12), Connecticut

Each section carries the fields that state cares about: sale opt-out, sharing/targeted-advertising opt-out, sensitive-data handling, and whether a universal opt-out preference (like Global Privacy Control) was detected. Your CMP resolves which section applies from the visitor's state and encodes the visitor's choices into it. For the underlying legal obligations these strings represent, see our complete guide to US state privacy laws.

How the signal moves through the ad stack

The value of GPP is only realized if the string reaches the auction. The path looks like this:

1. The CMP sets the string. On page load it determines applicable sections, reads the visitor's choices (and any GPC signal), and encodes a GPP string exposed via __gpp().
2. Header bidding reads it. Prebid.js has first-class support for the US signals. Its MSPA/usnat activity controls read the GPP string and gate bidder and vendor activity accordingly, so a visitor who opted out isn't handed to demand that shouldn't see them.
3. SSPs and bidders consume it. The GPP string travels in the bid request, and each downstream vendor applies its own obligations under the section that's set.
4. Google Ad Manager reads it too. Per Google's Ad Manager documentation, GAM consumes GPP, and starting September 2025 it supports GPP National v2 alongside v1. Google continues to read the legacy US Privacy String for now, but GPP is the recommended path forward.

The failure mode to watch: a CMP that sets a beautiful GPP string the browser never passes into Prebid or the ad server. If the string isn't wired into the auction, it's decoration. Test that a bid request actually carries it.

Universal opt-out signals feed the string

US state laws increasingly require honoring a browser-level opt-out preference, most concretely Global Privacy Control (GPC). When a visitor arrives with GPC enabled, your CMP has to treat that as an opt-out of sale and sharing and reflect it in the relevant GPP section and act on it, not log it and move on. Ignoring GPC is one of the more enforced failures in US privacy right now. We cover the mechanics in universal opt-out mechanisms and Global Privacy Control explained.

What publishers should actually do

1. Retire reliance on the US Privacy String. It was deprecated in January 2024. Keep it only for legacy compatibility, and move your compliance logic to GPP.
2. Decide on the MSPA. Signatory means you can use the US National string; non-signatory means use the state sections. Make sure your CMP config matches the choice you actually made.
3. Verify the string reaches the auction. Inspect a live bid request and confirm the GPP string is present in Prebid and in your ad server's requests.
4. Wire GPC into the sections. A GPC visitor must show up as opted out in the encoded string.
5. Keep the EU and US paths in one CMP. Running TCF for Europe and GPP for the US from separate tools is how strings get dropped at the boundary. One CMP, one envelope.

For the revenue side of these tradeoffs, see cookie consent and publisher ad revenue, and for the Google-side requirements, the Certified CMP requirement.

How CookieBeam handles GPP and US signals

Native GPP support. CookieBeam ships a GPP runtime that exposes the standard __gpp() CMP API, encodes the US National section (usnat) and the US state sections (usca, usva, usco, usut, usct), and keeps legacy __uspapi compatibility for vendors still reading the old signal during the transition.

Section resolution by visitor location. CookieBeam determines which section applies from the visitor's state and encodes their choices, including a detected GPC signal, into the right section automatically.

TCF and GPP from one deployment. The same CMP handles TCF 2.2 for European traffic and GPP for US traffic, so the envelope stays intact across the EU/US boundary instead of two tools dropping strings between them.

Consent logging. Every choice is recorded with timestamp and jurisdiction (consent logging and audit requirements), the record you'll want if a state attorney general or an ad-tech partner ever asks what signal you sent for a given impression.

The publishers who came through the US Privacy String deprecation cleanly did one thing: they stopped treating the US as a single "CCPA" checkbox and started treating it as a stack of state signals riding in one GPP envelope, wired end to end into the auction.