The Global Privacy Platform (GPP)
A unified standard by IAB Tech Lab for communicating user consent and data preferences efficiently and consistently across diverse global regulatory environments.
What is GPP?
The Global Privacy Protocol (GPP) was developed by the IAB Tech Lab to help ecosystem participants support user choice and comply with consumer privacy regulations across diverse regulatory regimes. This includes harmonizing compliance for Europe (GDPR), Canada (PIPEDA), and the fragmented US state privacy landscape (like CCPA, VCDPA, etc.) through sections like the MSPA.
GPP maximizes interoperability by standardizing preference encoding and communication. It defines a transport layer that provides a common set of well-defined signals, ensuring all participants have a consistent, partnership-agnostic understanding of the user's choices.
Current API Version: GPP 1.1
Key Benefits for Digital Property Owners
Cost Reduction & Operational Efficiency
Substantially cut down expenses and minimize operational complexities involved in implementing and maintaining multiple, fragmented privacy technologies.
Enhanced Future Flexibility
Gain the agility to adapt seamlessly to new privacy requirements and emerging regulations without needing major system overhauls.
Simplified Global Compliance
Centralize compliance efforts by supporting diverse privacy formats and signals, encompassing TCF 2.2, MSPA, and US state-specific strings.
GPP and US State Compliance (MSPA)
The United States presents a complex challenge with numerous states enacting their own comprehensive privacy laws (e.g., CCPA/CPRA, VCDPA, CPA, CTDPA). These laws often have unique requirements for consumer opt-outs, consent, and data processing notices.
The Multi-State Privacy Agreement (MSPA)
The MSPA was developed as a contractual framework for the industry, providing a path for signatories to meet the highest common denominator of state privacy requirements through a single "US National" signal.
However, whether you use the MSPA's US National section or individual US State Specific sections, GPP is the essential technical layer that carries and standardizes these signals.
Why GPP is Required for US Compliance:
- Unified Transport: GPP acts as the central mechanism for encoding both the MSPA National string and all specific US state strings (sub-sections).
- Interoperability: It ensures vendors receive and interpret these diverse signals correctly, regardless of which state law applies to the user.
- Efficiency: Instead of maintaining separate APIs for each state or the MSPA, GPP provides one unified API for retrieving the applicable signals.
GPP Sections for US Privacy:
- MSPA/US National Section: Used by MSPA signatories to signal compliance across multiple states simultaneously.
- US State Specific Sections: Provides unique encoded strings for individual state laws (e.g., California, Virginia, Colorado) where specific nuances are required.
- Single API Call: All these necessary signals are made available to vendors through a single GPP API call.
Google's GPP Support
Google Ad Manager and Adsense supports the Global Privacy Platform for publishers and CMPs who choose to use this framework to comply with US state privacy laws. It is important to note that the use of GPP is not required by Google, but is recommended over the deprecated US Privacy String.
Core GPP Support Requirements
- Future Version Support: Starting in September 2025, Google will support GPP National v2, and will continue to support v1.0.
- MSPA Status: Ad Manager is a certified MSPA Certified Partner Program (CPP), meaning publishers are not required to sign the MSPA to work with Google.
- EEA/UK TCF Exclusion: GPP strings are not accepted for ads served in the EEA or UK. Ad Manager continues to require the IAB Europe TCF v2.2 string via a certified CMP.
- Supported GPP Sections: Ad Manager only accepts the following GPP sections: US National, California, Colorado, Connecticut, Florida, and Virginia.
- Unsupported Sections: Ad Manager does not accept IAB Canada TCF, US Privacy String, US State Utah, or IAB EU TCF v2.2 as part of GPP support.
Restricted Data Processing (RDP) Logic
Google triggers Restricted Data Processing (RDP) based on specific fields within the GPP string, indicating user opt-outs.
RDP Triggers:
- US National: Opt-out of Sale, Sharing, or Targeted Advertising.
- California: Opt-out of Sale or Sharing.
- CO, CT, VA, FL: Opt-out of Sale or Processing for Targeted Advertising. (Florida also includes opt-out of Sensitive Data Processing for ages 13-18.)
Minor Consent Signals (TFCD/RDP):
GPP signals for minors are read by Google, resulting in Child-Directed Treatment (TFCD) or RDP based on age and consent:
- TFCD (Child-Directed): Triggered if minor consent fields (e.g., <13 or <16) are present for US National, CA, CO, CT, or FL.
- RDP (Ages 13-17): Triggered if there is "No consent" to processing/sale for specified age ranges in US National, CT, or FL.
Ready to Comply with GPP?
To comply with and effectively implement the Global Privacy Platform, leverage a dedicated Consent Management Platform (CMP) that handles the complexities for you.
We Recommend UniConsent CMP for GPP
UniConsent offers comprehensive solutions for consumer data control, efficient management of preference communications, and seamless GPP 1.1 API integration.
Explore UniConsent GPP Solution →GPP Implementation Guidelines
Publishers & Digital Property Owners
As a Publisher, your primary task is implementing a CMP to manage the user interface for consent. This includes choosing the applicable GPP sections based on your audience.
- Determine Applicable Sections with legal counsel (jurisdictions).
- Ensure Vendor and Partner Compatibility with GPP.
- Focus on User Experience for consent presentation.
- For Mobile App Developers, standardize GPP data storage locations and naming conventions so ad tags can access the GPP string seamlessly.
How Consent Management Platform (CMP) works
CMPs collect user choices, generate the GPP String, and communicate it via the GPP API. This involves developing diverse user interfaces for various regulatory frameworks.
- Obtain and use a unique CMP ID where required (e.g., TCF).
- Implement the defined GPP API 1.1 for web and mobile.
- Manage the complexity of Encoding the GPP String (Base64-like).
- Dynamically indicate the Applicable Section(s) to vendors.
Vendors & Advertisers
You must read and interpret the GPP string to determine allowed processing. As an Advertiser, you must ensure your ad tech partners and internal systems correctly read and honor the GPP signals received.
- Register for Vendor IDs (consistent across TCF/MSPA).
- Find the GPP String via CMP API, OpenRTB Regs object (server-side), or URL parameters (client-side).
- Use the IAB Decoder or build custom logic to decode the Fibonacci-encoded string.
- Validate
signalStatusisreadybefore consumption.
Frequently Asked Questions
What's the difference between GPP, IAB TCF 2.2, and CCPA?
The GPP is built upon the foundation of existing frameworks like TCF 2.2 but serves as a broader, comprehensive solution, specifically addressing the complexity of the US market. It defines the unified transport layer for encoding and transmitting user privacy signals for IAB TCF (EEA/UK), as well as signals related to the Multi-State Privacy Agreement (MSPA) and specific US state laws (e.g., California, Virginia, Colorado). GPP is the single technical standard for multi-jurisdictional consent signaling.
What is the difference between a GPP ID, TCF Vendor ID, and an MSPA Signatory ID?
These all refer to the same unique identifier assigned to vendors participating in the various frameworks. This consistency ensures that implementers do not need to maintain separate IDs across multiple frameworks. However, vendors must still register for each specific framework (TCF, MSPA, etc.) they wish to participate in.
How is the GPP String structured?
The GPP String is a single, Base64-like encoded string that begins with a required Header Section. This header acts as a table of contents, identifying which regulatory sections (like US National or California) are included in the string. The header is followed by the individual section strings, all concatenated and separated by a tilde (~). This compact, unified format allows multiple privacy signals to be passed efficiently.
Can GPP replace my existing IAB Europe TCF implementation?
No. While the GPP is designed to carry the TCF signal as a "section", major ad platforms like Google Ad Manager do not accept the TCF signal via GPP for the EEA/UK. The GPP primarily addresses compliance complexity in the US and Canada. For the European Economic Area (EEA) and the UK, you must continue to use a certified CMP to implement the IAB Europe TCF 2.2 string directly.
What is the purpose of Fibonacci Encoding in GPP?
GPP strings, especially those containing multiple sections, can become quite long. Fibonacci Encoding is a mechanism used in the specification to reduce the final string length. This prevents errors and issues that can occur in various parts of the digital advertising supply chain (like URL parameters or header limits) when dealing with excessively long strings.