Google Consent Mode v2: the complete guide to understanding and implementing it

This guide is the reference page of our Consent Mode series. It covers what Consent Mode v2 is and why it is mandatory, the four parameters, the choice between basic and advanced, a step-by-step implementation with or without Google Tag Manager, the setup on the main site builders, how Consent Mode fits with GA4, other ad platforms and server-side tagging, the most common mistakes, the Tag Assistant errors you are likely to meet and a final checklist. Each section links to a dedicated article when you need to go further.

What is Google Consent Mode v2?

Consent Mode is a Google feature that adjusts the behavior of Google tags according to the consent your visitor expresses. It is the bridge between your GDPR cookie banner, managed by your consent management platform (CMP), and the Google services you use: Google Analytics 4, Google Ads, Floodlight and the Conversion Linker. Instead of a simple "load or do not load", tags receive consent signals telling them whether analytics and advertising storage are allowed, and they change what they write and send accordingly.

Keep one thing in mind from the start: Consent Mode v2 does not replace GDPR compliance. Your banner must still offer a refusal as easy as acceptance, choices by category and proof of consent. Consent Mode only transmits the result of that choice to Google. A perfect Consent Mode setup behind a banner that pushes visitors to accept remains a breach of the rules that the 7 conditions of valid GDPR consent describe.

Consent Mode v1 vs v2: what changed

Google launched the first version in 2020 with two parameters, analytics_storage and ad_storage. Consent Mode v2 arrived in November 2023 and brought two changes:

• two new parameters, ad_user_data and ad_personalization, which describe what Google may do with the data rather than which cookies may be written;
• a formal distinction between a basic implementation and an advanced implementation, with different consequences for modeling.

A site still sending only the two v1 parameters is treated by Google as not providing the consent it needs for advertising use: remarketing lists and personalization stop working for EEA traffic, even when the visitor clicked "Accept".

Is Google Consent Mode v2 mandatory?

Legally, no law mentions Consent Mode. Contractually, yes for most advertisers. Google applies its EU User Consent Policy and, since the Digital Markets Act made Google a gatekeeper, it must prove that it has consent before using personal data of EEA users for advertising. Since March 2024, it has asked advertisers to pass that consent through Consent Mode v2 (or through an IAB TCF v2.2 string, see our TCF 2.2 guide). Our article on the Digital Markets Act and cookies explains why the regulation landed on your tags.

If your site has no Google tag at all, Consent Mode is irrelevant. If you only use GA4 without Google Ads, it is not strictly required, but without it GA4 has no way to receive the refusal and you lose behavioral modeling.

What changes for your campaigns

Without valid Consent Mode v2 signals, three areas suffer:

• Google Ads: conversion modeling cannot work. Google can neither estimate the conversions of users who declined nor properly feed Smart Bidding.
• GA4: sessions, events and journeys of EEA visitors are no longer reported correctly, and your reports become incomplete.
• Remarketing audiences: ad_user_data and ad_personalization must be sent with a granted status for Google to use the data for advertising and personalization. Without them, your audiences shrink or stop filling.

We detail the effects on bidding, attribution and audience size in our article on Consent Mode v2 and Google Ads campaigns. Browser restrictions such as Safari's Intelligent Tracking Prevention reduce the reach of cookies further, which makes Consent Mode and its modeling even more important.

Symptoms of a faulty implementation

A few signs should alert you: a drop in measured conversions on EEA traffic in Google Ads, warnings in the Diagnostics tab of your conversion actions, missing modeling in GA4, remarketing lists that stop growing, or Tag Assistant messages reporting missing consent signals.

The four Consent Mode v2 parameters

Each parameter takes the value granted or denied:

• analytics_storage: storage of analytics cookies (visit duration, pages viewed, device type). It existed in v1.
• ad_storage: storage of advertising cookies. It also existed in v1.
• ad_user_data: consent to send user data to Google for advertising purposes. New in v2.
• ad_personalization: consent to ad personalization, including remarketing. New in v2.

The distinction matters. analytics_storage and ad_storage govern collection (which cookies may be written), while ad_user_data and ad_personalization govern use (what Google may do with the data). This is what makes v2 more granular than v1.

Each parameter maps to one of the GDPR cookie categories shown in your banner: statistics for analytics_storage, marketing for the three advertising signals. Three other storage types exist (functionality_storage, personalization_storage and security_storage), but Google tags do not read them: they are only useful if you use them yourself in GTM triggers.

What the signals look like in a request

You can read the consent state directly in the requests sent to Google. The gcs parameter carries the storage state: G100 means both storages are denied, G111 means both are granted, G110 and G101 mean only advertising or only analytics storage is granted. The gcd parameter, added with v2, encodes all four signals and tells you whether each one came from a default or an update. If you see gcs=G111 on a page where the visitor refused, a tag escaped your banner.

Basic vs advanced Consent Mode: which one to choose?

This distinction determines what you actually measure when a visitor declines.

Basic mode

Google tags do not load until the visitor consents. If the visitor declines, nothing at all is sent to Google. This is the strictest approach for privacy, but you lose every signal from users who refuse. Google can only apply a general model built from consented data, which is less accurate.

Advanced mode

Google tags load before the visitor interacts with the banner, with all parameters denied. As long as consent is not given, they write no cookies and only send cookieless pings carrying non-identifying information such as a timestamp, the browser type, the referrer and the consent status. Google uses these pings to model conversions and behavior with much better accuracy, even with a high refusal rate.

Is advanced mode compatible with the GDPR?

Basic mode is enough to meet Google's requirements and keep remarketing for users who consent. Advanced mode gives more reliable data, which matters if you invest heavily in Google Ads, but it raises a legal question: the cookieless ping still sends a request to Google with the visitor's IP address and user agent, which can be seen as processing personal data without consent. European regulators have not issued a position specific to Consent Mode, so have your DPO or legal team validate it against the GDPR and the ePrivacy rules that apply to you. Our comparison of basic and advanced Consent Mode goes deeper into this trade-off.

Conversion modeling and its thresholds

Modeling does not start automatically. In Google Ads, Google indicates a minimum of about 700 ad clicks over 7 days per country and domain grouping. In GA4, behavioral modeling requires at least 1,000 events per day with analytics_storage denied for at least 7 days, and at least 1,000 daily users with analytics_storage granted for at least 7 of the previous 28 days. Below these volumes, the gaps simply stay empty. The most reliable way to recover data is still to increase your consent rate with a clear, honest banner.

How to implement Google Consent Mode v2 step by step

Step 1: list your tags and choose a CMP that supports v2

Before configuring anything, find out what your site actually loads. Check in 30 seconds which cookies and Google tags your site sets before consent with the free cookie scanner. The result tells you whether GA4, Google Ads, Floodlight or third-party pixels fire before the banner.

Your CMP (if the term is new, see what a consent management platform is) then displays the banner, collects the choice and transmits it to Google tags. Google lists the CMPs it works with in its CMP Partner Program; whichever tool you pick, check that it sends all four parameters, not just the two from v1. If your CMP does not support v2, you will have to implement the signals yourself in GTM, which is more fragile. Our guide to choosing a consent management platform lists the criteria to check.

Step 2: set the default state before any Google tag

Before any interaction with the banner, all four parameters must be denied for EEA visitors. This command must run before every Google tag, ideally as the first script in the <head>, above the Google Tag Manager snippet:

gtag('consent', 'default', { 'ad_storage': 'denied', 'analytics_storage': 'denied', 'ad_user_data': 'denied', 'ad_personalization': 'denied', 'wait_for_update': 500 });

wait_for_update tells Google tags to wait up to 500 ms for the CMP to push a choice stored during a previous visit. A returning visitor who already accepted is then measured correctly from the first hit.

If your audience is worldwide and you only want the restrictive defaults in Europe, the default command accepts a region parameter with a list of country codes. Be careful: a visitor whose location is misdetected then receives the permissive default, so many European sites keep denied everywhere.

Step 3: update consent after the visitor's choice

When the visitor accepts, declines or customizes, the CMP calls gtag('consent', 'update', {...}) with the values matching the accepted categories. If the visitor accepts statistics but refuses advertising, you get analytics_storage: 'granted' and the three other parameters stay denied.

Consent Mode stores nothing itself. Your CMP must keep the choice (cookie or local storage) and send the right states again on every page load. Otherwise Google receives inconsistent signals, which corrupts modeling. Keeping that choice is also what lets you show a regulator the proof of consent it expects.

Step 4: enable the complementary features

• url_passthrough passes ad click identifiers (GCLID, DCLID) through internal URLs while ad_storage is denied, which preserves attribution if the visitor accepts later.
• ads_data_redaction, combined with a denied ad_storage, removes ad click identifiers from the pings sent to Google.

Step 5: configure consent on your GTM tags

In Google Tag Manager, Google tags (GA4, Google Ads, Floodlight) have built-in consent checks: they read the Consent Mode signals by themselves, with nothing to configure. Non-Google tags (Meta Pixel, LinkedIn, Hotjar, Custom HTML) do not: in Advanced Settings > Consent Settings, select Require additional consent for tag to fire and add the relevant signal, for example ad_storage for an advertising pixel. If you set the default state inside GTM rather than in the page, use the Consent Initialization - All Pages trigger so it runs before every other tag.

Our Google Tag Manager and Consent Mode guide details this setup, including the consent overview screen and the community templates.

Step 6: verify

1. Open GTM in Preview mode: Tag Assistant opens on your site. Select a Google tag, then the Consent tab. The default column must show denied for all four signals, and switch to granted after a click on accept.
2. In your browser's network tab, filter on collect and read the gcs and gcd parameters before and after your choice.
3. In GA4, go to Admin > Data streams, open your web stream and check that consent signals are detected.
4. In Google Ads, open the Diagnostics tab of your conversion actions to confirm the Consent Mode status.
5. Test the full journey: refusal, partial acceptance, full acceptance, then a new page load. In each case, tags must behave as expected. For a complete test plan (console, Tag Assistant, reading the gcs and gcd parameters, cookies and every consent scenario), see our guide on how to check that Google Consent Mode v2 is working.

Consent Mode v2 on Squarespace, WordPress, Shopify and other platforms

The principle never changes, but the place where you insert the default state does. The rule is the same everywhere: the CMP snippet and its defaults must sit above any Google tag, and the platform's native Google integration must not inject a tag before them.

• Squarespace: the built-in Google Analytics field loads GA4 early. Our Squarespace and Google Consent Mode v2 setup guide shows where to place the code injection and what to remove.
• WordPress and WooCommerce: Site Kit, analytics plugins and the CMP plugin can all send consent states. Keep only one source, as explained in our WordPress cookie consent guide.
• Shopify: Shopify has its own Customer Privacy API, and the Google & YouTube app relies on it. Our Shopify cookie compliance guide covers how it connects to a third-party banner.
• Webflow, Wix and Next.js: see the Webflow cookie consent guide, the Wix guide and the Next.js guide, each with the injection point that runs first.

Consent Mode and Google Analytics 4

GA4 is the Google tag most sites load, and the one where Consent Mode errors are most visible. With analytics_storage denied, GA4 writes neither _ga nor _ga_<container-id>; our article on the _ga, _gid and _gat cookies explains what each of them stores and for how long.

Consent Mode does not settle the broader question of whether GA4 itself is lawful in Europe (data transfers, IP addresses, retention settings): that is covered in our guide is Google Analytics GDPR compliant?. Google Signals adds another layer, since it links GA4 data to signed-in Google accounts and depends on ad_personalization; see our Google Signals and GDPR guide. If you want to measure without consent at all, the alternatives are in our cookieless analytics guide.

Beyond Google: Microsoft, Amazon and Meta consent signals

Consent Mode only governs Google tags. Other ad platforms have built their own mechanisms, and your CMP must feed them too:

• Microsoft Advertising reads a consent signal in its UET tag, close in spirit to Google's. Our Microsoft UET Consent Mode guide shows the commands to send and how to test them.
• Amazon Ads introduced the Amazon Consent Signal; see our Amazon Consent Signal (ACS) guide.
• Meta, TikTok and LinkedIn pixels have no equivalent of Consent Mode that replaces blocking. They must not load before consent; our Meta Pixel and GDPR guide explains how to hold them back.

Consent Mode and server-side tagging

Moving GA4 or Google Ads to a server-side GTM container does not remove the need for consent. The consent state travels with each event to your server container, and the server tags must respect it in the same way. A server container that strips the consent parameters, or that sets first-party cookies for all visitors, breaks the chain. Our article on server-side tagging and consent covers what changes and what does not.

Does Consent Mode affect SEO or page speed?

Consent Mode itself has no effect on rankings. The script that carries it does: a heavy CMP loaded synchronously can delay rendering and hurt Core Web Vitals. The inline default command is a few hundred bytes; what matters is how the banner is loaded. Our article on the impact of a CMP on Core Web Vitals gives the measurements.

Common Consent Mode v2 mistakes and how to avoid them

• No default state. Without an explicit default, Google tags behave as if consent were granted. Always set all four parameters to denied before GTM.
• Forgetting the two v2 parameters. Many setups send ad_storage and analytics_storage but not ad_user_data and ad_personalization. Remarketing and personalization then stop working, even after acceptance.
• Wrong execution order. If a Google tag loads before the default state, it uses implicit values that may not match your policy. The CMP sending its signals after the tags have loaded produces the same result.
• A native integration that loads Google first. A site builder's Google Analytics field, or a plugin, can inject GA4 above your CMP. Remove it and load GA4 through GTM or the CMP.
• No persistence across pages. If the CMP does not resend the stored choice on each page, Google receives contradictory signals.
• Advanced mode with a CMP that blocks Google tags. If the CMP prevents Google tags from loading before consent, no cookieless ping can be sent and advanced modeling never starts.
• Confusing Consent Mode with script blocking. Every non-Google tracker must be blocked separately.
• Duplicate implementations. If your CMP, a plugin and custom code all send consent states, the conflicting signals cause errors. Keep a single source.
• A working Consent Mode behind a non-compliant banner. Easy refusal, granularity and proof of consent remain mandatory. Avoid the cookie banner dark patterns that regulators sanction.

Troubleshooting: 5 common errors in Tag Assistant

"No consent default found"

The default command is missing or fires after the Google tags. It must run first. If you set it inside GTM, use the Consent Initialization - All Pages trigger, not the standard All Pages trigger.

"ad_user_data or ad_personalization not set"

Your CMP only sends the v1 parameters. Update its configuration or switch to a CMP that natively sends all four signals.

"Consent state is always granted"

Your default state is granted instead of denied for EEA visitors. Tags fire before the visitor interacts with the banner, which is not GDPR compliant. Set all four parameters to denied by default.

Conversions drop to zero

Check in Tag Assistant that the state switches from denied to granted after a click on accept. Also make sure your conversion tags are not set to fire only on Consent Initialization.

Modeling inactive or insufficient data

You are probably below the volume thresholds described above. Two levers: a clearer banner that raises the consent rate, or a move to advanced mode after legal review.

Consent Mode v2 implementation checklist

• Scan your site to list the Google and third-party tags it loads.
• Check that your CMP natively supports Consent Mode v2 and sends all four parameters.
• Set the default state to denied for all four parameters, before GTM, at the top of the <head>.
• Remove any native Google integration that loads a tag before the defaults.
• Check that the CMP calls gtag('consent', 'update') after every choice and resends the stored choice on each page.
• Choose between basic and advanced after consulting your DPO or legal team.
• Enable url_passthrough (and ads_data_redaction if you want to strip click identifiers from pings).
• Add an additional consent check to every non-Google tag in GTM.
• Feed the Microsoft UET and Amazon consent signals if you advertise there.
• Validate the order of default and update events in Tag Assistant and in the gcs and gcd parameters.
• Confirm in GA4 (Admin > Data streams) and in Google Ads (conversion Diagnostics) that consent signals are detected.
• Test refusal, partial acceptance and full acceptance.

How FlowConsent handles Google Consent Mode v2

FlowConsent implements Consent Mode v2 natively, without any extra template or plugin. Your integration snippet starts with an inline script that records the four denied defaults, wait_for_update: 500, url_passthrough and ads_data_redaction before any Google tag loads, and the banner sends gtag('consent', 'update', …) as soon as the visitor chooses. On refusal, Google tags stay in cookieless mode and send gcs=G100 pings, which the compliance scan recognizes as compliant. If a Google tag is queued before the defaults, the banner logs a console error naming it so you can remove it. With GTM, the snippet goes above the container, never inside it. The details are in the Google Consent Mode documentation and the Google Tag Manager installation guide. FlowConsent is free up to 25,000 sessions per month, hosted in Europe, and installs in about ten minutes.