Why GPP Problems Are Hard to Spot

When a US visitor opts out of the sale or sharing of their data, that choice has to reach every ad partner on the page. With the IAB Global Privacy Platform (GPP), it travels as a compact string and a list of section IDs. If either is wrong — missing, stale, or carrying the wrong section — nothing visibly breaks. Ads still load, the banner still looks fine, and the problem only shows up later as partners ignoring opt-outs or bidding less on your inventory.

The good news is that you can inspect almost everything from the browser console. This tutorial walks through the checks in the order we would run them on a live page.

Step 1: Confirm the API Exists and Is Ready

A GPP-compatible CMP exposes a global __gpp function. Open DevTools on your page and run a ping command:

__gpp('ping', function (data) { console.log(data); });

The returned object tells you a lot at a glance:

• gppVersion — should read 1.1 for current implementations.
• cmpStatus — whether the CMP has loaded or hit an error.
• cmpDisplayStatus — whether the banner is visible, hidden or disabled for this visitor.
• signalStatus — “ready” once the CMP has settled on a consent state, “not ready” while it is still deciding.
• supportedAPIs — the sections the CMP can produce.
• applicableSections — the section IDs that apply to this visitor right now.
• gppString — the encoded string itself.

If __gpp is undefined, the CMP stub is missing or loads too late. The stub must be in place before any ad script that expects it, otherwise those scripts will see no CMP and either wait or proceed without a signal.

Step 2: Check the Applicable Section

Each privacy framework in GPP has a numeric section ID. The ones publishers meet most often are 2 (EU TCF v2), 5 (Canadian TCF), 7 (US National, “usnat”) and 8 onwards for individual state sections such as California, Virginia, Colorado, Utah and Connecticut. A visitor from a US state should normally see either the national section or the relevant state section in applicableSections, not the EU section.

Test from several locations. A common bug is a CMP that detects geography correctly for the banner but writes a default section into the string regardless, or the reverse. Using a VPN or your CMP’s preview tools, compare what the banner shows with what applicableSections reports.

Step 3: Read the Section Data

Rather than decoding the string by hand, ask the CMP for the parsed section:

__gpp('getSection', function (data, success) { console.log(data, success); }, 'usnat');

In the US National section, the opt-out fields use a simple convention: 0 means not applicable, 1 means the user opted out, and 2 means the user did not opt out. Focus on these fields first:

• SaleOptOut and SharingOptOut
• TargetedAdvertisingOptOut
• The matching notice fields, which record whether the visitor was given notice of each practice

Now perform the opt-out on the page — click your “Do Not Sell or Share” link or toggle the setting in the preference centre — and run getSection again. The opt-out fields should flip from 2 to 1. If they do not, the UI and the signal are out of sync.

Step 4: Test the Global Privacy Control Path

Several state laws require businesses to treat a Global Privacy Control signal as an opt-out. Enable GPC in a browser or extension that supports it, confirm navigator.globalPrivacyControl returns true in the console, then load the page in a fresh session. The relevant opt-out fields should already read 1 without the visitor touching the banner. Some sections also include a field indicating that the choice came from a GPC signal.

Step 5: Watch Events, Not Just Snapshots

Ad scripts should not read the string once at page load and forget it. Register a listener to see what partners see:

__gpp('addEventListener', function (evt) { console.log(evt.eventName, evt.pingData); });

You should observe events such as listenerRegistered, signalStatus and sectionChange. When the visitor changes a choice, a sectionChange event with an updated string should follow. If your header bidding wrapper or ad server integration only reads the string before signalStatus becomes “ready”, it may send an empty or outdated value.

Step 6: Follow the String Into Ad Requests

Finally, open the Network tab and filter for your ad requests. Many ad endpoints accept gpp and gpp_sid parameters (the string and the applicable section IDs). Check that:

1. both parameters are present on requests from US visitors;
2. the string matches the one returned by ping at the time of the request;
3. after an opt-out, subsequent requests carry the new string rather than a cached one.

If you use Prebid.js, confirm that its consent management module is configured for GPP, and inspect the bid requests leaving the wrapper as well as the final ad server call.

Common Failure Patterns

• Stub loads after ad tags — partners see no CMP at all.
• Wrong section for the region — EU section sent for US traffic, or no section at all.
• UI and signal out of sync — the toggle changes, the string does not.
• GPC ignored — the browser signal never becomes an opt-out.
• Stale strings in requests — the wrapper caches the first value it saw.

Key Takeaways

• Start with ping: version, status, applicable sections and the string tell you most of the story.
• Use getSection to read opt-out fields; 1 means opted out, 2 means not opted out.
• Test the opt-out link and GPC separately and confirm both change the signal.
• Listen for events and wait for a “ready” signal before ad requests read the string.
• Verify gpp and gpp_sid in real network requests, before and after an opt-out.