Google Consent Mode v2: Setup Guide and the June 2026 Change

Two of those four signals, ad_user_data and ad_personalization, arrived in November 2023. Since March 2024, Google Ads has required them for remarketing and conversion measurement in the European Economic Area, the United Kingdom, and Switzerland. Then, on June 15, 2026, Google changed which setting actually governs the data. Most setup guides still describe the old behavior, so that change is worth taking first.

What changed on June 15, 2026

Before that date, two separate settings jointly decided whether Google Ads received advertising cookies and identifiers from your site: the Google Signals toggle inside Google Analytics, and your Consent Mode settings. Both had to permit it.

As of June 15, 2026, Google's own documentation says Analytics "will transition to using Consent Mode (within Google Ads) as the single control for data", and that privacy choices managed via Ads Consent Mode settings "will exclusively govern how data is collected and used". The Google Signals setting keeps a narrower job: associating your Analytics data with signed-in users for behavioral reporting. Google's notice is published in Updates to Google Analytics Data Controls.

The practical consequence is simple. If you were relying on the Google Signals toggle to hold advertising data back, that lever is gone. Your Consent Mode configuration is now the only thing between a visitor's choice and Google Ads.

The Consent Mode signals, and what each one does

Consent Mode v2 defines four signals that matter for advertising and analytics, plus three more that cover the rest of a site's storage. A consent tool maps its categories onto all seven.

Basic mode or advanced mode?

Consent Mode has two implementations, and the choice is a legal one before it is a technical one.

ConsentStack defaults to basic mode for Google tags. The tag stays blocked until someone accepts, so no request reaches Google before that, and the four signals are still set up front so a tag that does load already knows what the visitor chose. The trade-off is honest: you give up the extra modeling that pre-consent pings would have fed Google. We default that way because a request before consent is still a request, and not every regulator or privacy counsel treats that as equivalent to silence. Choose on the legal position you are willing to defend, not on which one reports better numbers. One exception is a Google tag served from your own domain through Google Tag Gateway, covered below.

The legal side of that choice is covered in our guide to whether Google Analytics is GDPR compliant, which also reports how often 2,208 scanned sites sent data to Google before consent.

How to set up Consent Mode v2

There are two routes, and which one applies depends on whether you already have a consent banner.

If you use a consent management platform, the platform does this for you. Cookiebot, CookieYes, Complianz and ConsentStack all set the defaults and fire the update call when someone chooses. Your job is to confirm the defaults are denied and that the platform's script loads before your Google tag, not after.

If you are wiring it by hand, Consent Mode is two gtag calls. The first sets defaults and has to run before any Google tag loads, which in practice means above your Google Tag Manager or gtag.js snippet in the head:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }

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

  gtag('set', 'ads_data_redaction', true);
  gtag('set', 'url_passthrough', true);
</script>

The three settings in that first call are the ones people search for by name. Here is what each one does, and what ConsentStack sets.

The second call runs when someone makes a choice, and sends only what they agreed to:

gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
});

Send the same call with 'denied' values for anything the visitor declined. Sending the update call at all is what distinguishes a working setup from a site that silently runs on defaults forever.

How ConsentStack handles it

ConsentStack sets the defaults, fires the update call, and maps its four consent categories onto all seven Consent Mode types automatically. There is no Consent Mode add-on to buy and nothing to configure: it behaves the same on the free plan as on paid ones. The details are in the platform integrations documentation.

Concretely, the SDK denies all four v2 signals by default, keeps functionality_storage and security_storage granted, sets wait_for_update to 500 milliseconds, and turns on both ads_data_redaction and url_passthrough. When a visitor chooses, marketing consent maps to ad_storage, ad_user_data and ad_personalization together, and analytics consent maps to analytics_storage.

What Google Tag Gateway changes

Google Tag Gateway for advertisers serves the Google tag from your own domain instead of googletagmanager.com. Your CDN or load balancer reserves a path on your site, loads the tag script from there, and forwards measurement requests to Google through the same path. Google's stated reasons are conversion uplift and fewer third-party interactions. In practice, a tag that loads from your own domain is much harder for ad blockers and browser tracking protection to catch. Cloudflare offers it as a one-click setting for any domain it proxies, and Google Cloud Load Balancer and other CDNs can do the same.

That is also what it changes for consent. Most consent tools, ConsentStack included, hold Google tags back by recognizing the domain they load from. A tag loaded from your own domain is not on that list. Google's own setup notes say it plainly: enabling the gateway "affects Google tag firing behavior", and "if you use consent mode, you must turn off automated script set up".

Tag Gateway with ConsentStack, exactly as it behaves

ConsentStack's request fence treats a request to your own hostname as first-party and lets it through before any tracker rule is checked. That is deliberate, since your own site has to work. It also means a Google tag served through Tag Gateway is not held back the way one from googletagmanager.com is. With the gateway on, the Google tag runs in what Google calls advanced mode, whether or not that was the plan.

What still holds is the consent state. The ConsentStack snippet pushes the denied defaults for all four v2 signals, with wait_for_update set to 500 milliseconds, at the moment the browser parses it, before any script placed below it runs. A gateway-served tag that loads after the snippet reads those defaults, sends cookieless pings while consent is denied, and receives the update call when the visitor chooses. If the visitor declines, the update repeats the denials. The gateway changes where the tag comes from. It does not change what Consent Mode tells it.

So the rule with ConsentStack is the rule Google gives: keep the ConsentStack snippet above the Google tag in the head, place the tag yourself, and switch off the CDN's automated tag setup. The free compliance scan reads the consent state the Google tag itself records on the page, both the dataLayer and the tag's internal consent state, rather than only watching for googletagmanager.com, so it can tell you whether the denied defaults were in place when the tag ran.

How to tell whether Tag Gateway is on

Open your site's HTML source and look at the Google tag's script address. A standard tag loads from googletagmanager.com. A gateway tag loads from a path on your own domain, usually with the same ?id=G-, ?id=GTM- or ?id=AW- identifier at the end. In the browser's network panel the measurement hits show the same pattern: requests carrying /g/collect that go to your own domain on the reserved path rather than to google-analytics.com. Google's tag settings screen also lists the domains where the gateway is active. If you find it on and never turned it on, check the CDN dashboard first. Cloudflare enables it at the zone level, for every hostname and subdomain at once.

Is Google Consent Mode v2 mandatory?

Not universally. Google Ads requires valid consent signals for remarketing and for measuring conversions from users in the European Economic Area, the United Kingdom, and Switzerland, and those features degrade without them. Outside those regions nothing forces it. It is still the only supported way to tell Google tags what a visitor consented to, so most sites end up implementing it anyway.

What is the difference between Consent Mode v1 and v2?

v1 sent two signals, ad_storage and analytics_storage. v2 keeps both and adds ad_user_data and ad_personalization. The addition matters because it separates two questions that v1 bundled together: whether your data may be sent to Google at all, and whether it may be used to personalize advertising. A visitor can now permit the first and refuse the second.

How do you check Consent Mode v2 is actually working?

The common failure is not a wrong value, it is an update call that never fires, or a default block that loads after the Google tag and therefore does nothing. Both look fine in the banner and wrong in the data.

In Google Tag Manager, use Preview mode and watch the consent state on each tag as you accept and decline. In the browser console, inspect window.dataLayer for the consent entries and confirm both the default and the update appear, in that order. Google Tag Assistant shows the same state per tag.

For an outside view, our free Google Analytics consent checker loads your site the way a visitor would, and our testing and verification guide walks through checking each signal by hand.