Published August 15, 2026 · 10 min read · RegSentry blog
Google Consent Mode v2 is how Google's tags — Analytics, Ads, and anything else riding through gtag or Tag Manager — learn whether a visitor has consented. Set up correctly, tags hold their fire until consent arrives. Set up almost-correctly, everything looks fine in Tag Manager while tags fire exactly as they always did — and "almost correctly" is the most common state we find in the wild. This guide walks the full setup, in order, with the verification step most guides skip.
Consent Mode is a signaling layer. Your site declares a consent state for a handful of named categories, and Google's tags read that state and adjust their behavior. The v2 part refers to two signals Google added for its advertising tags: ad_user_data and ad_personalization, on top of the original ad_storage and analytics_storage. Google requires these v2 signals for features like remarketing audiences to work for traffic from regions where they apply.
Two things Consent Mode is not: it is not a consent banner (you still need a consent management platform to ask the visitor), and it does not govern non-Google tags by itself — though Tag Manager's consent settings, covered below, extend the same mechanism to any tag in your container.
One more distinction worth knowing before you configure anything: Consent Mode has two flavors. Basic means tags are fully blocked until consent — nothing loads, nothing is sent. Advanced means Google's tags load even when consent is denied but send cookieless "pings" instead of full hits, which Google uses for conversion modeling. Advanced is the default behavior when you simply set defaults to denied and let the tags load; Basic requires you to also hold the tags back. If your goal is "no tracker contacts its server before consent" — the standard that pre-consent tracking claims are measured against — understand that Advanced mode still sends those denied-state pings, and decide deliberately which posture you want.
The consent default must execute before the GTM container (or gtag.js) loads. This ordering is the single most common failure: if the container loads first, tags can fire in the gap, and no amount of later configuration takes those requests back.
<!-- Consent Mode v2 defaults. Place in <head>, BEFORE the GTM container
snippet (or before gtag.js). Nothing may load ahead of this. -->
<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: 'denied',
personalization_storage: 'denied',
security_storage: 'granted',
wait_for_update: 500
});
</script>
Notes on the pieces:
security_storage stays granted — it covers things like fraud-prevention essentials that consent regimes treat as strictly necessary.wait_for_update: 500 tells tags to hold up to 500ms for your CMP to deliver a stored consent state (for returning visitors who already chose), avoiding a flash of denied-state behavior before the real state arrives.region parameter on additional gtag('consent','default',…) calls. If in doubt, one global denied default is the simple, conservative choice.When the visitor makes a choice, your CMP must tell Google by calling gtag('consent','update',…) with the categories the visitor granted:
// Your CMP calls this from its "visitor accepted" callback.
// Grant only the categories the visitor actually accepted.
gtag('consent', 'update', {
ad_storage: 'granted',
ad_user_data: 'granted',
ad_personalization: 'granted',
analytics_storage: 'granted'
});
In practice you rarely write this by hand: every major CMP — Cookiebot, OneTrust, CookieYes, Termly, Usercentrics, Osano, Iubenda and others — has a Google Consent Mode integration that maps its own categories (marketing, statistics, preferences) onto Google's signals and fires the update for you. The failure mode is simply that the toggle was never turned on: the banner records the choice in its own cookie and Google never hears about it, so tags run on defaults forever. Find the integration setting in your CMP and enable it.
Google's own tags (GA4, Google Ads) have built-in consent checks — they automatically respect analytics_storage and the ad signals. Third-party tags in your container do not. This is what GTM's tag-level consent settings are for:
ad_storage for ad pixels (Meta, TikTok, LinkedIn), analytics_storage for analytics and replay tools.Two supporting settings worth knowing: ads_data_redaction (when true and ad_storage is denied, further strips identifiers from any ad pings) and url_passthrough (carries click information through page URLs when cookies are denied). Both are optional refinements, set via gtag('set', …).
Every step above can be configured and the setup can still fail — a hardcoded snippet outside GTM, a duplicate pixel from a platform integration, a CMP category mapped wrong. The only trustworthy test is watching the network:
collect, facebook, doubleclick, tiktok. In a Basic setup, nothing should appear. In an Advanced setup, GA hits should carry gcs=G100 — the parameter that says consent was denied when the ping was sent — and no third-party tags with consent requirements should fire at all.After any Consent Mode change, verify from outside your own assumptions: our free checker loads your site in a real browser with the banner unanswered and lists every tag that contacted its server anyway — the same view a plaintiff-side scanner gets.
See what fires on your site before visitors consent — free, 30 seconds, no signup.
Real browser scan, no signup to run it. You see a summary of the findings; the full report with every tracker unlocks with your email.
If you'd rather have the site watched continuously — with an email the moment a new tracker appears — that's what monitoring is for ($99/mo, cancel anytime).