Google Consent Mode is a technical interface between a consent management platform (CMP) and Google tags. It tells Google Analytics 4, Google Ads and related tags which storage and processing purposes a visitor has accepted or rejected.
It is not a consent banner or a legal basis. A correct Consent Mode setup does not by itself make a website compliant with the GDPR or national rules on terminal-equipment access. It only makes Google tags respond to the state communicated by the CMP.
This guide explains the engineering implementation, not legal advice. The appropriate services, purposes and Consent Mode variant should be assessed for the specific website with the organisation's privacy team or legal counsel.
The short answer
A reliable implementation needs five elements:
- a genuine consent choice in the CMP,
- a defined default state before any Google measurement command runs,
- an immediate state update after the visitor makes a choice,
- the same logic for withdrawal and future page views,
- verification in Tag Assistant and the browser network panel.
The central architecture choice is whether Google tags remain fully blocked before consent (Basic Consent Mode) or load with denied defaults and may send cookieless pings (Advanced Consent Mode). The two variants do not create the same data flow.
Separate the legal and technical layers
The GDPR regulates matters including personal-data processing, transparency, legal bases, international transfers and data-subject rights. EU member states also apply rules derived from the ePrivacy framework to storing or accessing information on a user's device. In Germany, these rules are set out in Section 25 TDDDG.
Consent Mode does not decide whether consent is required or whether an exemption applies. It communicates a technical state after those questions have been assessed.
The four central Consent Mode v2 parameters are:
analytics_storagefor analytics-related storage,ad_storagefor advertising-related storage,ad_user_datafor sending user data to Google for advertising,ad_personalizationfor personalised advertising and remarketing.
These parameter names are not ready-made CMP categories. Their mapping to services, purposes and legal bases must be documented and implemented consistently.
Basic versus Advanced Consent Mode
Basic Consent Mode
In Basic Mode, Google tags are blocked before consent. If the visitor rejects the relevant purpose, the tags do not load and no data is sent to Google. They load only after consent has been granted.
This reduces measurement coverage but creates a clear technical boundary: no Google measurement request before the relevant permission.
Advanced Consent Mode
In Advanced Mode, Google tags load with denied default consent states. When consent is denied, they do not use the corresponding cookies but can send cookieless pings containing consent and device signals. Google may use these signals for modelling.
“Cookieless” does not automatically mean “anonymous”, “exempt from consent” or “legally risk-free”. Communication with Google still takes place. The parameters, recipients, purposes and legal basis therefore require a separate assessment.
| Question | Basic Mode | Advanced Mode |
|---|---|---|
| Google tags before consent | blocked | loaded with denied status |
| Requests after rejection | no Google tag requests | cookieless pings may be sent |
| Modelling coverage | lower | potentially higher |
| Technical boundary | simpler | more complex |
| Privacy assessment | still required | especially important |
Google documents the distinction in its official Basic and Advanced Consent Mode overview. The choice should not be based only on the amount of data a team would like to retain.
Implementation sequence
1. Inventory services and purposes
List every script and request, not only GA4:
- Google Tag Manager,
- Google Analytics 4,
- Google Ads and Floodlight,
- embedded video, maps and chat,
- A/B testing, session recording and heatmaps,
- server-side tagging or forwarding endpoints.
For each service, record the purpose, CMP category, potential cookies or storage access, recipient, loading condition and withdrawal behaviour. A tag-manager container is not inherently exempt; what matters is what it executes and transmits.
2. Set the default first
The consent default must be established before Google configuration or measurement commands run. Otherwise a tag can briefly execute with the wrong state.
In Google Tag Manager, Google recommends a CMP or Custom Template using the Consent APIs. setDefaultConsentState and updateConsentState are designed for this purpose; an arbitrary Custom HTML tag is not a robust way to initialise consent.
The default must match the chosen architecture and legal assessment. In a consent-based setup, optional purposes will commonly start as denied. Regional defaults must not silently treat users as having consented without a documented basis.
3. Update on the same page
When a visitor makes a choice, the CMP should update the state on the same page. Delaying the update until the next page view loses the first permitted measurement and creates inconsistent behaviour.
Send an explicit state for every relevant purpose. “Accept all”, “necessary only” and granular choices must each produce a clear matrix. For example, analytics consent without advertising could result in:
| Parameter | State |
|---|---|
analytics_storage | granted |
ad_storage | denied |
ad_user_data | denied |
ad_personalization | denied |
4. Treat withdrawal as a first-class flow
Withdrawing consent should be as easy as granting it. The implementation should:
- keep consent settings accessible,
- update relevant signals to
deniedimmediately, - stop future tag execution,
- apply the documented deletion policy to existing cookies,
- persist the new state for future page views.
A Consent Mode update does not automatically remove every cookie already set, nor does it retroactively delete data held by a third party. The wider implementation must cover those concerns.
5. Test client-side navigation
React and Next.js applications often navigate without a full reload. Verify that:
- the first page view waits for initialised consent,
- each client-side route is measured exactly once,
- a late consent update does not create a duplicate page view,
- a hard reload and direct entry restore the same state.
The CMP and analytics layer must share the same view of routing.
Verify the result, not just the banner
Test at least these scenarios in a clean browser profile:
- first visit with no stored choice,
- rejection of all optional purposes,
- analytics-only consent,
- acceptance of all purposes,
- consent withdrawal,
- reload and client-side navigation,
- mobile layouts and every supported language.
Tag Assistant
The Consent tab in Google Tag Assistant shows whether a default was set, which updates followed and the state of each consent type. Google's Consent Mode troubleshooting guide explains the diagnostic views.
Browser network panel
Also inspect the browser's developer tools:
- Which requests leave before a choice?
- In Basic Mode, are Google measurement requests genuinely absent?
- Which requests remain after rejection in Advanced Mode?
- Are cookies or local-storage entries written?
- Does behaviour change correctly after consent and withdrawal?
This is more meaningful than checking whether a banner is visible.
Performance, SEO and interpretation
Consent software can hurt user experience if it is injected late, shifts layout, ships an oversized bundle or loads the tag manager more than once. A stable implementation reserves space or uses a predictable overlay, supports keyboard use and avoids blocking essential controls.
Consent Mode itself is not a direct ranking factor. The effects are indirect:
- incomplete analytics can distort priorities,
- an unstable banner can affect Core Web Vitals and conversion,
- incorrectly blocked functionality can break rendering or navigation,
- modelled data can be mistaken for observed behaviour.
SEO teams should combine GA4 with Search Console, server and error data, and Core Web Vitals field data. Reports should distinguish observed, modelled and consent-limited figures.
Audit checklist
- CMP categories and Consent Mode parameters are mapped and documented.
- Basic or Advanced Mode was deliberately selected and assessed.
- The default is set before every Google measurement command.
- A choice updates the status on the same page.
- Rejection and granular choices work in practice.
- Withdrawal stops future measurement and addresses stored data.
- SPA navigation creates neither missing nor duplicate page views.
- Every state has been checked in Tag Assistant and the network panel.
- The CMP does not introduce avoidable layout shifts.
- The privacy notice, CMP wording and technical behaviour agree.
- Tests are repeated after CMP, GTM or GA4 changes.
Conclusion
A sound Consent Mode implementation starts with explicit decisions about services, purposes and loading conditions, not with a GTM snippet. Basic and Advanced Mode provide different levels of measurement and create different data flows. Both need a documented assessment.
Google's official Consent Mode implementation guide defines the API order. A production audit should add the applicable legal rules, CMP configuration, withdrawal behaviour and real network tests.