Integrating Google Consent Mode v2, Global Privacy Control and IAB GPP requires a shared decision process, followed by separate platform integrations. GPC communicates an opt-out preference. Consent Mode controls supported Google tag behaviour. GPP carries structured privacy information to participating recipients. These signals are related, but they do not express interchangeable permissions.
Start with the visitor's applicable rights and choices, decide which processing is permitted, then configure each recipient accordingly. A matching banner label, Google signal and GPP string is useful evidence of consistency. The decisive check is what information the browser and servers actually send.
This guide focuses on integration architecture. For the underlying obligations, see the GPC guide and CCPA cookie banner requirements.
IAB Tech Lab now calls GPP the Global Privacy Protocol, formerly the Global Privacy Platform. Existing repository names and integration documentation may still use the earlier name.
Give each signal a defined role
| Component | Its role | What it does not establish |
|---|---|---|
| CMP or preference service | Collects and maintains visitor choices | Whether every downstream recipient follows them |
| GPC | Communicates a browser or device privacy preference | Affirmative consent when the signal is absent |
| Google Consent Mode | Changes supported Google tag behaviour using consent states | Permission for unrelated vendors or every type of processing |
| IAB GPP | Transports privacy choices through supported framework sections | Legal compliance merely because a string is present |
| Application and server controls | Enforce the permitted processing for each destination | Automatic enforcement from adding a field to an event |
GPC is exposed through the Sec-GPC: 1 request header and the browser's navigator.globalPrivacyControl property. A false or missing value does not supply permission to sell or share data. See the GPC specification.
A useful internal record keeps separate fields for the source of a preference, its scope, the time received and the resulting processing decision. For example, keep a sale/sharing opt-out separate from an analytics consent choice. Record only the information needed to operate and demonstrate those choices.
Map processing decisions before writing code
Prepare a mapping for each destination, including its purpose, data fields, relevant user choices, applicable opt-outs and technical enforcement method. Review the actual configuration and contracts before treating an analytics or advertising integration as permitted. The sale versus sharing guide explains that assessment.
Google's four principal Consent Mode parameters use the strings granted and denied, not JavaScript booleans:
| Parameter | Decision represented |
|---|---|
ad_storage | Consent for advertising-related storage |
analytics_storage | Consent for analytics-related storage |
ad_user_data | Consent for sending user data to Google for advertising |
ad_personalization | Consent for personalised advertising |
These values should reflect the specific choices and processing involved. One CMP category does not necessarily justify granting every advertising parameter. See Google's implementation reference.
Example: analytics accepted, advertising rejected
Consider an illustrative European implementation where a visitor accepts the site's separately explained analytics purpose and rejects advertising. If that choice supports the configured analytics storage, the mapping can set analytics_storage to granted while leaving the three advertising parameters denied. The integration must also prevent non-Google advertising tags and server destinations from receiving prohibited data.
This example assumes the underlying consent and analytics configuration have been assessed. It is not a rule that every analytics product can run whenever an “Analytics” switch is on.
Example: a California visitor sends GPC
A covered business that sells or shares personal information must process a qualifying opt-out signal for the browser or device and associated profiles, including pseudonymous profiles. If it knows the consumer, it must also apply the request to that consumer. It must display whether it has processed the signal. A saved setting allowing sale or sharing cannot simply override a newly received signal. The regulation provides specific conflict and subsequent-consent rules. See CCPA regulations, section 7025.
For an illustrative advertising flow classified as sharing, the integration must stop that sharing. Sending an advertising denial to Google may be one part of the implementation; disabling other destinations may be another. Separately assessed analytics may have a different outcome. Do not translate GPC mechanically into either “reject every cookie” or “only disable personalised adverts”.
Initialise Google consent through one integration path
Choose the supported path for your deployment:
- Direct Google tag: establish consent defaults before measurement commands, then update the state when the preference solution has the relevant choice.
- Google Tag Manager: use the CMP's supported template or a consent template using
setDefaultConsentStateandupdateConsentState. Set defaults on Consent Initialization. Google warns that queuedgtagcommands inside templates can be processed too late. See Google's consent template guidance.
Avoid installing a CMP's native integration and a second custom script that independently grants or denies the same settings. Assign responsibility for defaults and updates, then test that there is one consistent outcome.
wait_for_update provides a bounded wait for an asynchronous consent update. It is not a mechanism that waits indefinitely for a person to choose. When the wait expires, the configured default still matters. Regional defaults are supported, but a published list of countries with a global granted fallback is not a legal assessment. See Google's setup guidance.
Choose basic or advanced behaviour deliberately
For the deployment decision and modelling trade-offs, use the basic versus advanced Consent Mode comparison.
In a basic implementation, Google tags remain blocked until the relevant consent is granted. In an advanced implementation, tags load with defaults and can send cookieless pings when consent is denied. Denied storage therefore does not mean no network requests. Separately, denying ad_user_data disables personal data collection for online advertising, including user IDs and enhanced conversions; denying ad_personalization disables personalised advertising. These are Google's technical implementation options, described in its Consent Mode overview.
Assess the proposed requests, purposes and legal requirements before selecting the behaviour. “Cookieless” is not a substitute for reviewing data collection. For the consent context, read the GDPR cookie consent guide.
Treat URL passthrough and advertising-data redaction as separate configuration decisions. URL passthrough can carry identifiers through links when storage is denied; advertising-data redaction has a defined Google Ads and Floodlight scope. Neither is a general permission to transmit information. The details are in Google's optional consent features.
Read current GPP data only when it is ready
Use the API version your CMP implements. In GPP CMP API 1.1, getGPPData was removed. The callback-based ping response includes the GPP string, applicable sections and readiness state. Subscribe with addEventListener for updates; use the event's pingData rather than assuming that a section-change notification already represents a completed update.
The specification distinguishes signalStatus: 'not ready' from 'ready'. Processing updates can produce intermediate section changes before the final ready event. Readiness describes signal availability, not permission. See the IAB GPP CMP API specification.
A practical integration should define these outcomes before release:
| Condition | Integration decision to specify |
|---|---|
| CMP API has not loaded | What remains blocked while waiting, and how readiness is detected |
| Signal is not ready | How dependent processing pauses without using a stale grant |
| Ready signal with applicable sections | Which recipient consumes which section and how it enforces the fields |
| No applicable section | Which other controls govern the destination; this is not blanket permission |
| CMP error or timeout | A documented fallback that does not invent permission |
| Preference changes | How existing listeners, queued events and subsequent requests receive the new decision |
GPP section identifiers are defined centrally. For example, 7 identifies the US National section and 8 the US California section. The header has identifier 3, but it is structural metadata, not a jurisdictional permission section. Use the IAB section registry instead of maintaining a copied state table that can become stale.
Configure the CMP to generate the appropriate sections and verify each recipient's supported integration. Calling the read API does not itself create or update a valid GPP string. GPP is relevant where a participating integration uses it; it is not a universal legal requirement for every website.
Carry the decision through server-side processing
Google's supported server-side Tag Manager architecture already carries consent parameters in requests from the Google tag to the server container. Its GA4 client interprets the requests, and supported Google product tags adjust their behaviour. A custom consent JSON object is not required as a replacement for that mechanism. See Google's server-side Consent Mode documentation.
Other server tags and direct conversion APIs need destination-specific controls. Do not assume a Meta, Microsoft or custom webhook integration reads Google consent fields automatically. Document the event fields it consumes, the decision it applies and the information it suppresses.
For custom infrastructure, review the following boundaries:
- Incoming request: determine which browser signals and stored preferences are available before deciding to forward data.
- Preference storage: associate an opt-out with the appropriate session or account without requiring extra identification merely to accept it.
- Application event: attach the necessary decision context, avoiding unnecessary personal information in diagnostic logs.
- Queue or server container: prevent stale or incomplete state from being interpreted as a grant.
- Outbound destination: check the payload, destination and applicable restrictions immediately before dispatch.
A response header does not automatically become an input to a downstream server request. An HttpOnly cookie cannot be read by browser JavaScript. If the server owns the preference, design an explicit, appropriate way for the page and relevant services to receive the resulting state. Do not present setting a cookie as proof that the opt-out has been enforced.
For broader architecture, see the server-side tracking guide.
Verify the complete preference journey
Test a clean visit, returning visit and mid-session change. Use both slow and failed CMP loading conditions. Record the expected outcome before running the test.
| Scenario | Evidence to inspect |
|---|---|
| First visit before a choice | Google defaults, actual tag loading and every outbound destination |
| Analytics-only choice | Google parameter mapping and independent advertising controls |
| GPC with a saved advertising preference | Resolution of the conflict, processed status and resulting transfers |
| Login after an anonymous opt-out | Account association and relevant downstream controls |
| Consent withdrawal | Immediate updates, future event handling and applicable storage changes |
| GPP update in progress | No use of intermediate data as permission; final ready state consumed |
| Delayed server event | Treatment of an event queued before a subsequent preference change |
| Reload or navigation | Saved preferences restored without a temporary unintended grant |
Use Google Tag Assistant's consent diagnostics to inspect defaults and updates. Inspect network requests and server previews alongside it. A single gcs value is not a complete test of all Consent Mode v2 parameters, GPC processing or other vendors.
Keep a short record of the configuration version, test conditions, expected outcome and observed result. A successful signal transmission and a correctly restricted data transfer are separate findings.
Frequently asked questions
Does GPC automatically update Google Consent Mode?
Do not assume it does. Confirm how the CMP or custom integration receives the signal, resolves its scope and updates the relevant Google settings. Test actual transfers, including destinations that do not use Google tags.
Can one marketing switch control all platforms?
Only if the underlying purposes, choices and platform mappings support that design. Google, Microsoft UET, Microsoft Clarity and other products have distinct interfaces. See the UET Consent Mode guide and Clarity Consent API guide.
Do we need GPP if we do not use programmatic advertising?
Check the integrations you actually use. Implementing an unused signalling protocol adds maintenance without demonstrating that your existing processing is controlled. Your applicable consent and opt-out obligations still need effective handling.
Is a denied signal enough to prove compliance?
No. Review the choice presented to the visitor, the data collected, each recipient's behaviour and the server path. A denied parameter can coexist with permitted limited requests or an incorrectly configured unrelated transfer.
For a reproducible fault, use our Google Consent Mode v2 troubleshooting guide to trace missing defaults, failed updates and unexpected tag behaviour.
Review your integration
Start with a destination inventory and a small set of testable preference scenarios. Use the results to identify where the CMP, tags, application and server disagree. Recheck the journey when changing a CMP template, vendor, purpose or server integration.
For help reviewing the implementation, discuss your Consent Mode setup or request a free consent audit.
