Implementing IAB Global Privacy Protocol (GPP) Across Web, In-App, and CTV Inventories

In OpenRTB 2.6 bid requests, the regs.gpp string and regs.gpp_sid integer array supersede legacy privacy extensions such as regs.ext.us_privacy and user.ext.consent. When a publisher's supply path fails to populate these native fields or transmits a header mismatch between the encoded consent string and the declared Section ID array, tier-1 demand-side platforms (DSPs) systematically throttle or drop the incoming QPS before auction evaluation. Across North American and European programmatic exchanges, missing or malformed privacy payloads reduce effective bid density by 35% to 60% on affected impressions, forcing inventory to clear through lower-yield contextual fallback tiers or go unfilled entirely.

For multi-platform publishers operating across Web, Mobile In-App, and Connected TV (CTV), privacy signal transmission is no longer a localized tag management task. Regulatory fragmentation across European Economic Area (EEA) jurisdictions and nearly twenty distinct US state privacy statutes requires a unified transport layer capable of encoding heterogeneous legal frameworks into a compact, bitwise-parsable payload. Executing this architecture without introducing client-side main-thread latency, mobile SDK memory leaks, or Server-Side Ad Insertion (SSAI) macro truncation requires strict alignment between Consent Management Platforms (CMPs), header bidding wrappers, and SSP endpoint validators.

At Sky Boosts, our engineering teams inspect millions of bid requests per second across Prebid.js 11.x, Prebid Server, Google Ad Manager (GAM) MCM, and direct OpenRTB 2.6 pipes. Implementing the Global Privacy Protocol properly protects publisher yield while maintaining airtight statutory compliance across every device environment.

From Platform to Protocol: How the IAB Global Privacy Protocol (GPP) Standardizes Consent

Prior to the consolidation of programmatic privacy standards, ad tech infrastructure relied on isolated, jurisdiction-specific payloads. European traffic utilized the Transparency and Consent Framework (TCF) passed inside user.ext.consent, while California traffic relied on the four-character us_privacy string (1YNN) passed inside regs.ext.us_privacy. As additional US states enacted comprehensive consumer privacy legislation with divergent definitions of sensitive personal data, profiling, and juvenile opt-in thresholds, the static four-character schema became mathematically incapable of representing the required legal signals. Maintaining separate OpenRTB extension fields for every new jurisdiction would have bloated bid request payloads and fractured DSP parsing logic.

To resolve this structural bottleneck, the IAB Tech Lab Global Privacy Protocol formally transitioned its nomenclature from the "Global Privacy Platform" to the "Global Privacy Protocol", deprecating the legacy CCPA US Privacy string in January 2024. The protocol establishes a single extensible container format that encapsulates multiple regional consent frameworks inside one tilde-delimited (~), base64url-encoded bitstream. Rather than requiring SSPs and DSPs to inspect dozens of disparate JSON extensions, the protocol pairs the unified string (regs.gpp) with an explicit array of active Section IDs (regs.gpp_sid), allowing downstream bidding engines to immediately identify which regulatory rules govern the current impression.

Supporting this unified architecture across Web, Mobile App, and CTV inventories requires adapting the protocol's storage and retrieval mechanics to the runtime constraints of each medium:

• Web Environments (Desktop and Mobile Web): The browser relies on the JavaScript __gpp() stub API exposed on the window object. Prebid.js 11.x and Google Publisher Tag (GPT) query this synchronous/asynchronous command queue during auction initialization, reading the active string and passing it to client-side bid adapters and Prebid Server endpoints.
• Mobile In-App Environments (iOS and Android): Because native applications lack a global window object, the CMP SDK writes resolved GPP values directly to native local storage (NSUserDefaults on iOS and SharedPreferences on Android) using standardized IABGPP_* keys. Mediation layers, Prebid Mobile SDK, and Google Mobile Ads (GMA) Next-Gen SDK observe these storage keys and attach the values to outbound ad requests.
• Connected TV and SSAI Environments: CTV applications running on tvOS, Roku (BrightScript), Samsung Tizen, or LG webOS lack standard browser cookies and often delegate ad fetching to an intermediate SSAI stitcher. The client application must capture user consent via a native CTV CMP interface or device-level registry, construct the GPP string, and pass both the encoded payload and the active Section IDs via URL query macros ([GPP_STRING] and [GPP_SID]) to the SSAI proxy, which in turn populates the server-to-server OpenRTB 2.6 request.

Embedding this multi-environment taxonomy directly into our privacy and compliance approach ensures that every impression monetized through our network carries verifiable, machine-readable consent metadata regardless of whether the request originates from a Chromium browser, an iOS gaming app, or a server-stitched FAST channel.

Decoding the GPP Section ID Architecture and 2025/2026 US State Additions

At the binary level, a GPP string is a modular bitstream composed of a mandatory header section followed by one or more jurisdiction-specific payload sections separated by the tilde (~) character. Every valid GPP string begins with the base64url character D, which represents the 6-bit integer 3 (binary 000011), designating the fixed GPP header type. Immediately following the type identifier are the protocol version (6 bits) and a Fibonacci-encoded integer range list that declares every Section ID present inside the string.

By encoding active section identifiers in the header using Fibonacci compression, a parser can determine all applicable regulatory regimes within the first few bytes of the string before splitting the tilde-delimited segments. When an SSP receives an OpenRTB request containing regs.gpp: "DBACNYA~CPXxRfAPXxRfAAfkabENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN", the edge validator decodes DBACNYA to verify that Section 2 (EU TCF v2.2) and Section 6 (legacy USP v1) are declared in the header, and then cross-checks that result against the integer array provided in regs.gpp_sid: [2, 6].

If a publisher's CMP appends a state section to the string without updating the Fibonacci header, or if an ad server macro passes regs.gpp_sid as a stringified comma list ("7,8") instead of a native JSON integer array ([7, 8]), strict DSP schema validators reject the bid request as non-compliant. Furthermore, keeping the bitstream compressed ensures that even when a publisher concatenates multiple regional strings for cross-border redundancy, the total HTTP payload overhead remains under 150 bytes, preventing URL truncation in GET-based VAST 4.3 calls.

EU TCF v2.2 (Section 2), MSPA US National, and Finalized State Strings (CA, VA, CO, CT, MN, MD, IN, KY, RI)

The GPP registry assigns a unique numeric Section ID and standardized API prefix to each jurisdiction. Understanding how DSPs evaluate these sections is critical when configuring CMP geo-targeting rules and fallback logic:

Section ID	API Prefix	Jurisdiction / Regulatory Framework	Bitfield Granularity & Key Signals
2	tcfeuv2	EU TCF v2.2 (EEA & UK)	Vendor consents, legitimate interest disclosures, special features, and publisher restrictions.
5	tcfca	Canada TCF	Canadian PIPEDA / Quebec Law 25 consent and disclosure bitfields.
6	uspv1	Legacy US Privacy (Deprecated)	4-character string (1YNN). Deprecated Jan 2024; kept only for legacy DSP backward compatibility.
7	usnat	MSPA US National	Unified Multi-State Privacy Agreement baseline covering sale, sharing, targeted ads, and sensitive data.
8 - 12	usca, usva, usco, usut, usct	First-Wave US States (CA, VA, CO, UT, CT)	State-specific notices, opt-out of sale/sharing/targeted advertising, and sensitive data array bits.
13 - 22	usfl, usmt, usor, ustx, usde, usia, usne, usnh, usnj, ustn	Second-Wave US States (FL, MT, OR, TX, DE, IA, NE, NH, NJ, TN)	Expanded state-level sensitive data flags, adolescent consent tiers (ages 13-16 / 13-17), and profiling bits.
23+	usmn, usmd, usin, usky, usri	2025/2026 Finalized US States (MN, MD, IN, KY, RI)	Newly finalized state strings addressing strict data minimization, profiling opt-outs, and August 2026 MSPA alignment.

As US state privacy legislation expanded beyond the initial five states (California, Virginia, Colorado, Utah, and Connecticut), the IAB Tech Lab finalized new US State strings in late 2025 and 2026 for Minnesota (usmn), Maryland (usmd), Indiana (usin), Kentucky (usky), and Rhode Island (usri), alongside an August 2026 update for the Multi-State Privacy Agreement (MSPA) and CMP API v1.1. These recent state additions reflect increasingly nuanced statutory requirements. For example, Maryland's Online Data Privacy Act enforces strict data minimization standards that restrict the collection and processing of sensitive data irrespective of consumer opt-in, while Minnesota's statute introduces specific rights regarding automated profiling in furtherance of consequential decisions.

Publishers configuring their CMPs face a critical architectural choice for US domestic traffic: transmitting individual state-specific strings based on the user's geo-IP location (usca, usva, usmn, usmd, etc.) versus applying the unified MSPA US National (usnat, Section 7) string across all fifty states. While usnat simplifies CMP tag logic by applying a "highest common denominator" privacy baseline nationwide, doing so treats every US user under the strictest combined interpretation of sensitive data and minor consent rules. Conversely, dynamic geo-IP routing serves the exact state section (regs.gpp_sid: [8] for a California user, or the respective state ID for a user in Indiana, Kentucky, or Rhode Island) and maximizes addressable yield in states without restrictive opt-out mandates. Through our publisher solutions, our AdOps engineers help media owners audit their geo-IP consent routing so that regional traffic transmits the exact Section ID expected by tier-1 buyers without over-restricting national addressability.

Passing regs.gpp and regs.gpp_sid in OpenRTB 2.6

In OpenRTB 2.6, the Regs object natively incorporates gpp (string) and gpp_sid (array of integers). When communicating with legacy DSP endpoints still operating on OpenRTB 2.5, SSPs must duplicate these values inside regs.ext.gpp and regs.ext.gpp_sid to ensure seamless ingestion.

In web environments running Prebid.js 11.x, the consentManagement module must be explicitly configured to query the __gpp API and enforce auction delay thresholds cleanly. If the CMP fails to respond before the timeout window expires, the wrapper proceeds without a valid GPP payload, causing downstream SSPs to strip user identifiers (user.buyeruid, user.ext.eids) to prevent unauthorized personal data processing.

// Production Prebid.js 11.x GPP Configuration with Activity Controls
pbjs.setConfig({
  consentManagement: {
    gpp: {
      cmpApi: 'iab',
      timeout: 150, // Balanced timeout: prevents main-thread starvation when CMP is cached
      actionTimeout: 10000 // Wait window when user interaction with UI banner is required
    }
  },
  // Prebid 11.x Activity Controls: Enforce UFPD (User First-Party Data) and EID filtering
  activities: {
    transmitUfpd: {
      rules: [{
        condition: (context) => {
          const gppData = pbjs.getConsentMetadata()?.gpp;
          return Boolean(gppData && Array.isArray(gppData.applicableSections) && gppData.applicableSections.length > 0);
        },
        allow: true
      }]
    }
  }
});

Once Prebid.js or Prebid Server constructs the outbound OpenRTB 2.6 request, the regs object must present a strictly typed integer array for gpp_sid alongside the tilde-delimited string:

{
  "id": "80ce30c53c16e",
  "imp": [
    {
      "id": "1",
      "video": {
        "mimes": ["video/mp4"],
        "minduration": 5,
        "maxduration": 30,
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "plcmt": 1
      },
      "bidfloor": 14.50,
      "bidfloorcur": "USD"
    }
  ],
  "regs": {
    "coppa": 0,
    "gpp": "DBACNYA~BVoIgACgA.QA~BVoIgACgA",
    "gpp_sid": [7, 8]
  }
}

For Mobile In-App developers, the IAB Tech Lab specification mandates storing GPP signals in device-level persistent dictionaries (SharedPreferences on Android and NSUserDefaults on iOS). Unlike the JSON integer array used in OpenRTB, the mobile storage specification requires the active section IDs to be stored in IABGPP_GppSID as an underscore-delimited string (for example, "7_8"). The mobile advertising SDK or Prebid Mobile wrapper must read IABGPP_HDR_GppString and split IABGPP_GppSID on the underscore delimiter to cast each token into a 32-bit integer before serializing the OpenRTB regs.gpp_sid array. Failing to convert "7_8" into [7, 8] is one of the most common causes of schema validation failures on mobile app inventory.

In Connected TV environments utilizing Server-Side Ad Insertion (SSAI) or VAST 4.3 ad tags, the client application passes the GPP parameters to the stitcher or ad server via standardized URL macros:

https://ads.skyboosts.com/vast?iu=/218000/ctv_fast_stream&gpp=[GPP_STRING]&gpp_sid=[GPP_SID]&correlator=[TIMESTAMP]

Note that inside VAST URL macros, [GPP_SID] resolves to a comma-separated string of integers (such as gpp_sid=7,8). The SSAI stitcher or SSP endpoint must URL-decode the string, split on the comma, validate that each element is a positive integer matching the Fibonacci header of [GPP_STRING], and inject the resulting integer array into the downstream OpenRTB 2.6 bid request. Our unified monetization platform performs automated edge normalization across Web, SDK, and CTV VAST inflows, catching underscore-versus-comma formatting discrepancies before the request reaches DSP bidding pipes.

CMP API v1.1 Implementation and IAB Accountability Platform v1.0

On the client side, reliable consent transmission depends on the interaction between the publisher's ad tag wrapper and the CMP API. As part of the August 2026 update for the MSPA and CMP API v1.1, the IAB Tech Lab refined the __gpp() interface to eliminate asynchronous race conditions and clarify command execution states. Under CMP API v1.1, calling __gpp('ping', callback) or registering a listener via __gpp('addEventListener', callback) returns a structured PingReturn object containing gppVersion ("1.1"), cmpStatus ("stub", "loading", "loaded", or "error"), cmpDisplayStatus ("hidden", "visible", or "disabled"), signalStatus ("not ready" or "ready"), supportedAPIs, and applicableSections.

A frequent production failure occurs when publishers trigger their Prebid.js and GAM auction call immediately upon cmpStatus === 'loaded' rather than waiting for signalStatus === 'ready'. When a new user arrives on page and the CMP UI banner is visible (cmpDisplayStatus === 'visible'), the CMP library is loaded in memory, but the user has not yet made a consent choice in opt-in jurisdictions (such as EEA Section 2), leaving signalStatus as "not ready". Firing the auction before signalStatus transitions to "ready" causes applicableSections to return [-1] or [0], stripping personalized demand from the initial pageview.

Below is a production-grade JavaScript orchestrator that safely gates programmatic auction initialization on the CMP API v1.1 signalStatus transition while enforcing a hard fallback ceiling so ad rendering never hangs indefinitely if a third-party CMP script fails:

(function orchestrateGppAuction() {
  let auctionDispatched = false;
  const HARD_FAILSAFE_MS = 600;

  function triggerProgrammaticStack(gppPingData) {
    if (auctionDispatched) return;
    auctionDispatched = true;

    window.googletag = window.googletag || { cmd: [] };
    window.pbjs = window.pbjs || { que: [] };

    pbjs.que.push(function() {
      pbjs.requestBids({
        bidsBackHandler: function() {
          pbjs.setTargetingForGPTAsync();
          googletag.cmd.push(function() {
            googletag.pubads().refresh();
          });
        }
      });
    });
  }

  const failsafeTimer = setTimeout(function() {
    triggerProgrammaticStack(null);
  }, HARD_FAILSAFE_MS);

  if (typeof window.__gpp === 'function') {
    window.__gpp('addEventListener', function(evt, success) {
      if (!success || !evt || !evt.pingData) return;
      if (evt.pingData.signalStatus === 'ready') {
        clearTimeout(failsafeTimer);
        triggerProgrammaticStack(evt.pingData);
      }
    });
  } else {
    clearTimeout(failsafeTimer);
    triggerProgrammaticStack(null);
  }
})();

Beyond technical ingestion, verifying that downstream intermediaries honor user choices is now subject to cryptographic and log-level scrutiny. In November 2024, the IAB Tech Lab finalized the Accountability Platform v1.0 specification to audit and verify accurate transmission of GPP consumer consent signals across the programmatic supply chain. Previously, once a publisher generated a GPP string, there was no standardized mechanism to prove that every SSP, ad exchange, and DSP in the auction graph preserved those exact bitfields without mutation or truncation.

The Accountability Platform v1.0 specification addresses this gap by defining a standardized data schema and sampling methodology for consent transaction logs. Participating supply-side and demand-side platforms record immutable audit records linking transaction IDs, timestamps, incoming GPP strings, outgoing GPP strings, and the specific data-processing actions taken (such as whether user IDs were scrubbed or targeted advertising bids were suppressed when an opt-out bit was set). Independent auditing entities and regulatory compliance monitors can compare publisher-side CMP emission logs against SSP and DSP ingestion logs to detect signal loss or unauthorized personal data transmission across hops.

To ensure full readiness for the August 2026 MSPA and CMP API v1.1 milestones as well as Accountability Platform v1.0 auditing, publisher engineering and AdOps teams should execute a four-point verification checklist across their inventory:

1. Audit gpp_sid and Header Parity: Verify via real-time network inspection that every outbound OpenRTB 2.6 bid request carries regs.gpp_sid as a native JSON integer array whose values exactly match the Fibonacci-encoded section list inside the regs.gpp header.
2. Verify 2025/2026 US State Coverage: Confirm that your CMP vendor supports and actively encodes the newly finalized US state strings (Minnesota, Maryland, Indiana, Kentucky, and Rhode Island) or applies the updated August 2026 MSPA usnat Section 7 string appropriately based on your legal counsel's geo-routing rules.
3. Normalize Mobile and CTV Delimiters: Ensure that native app mediation layers convert underscore-delimited IABGPP_GppSID storage values ("7_8") and CTV SSAI stitchers convert comma-delimited VAST macro values ("7,8") into valid OpenRTB integer arrays ([7, 8]) prior to auction dispatch.
4. Gate Auctions on signalStatus: "ready": Upgrade web wrappers to CMP API v1.1 event listeners that evaluate pingData.signalStatus === 'ready' rather than cmpStatus === 'loaded', eliminating race conditions that drop first-impression consent strings and degrade programmatic yield.