This document provides technical implementation guidelines related to the Global Privacy Platform (GPP) specifications. The IAB Tech Lab Global Privacy Working Group developed the guidelines to support industry adoption of the GPP. The intended audience for this document includes product and engineering teams building technology based on the specifications who are looking for implementation guidance.
1.1 Getting Started
1.2 Glossary of Terms
1.3 Core GPP Specifications
1.4 Section Specifictions - Understanding Sections and Sub-sections
2.1 About Consent Management Platforms (CMPs)
2.2 Deciding Which Sections to Support
3.1 CMP IDs
3.2 Presentation of User Choices
3.3 Supported APIs
3.4 Applicable Section(s)
3.5 Encoding the GPP String
3.6 API Lifecycle: Managing “opt in” vs. “opt out” Frameworks
4.1 Vendor IDs
4.2 Finding a GPP String
4.3 Decoding a GPP String
4.4 Sending a GPP String
Where can I find section-specific implementation guidelines?
What’s the difference between a GPP ID, TCF Vendor ID, and an MSPA Signatory ID?
How can I submit my questions?
The IAB Tech Lab Global Privacy Platform (GPP) was developed to help ecosystem participants support user choice and comply with consumer privacy regulations across diverse regulatory regimes. With increasing numbers of data privacy laws being adopted across the globe, including the GDPR in Europe, PIPEDA in Canada, and multiple US state laws, efforts to maintain compliance were becoming dramatically more complex, cumbersome and fragmented. In response, the Tech Lab’s Global Privacy Working Group developed the GPP, a unified standard for communicating user consent and data preferences efficiently and consistently across diverse legal environments.
The GPP aims to maximize interoperability in this complex environment by simplifying and harmonizing user preference communication, making it easier for all parties in the digital advertising supply chain to comply with regional privacy regulations and easier for users to understand their options and to express and manage preferences. The platform accomplishes this by defining a transport layer which standardizes preference encoding and communication and by providing a common set of well defined signals so all participants have a consistent, partnership agnostic understanding of the user preferences.
The IAB Tech Lab Global Privacy Working Group is responsible for the development of the GPP. As of this writing it has added support for the following privacy strings: the IAB Europe TCF, the IAB Canada TCF, the MSPA’s US National string, and a number of US state-specific privacy strings. The Global Privacy Platform will continue to be expanded to support additional jurisdictions with data privacy regulations. For the most up-to-date information on supported privacy strings, see Section Information in the Global Privacy Platform github repository.
Before adopting and implementing the IAB Global Privacy Platform (GPP) standard, a company should consider the following:
-
Regulatory Requirements: You must start with your compliance team or legal counsel and ensure that the GPP standard aligns with the privacy regulations applicable to your business and to verify the platform supports the jurisdictions your company operates in.
-
Legal and Compliance Review: Conduct a thorough legal review to ensure that adopting GPP aligns with your privacy policies and terms of service. This includes verifying that the GPP implementation meets the requirements of all relevant data protection laws.
-
User Experience: Determine if implementing GPP will impact the user experience on your platform and if so, how. Consider how consent choices will be presented to users, how users will define and manage their preferences and how changes affecting users will be communicated.
-
Vendor and Partner Compatibility: Ensure that your partners, including advertising networks, data processors, and other third-party vendors, are also compatible with GPP. Coordination with these partners is crucial for maintaining compliance across the data supply chain.
-
Technical Integration: Assess the technical requirements for integrating GPP with your existing systems. This includes understanding how GPP handles consent strings, how it interfaces with your content management systems (CMS), ad servers, or other third-party services, and whether your infrastructure can support these integrations.
-
Data Management: Review GPP user consent data handling and ensure that your data processing practices are compatible with the framework. This includes understanding the logging, storage, retrieval, and updating of consent preferences and ensuring that the process is secure and compliant.
-
Staff Training: Prepare your teams by providing training on your regulatory compliance program and how to implement and manage GPP to support it. This includes compliance teams responsible for monitoring and reporting and product and technical teams responsible for implementation and partner integration.
-
Ongoing Maintenance and Updates: Determine how your organization will manage the process of keeping your GPP implementation up to date as support for new regulations is added and support for existing ones change. This requires a commitment to keeping abreast of updates to the platform, understanding if and how changes impact your implementation and regularly updating your implementation to ensure continuous compliance.
-
Cost and Resources: Consider the cost of implementing and maintaining GPP, including:
-
Resource allocations for the initial build
-
Ongoing operational costs for testing, monitoring and updates.
-
The cost of developing and maintaining integrations with existing and future partners and service providers
-
Resources required for ongoing monitoring of compliance with new and updated regulations.
-
-
Testing and Monitoring: Plan for system and end-to-end testing during deployment to ensure the GPP implementation works as expected and that you have sufficient monitoring in place. After deployment, establish monitoring processes and regular reviews and testing to ensure continued compliance and proper functioning of your implementation.
By considering these factors, a company can effectively implement the Global Privacy Platform standard to aid in complying with global privacy regulations.
|
Term |
Definition |
|
Advertiser |
A company, or advertising agency representing an Advertiser, that (i) owns advertisements for placement in inventory on Publisher’s websites or other media properties, and/or (ii) interacts with consumers on its Digital Properties or through its advertisements. |
|
Consent Management Platform (CMP) |
A company or organization that acts as an intermediary between a Publisher, an end user, and Vendors to (i) provide transparency, (ii) help Vendors and Publishers establish legal bases for processing (where needed), (iii) acquire user consent as needed, as well as manage user opt outs, and (iv) communicate these to the ecosystem. |
|
Digital Property |
A web page, mobile site, video digital property, video player, application, or retailer page. |
|
Digital Property Owners |
Any party that identifies as a Publisher or Advertiser in the digital supply chain who maintains control of a Digital Property. |
|
GPP String |
A string of characters used to represent a user’s choices. |
|
Multi-State Privacy Agreement (MSPA) |
A common contractual framework for Advertisers, Vendors, and Publishers for implementing U.S. state privacy laws that functions as a “springing contract”that creates a contractual relationship amongst signatories as personal information flows between them for purposes of delivering a digital ad. |
|
Section |
In the context of the GPP String, a Section is the technical encoded representation of the choices/signals for a specific framework. Frameworks usually represent a specific jurisdiction. |
|
Subsection |
In the context of the GPP String, a Subsection is a logical part of a section used to separate information within this section. |
|
Vendor |
A company that participates in the delivery of digital advertising or other online activities within a Digital Property, to the extent that company is not acting as a Publisher, Advertiser or CMP. |
In the GPP Github repository, there is a Core folder that contains the two specifications that make up the core of the platform: the GPP API Specification and the GPP String Specification.
The GPP API Specification describes the Consent Management Platform (CMP) API, which is the mechanism web pages and apps use to interact with CMPs, including how providers of the API must implement it and what callers of the API can expect.
The GPP String Specification defines what a GPP string looks like and includes the details for the GPP header section. It also provides the primitive data types that may be used in any section specification.
The header section is always required and always comes first. The purpose of the header is to identify which sections are included in a string payload and be a table of contents of where to find each signal in the string payload (broken into discrete sections).
A section in the GPP represents a unique privacy signal and generally corresponds to a unique jurisdiction. As such, only one section should be sent in a given string, understanding that an individual is typically afforded rights under a single jurisdiction. However, you may encounter multiple sections identified within the Section ID (gpp_sid).
Today, acceptable use is to allow up to two (2) applicable section IDs to be signaled. See CMP Guidelines, 3.4 Applicable Section(s), for more details.
Sections indicate a user’s preferences according to the jurisdiction that the section represents. A high level explanation of sections are provided here for reference.
- The EEA/UK section contains data that, when decoded, produces a TC String that is compatible with the TCF specification. See the Transparency and Consent Framework Specification and Implementation Guidelines for more information.
Important Note:
The standalone TC string will continue to be used by many digital property owners until it is deprecated by IAB Europe. Until then, the TC string must be included in your transaction headers, the TCF API must be implemented on your page, and vendors are required to look for and interpret the TC string for all transactions where GDPR is applicable.
-
The US Privacy section is deprecated and should not be used. US privacy signals are provided in the MSPA/US National and US State specific sections**.**
-
The MSPA/US National section provides a way for MSPA signatories and Certified Partners to meet the highest common denominator of state privacy law requirements and are used in place of specific state strings. The signals in the MSPA/US National Section can be evaluated for required compliance in light of the MSPA. See the MSPA text and Implementation Guidelines for more information.
-
The US State Specific sections provide a way to meet state privacy law requirements. They have been developed to comply with the relevant state privacy laws. The signals in each section, when decoded, can be evaluated for compliance in light of the relevant state laws.
Every string consists of at least one section, but each section may contain multiple sub-sections. Sub-sections are used to indicate values representing bespoke requirements under various laws and regulations. For example, while US state privacy laws typically allow for processing unless an opt-out signal has been received, there are different levels of consent required for processing sensitive personal information or children’s data. Sub-sections allow for these nuances to be captured within the consent string.
The Global Privacy Working Group is responsible for authoring technical specifications for new sections when there is a need to communicate user preferences relevant to specific markets.
Upcoming additions include new sections for U.S. states that have enacted comprehensive data privacy laws, as well as a section designed to help organizations comply with India's Digital Personal Data Protection Act (DPDPA).
This section details the overall guidelines that digital property owners should typically follow when implementing the GPP.
A Consent Management Platform (CMP) is used to manage transparency and consent preferences signaled by the end user. The CMP captures and manages the transparency and consent information from a user. The CMP also surfaces this information to vendor technologies operating as part of the publisher’s digital property and supply chain. The CMP acts as an intermediary between the publisher, end user, and vendors.
The publisher may implement a CMP in two ways:
-
Build: Develop an in-house CMP
-
Outsource: Rely on the service of a commercial CMP
Regardless of the choice to build or outsource the CMP, Publishers should be aware of the sections in the GPP that include additional CMP requirements such as registration. Publishers who choose to develop an in-house CMP should also refer to the CMP Guidelines section of these guidelines.
Publishers may operate in one or multiple jurisdictions where there is a need to provide their users with transparency and choice. The GPP includes support for multiple jurisdictions including the EU, Canada, and multiple US states. For the most up-to-date list of jurisdictions that the GPP supports, see the Section Information portion of the specification.
Publishers should consult their business and legal teams to determine which sections of the GPP they should support. They should also consult their CMPs (if using a commercial CMP) to determine which sections the CMP is ready to support. Last, publishers should work with their vendor partners to understand which sections their partners are ready to support.
This section details the overall guidelines that consent management platforms should follow when implementing the GPP.
CMPs are responsible for collecting consent from the end user and communicating that consent to vendors.
As a GPP CMP, you will need to:
-
Establish legal bases for processing personal data with your end users, complying with the requirements, technical specifications, and policies of the individual privacy strings (GPP sections) you support.
-
Generate an encoded data string, the GPP String, containing the encoded choices or settings for the individual sections for which you have established legal bases.
-
Share the GPP String with vendors through the defined GPP API.
Certain section frameworks supported in the GPP, such as IAB Europe’s Transparency and Consent Framework (TCF) and IAB Canada’s Transparency and Consent Framework (TCF), require a CMP ID. This is an ID assigned by the IAB Europe following registration and certification; if you register as a CMP for multiple of these frameworks, your IAB CMP ID will be the same for all frameworks. Not all individual privacy sections require a CMP ID.
The PingReturn object defined in the GPP API contains a cmpId field. If you support a section that requires a CMP ID, you should always provide your ID in that field (field may be set to 0 during your stub/loading phase). If you do not have an assigned CMP ID due to not supporting sections that require one, you should set the field to 1.
One of the core responsibilities of a CMP is to surface consent choices to the end user within the publisher’s site, mobile, or CTV application.
As the IAB GPP supports many individual section frameworks, you will likely need to develop different user interfaces to establish legal bases under different frameworks. As a CMP, you are responsible for complying with the technical specifications and policies set by each privacy framework that your CMP supports. This may further require IAB certification.
Note that these user interfaces may be surfaced in different ways; some frameworks may require that the user is automatically presented with a blocking interface upon visiting the site or app, whereas others may be triggered by the user clicking a link embedded in the site or app.
As a CMP that supports the GPP, you are not required to implement all supported sections. To indicate to callers which sections of the GPP that you support, use the supportedAPIs field in the PingReturn object. This can be set statically to the list of all sections (string formatted as <section prefix>:<section ID>) that your CMP supports. Use the applicableSections field in the PingReturn object to dynamically indicate the specific section(s) that apply to a given user.
Note that the applicableSections list is separate from the range-encoded Sections list in the GPP string header itself; the GPP header Sections list should contain only the list of section IDs that correspond to the sections present in the latter part of the GPP string.
The GPP string can be thought of as a list of all individual privacy strings collected from the end user. As a CMP, you are responsible for helping vendors interpret this string and determine which section string(s) applies to this request. You will indicate this through the applicableSections field in the PingReturn object.
This field should be set only to the individual section IDs that you have determined are applicable to this request; it should not be set to the list of all sections that you support as a CMP. If you have determined that no section applies, set [-1]. This is typically determined primarily by the end user’s geolocation, although CMPs may use other factors at their discretion in conjunction with your legal and business teams. For example, if you support both the MSPA US National section as well as a state section also supported by MSPA US National, you can determine which section between the two actually applies and should be read by vendors.
Note that you can set up to 2 applicable section IDs in the field. Previously the specification allowed up to 3 to accommodate the now-deprecated US Privacy section, but this is no longer allowed. In the above example where multiple frameworks apply, you may choose to signal both as applicable or select a single section.
The GPP string consists of a tilde-concatenated (~) list of consent sections that you have collected for a given user. It begins with a “header” that provides metadata about the remaining contents of the string, followed by individual section strings.
Instructions for encoding the header section and general encoding formats used by many of the individual sections can be found in the GPP Consent String Specification. Note that while the recommended encoding format uses the base64 alphabet, the encoding is only “base64-like” and it uses a different grouping and padding format. More details can be found in the Consent String Specification.
Example headers that demonstrate the expected grouping, padding and encoding patterns can be found in the specification. To manually test the decoding of your encoded strings, you can use the decoder at iabgpp.com.
The GPP supports multiple styles of frameworks. Some, like TCF, are considered to be “opt in” where the user must make a selection prior to proceeding in the site or app, whereas others, like MSPA US National, are considered to be “opt out”, where the user triggers the consent layer through an embedded link on the site or app.
See the PingReturn section and status codes for more on how to signal various lifecycle events for different framework types. Some key fields are:
-
signalStatus: This indicates that the GPP string is ready to be consumed by vendors. Note that for an “opt out”-style framework, this field may immediately be set toready, as long as an initial string for the applicable section has been generated (or if there is no applicable section). -
cmpDisplayStatus: This indicates the visibility of the applicable UI. Note that for frameworks that do not have a blocking display layer (e.g. where a user triggers the consent dialog via a “Do not sell or share” link), this value should always be null; callers will rely on thesignalStatusfield to determine if the GPP string is ready for consumption.
Today’s global environment requires Vendors to uphold their own compliance obligations as well as to support their partners in their compliance efforts. The GPP provides Vendors with a technical mechanism to understand where processing is allowed and where processing may be restricted under applicable privacy laws and regulations.
Vendors use the GPP in order to
-
Understand user consent and data preferences and, the compliance posture of Publishers sharing personal data; and
-
Support the Vendor’s compliance posture.
Vendor roles include:
-
Supply Side Platforms (SSPs)
-
Demand Side Platforms (DSPs)
-
Measurement Providers
-
Data Management Platforms (DMPs)
Vendor IDs are unique identifiers assigned to companies participating in the IAB Europe’s Transparency and Consent Framework (TCF) for GDPR and ePrivacy compliance, IAB Canada’s Transparency and Consent Framework (TCF) for PIPEDA and Quebec’s Law 25 compliance, or IAB’s Multi-State Privacy Agreement (MSPA) for compliance with US state privacy regulations.
Each participating vendor is assigned a Vendor ID by the IAB upon registration for TCF Europe, TCF Canada, or when becoming a signatory to the MSPA. Note that not all sections necessarily require registration; however, when registration is required, the Vendor ID is consistent across all frameworks.
-
Vendors can decode the GPP string to determine:
-
Whether they have permission to process user data.
-
What purposes they can process data for (e.g., ad targeting, measurement).
-
-
Vendors that are not included in the GPP string are required to respect the lack of consent and avoid processing personal data.
GPP strings are created by CMPs and can be found through a CMP API call, through the OpenRTB Regs object (when you don’t have access to the browser), or by reading the URL parameters (where JavaScript cannot be executed).
CMP API call
When GPP is received client side (e.g., any code snippet deployed directly on the browser, such as JavaScript), the GPP CMP API should be used to access the encoded string. This information can be collected whether you are in the top parent page (using the __gpp method) or from an iframe (using postMessage method as defined by the CMP API technical specifications). Use a callback function passed to the event listener API (addEventListener) to retrieve the most up to date PingReturn object.
OpenRTB Regs Object
If GPP is received server side (e.g., OpenRTB), you should read the encoded string from the Regs object. For other non-standard server side delivery, clarify with your partner(s) on how the encoded string is passed.
If OpenRTB is not supported (for example, for cookie syncs), the GPP string will be found in the URL parameters. Vendors are encouraged to follow the IAB recommendations for macro names. The GPP Consent String Specification allows for URL-based service processes to receive a string through a set of macros designed to pass the encoded string via URL.
The GPP string runs the risk of causing errors due to string length so that Fibonacci encoding is used to shorten the string length. As a result, you will need to either develop your own decoder or use the IAB provided decoder in order to read the values of the string. Refer to the GPP Consent String Specification for more guidance on decoding the GPP string.
Fibonacci Encoding
It will be important to read the IAB technical specification for decoding the string. Reference Section 6. Implementation Resources for links to IAB documentation.
For any server-side call, if using openRTB, the consent payload should be sent according to the openRTB specs.
For any client-side call, once the consent payload has been obtained leveraging the CMP JS API, you can validate that it reflects user-intentful consent by checking the status of certain fields. For example:
-
the field cmpStatus is loaded, and
-
the field signalStatus is ready
The status of these two fields as indicated above show that the CMP has been loaded and that the GPP string is ready to be consumed. After validating the PingReturn payload is suitable for your case, you should pass the GPP string in the ad call using the URL-passing macro solution detailed in documentation for the GPP String.
-
MSPA Technical Signaling Implementation Guidelines - Note that these guidelines are for MSPA signatories
The GPP ID, TCF Vendor ID, and MSPA Signatory ID refer to the same identifier assigned to vendors participating in different frameworks. When a vendor registers for any of these frameworks, they will always have a GPP ID. This ensures that implementers do not need to maintain separate vendor IDs across multiple frameworks.
It's important to note that vendors must register for each specific framework they wish to participate in. Registration in one framework does not automatically mean they are registered in others. Failure to register for all appropriate frameworks will result in vendors not being included in Global Vendor Lists (GVLs) or signatory lists.
You can submit your questions regarding the GPP to [email protected].
Below are implementation resources developed and maintained by the Global Privacy Working Group
-
Encoder/Decoder Tool (GPP String Debugging Tool)