Google Consent Mode v2 Setup with Google Tag Manager: Step-by-Step Guide

Short answer: Google Consent Mode v2 is the signaling layer that tells Google tags (GA4, Google Ads, Floodlight) what a visitor has or has not consented to. A correct Google Tag Manager setup comes down to five steps: fire a denied default for all four signals on GTM's Consent Initialization trigger, send an update the moment the visitor chooses in the banner, review each tag's built-in consent settings, add regional defaults if you serve several markets, and verify the flow with Tag Assistant and the gcs parameter. Since March 2024, Google requires the two v2 signals, ad_user_data and ad_personalization, from advertisers who want to keep personalization and remarketing features for EEA and UK traffic.

Most Consent Mode failures come from two commands firing in the wrong order, or from a banner that never talks to the data layer at all. This guide builds the setup from scratch in Google Tag Manager, in the order the browser needs it. For the conceptual background (what the signals mean and what Google does with them), see our Google Consent Mode overview; this article stays hands-on.

Note: This article is technical documentation, not legal advice. Whether and how you need consent for specific cookies depends on the laws that apply to your audience; consult a qualified lawyer for decisions about your specific situation.

Table of contents

• What Consent Mode v2 is and when you need it
• The four v2 signals explained
• Step 1: Set the default consent state before any Google tag
• Step 2: Wire your CMP banner to send the update call
• Step 3: Configure tag consent settings in GTM
• Step 4: Regional defaults for multiple markets
• Step 5: Verify with Tag Assistant and DevTools
• Basic vs Advanced mode: what each sends
• How cerez.io automates the wiring
• Frequently Asked Questions
• Sources

What Consent Mode v2 is and when you need it

Consent Mode is not a banner and it does not collect consent. It is an API with exactly two commands: gtag('consent', 'default', ...) declares what Google tags may do before the visitor has chosen, and gtag('consent', 'update', ...) revises that state the moment a choice is made. Google tags read these signals and adjust their behavior: with analytics_storage denied, GA4 does not write its _ga cookie; with ad_storage denied, ad tags stop storing click identifiers.

Version 2, announced in late 2023, added two signals to the original pair, largely to align with the EU's Digital Markets Act. Since March 2024, Google has required valid v2 signals from advertisers who want to keep audience building, remarketing and ad personalization for EEA and UK traffic; without them, those features degrade for that traffic.

Who actually needs this:

• You run Google Ads with EEA or UK visitors: you need Consent Mode v2. This is a Google platform requirement, separate from your legal obligations.
• You run GA4 only: Google imposes no enforcement deadline, but consent-first laws (ePrivacy and GDPR in the EU, KVKK in Turkey) still require consent before non-essential cookies are set; Consent Mode is the standard way to make Google tags respect that choice.
• You have no Google tags at all: you do not need Consent Mode, but you still need consent management for whatever tags you do run.

One more caveat before the steps: Consent Mode transmits consent, it does not make your site compliant by itself. The banner that collects the choice, the texts that explain it and the records that prove it are separate work.

The four v2 signals explained

Each signal takes the value granted or denied and controls a distinct behavior in Google's tags:

Three supporting signals sit outside the March 2024 requirement: functionality_storage (preferences such as language), personalization_storage (on-site personalization) and security_storage (fraud prevention, CAPTCHA); declaring them in your default keeps the setup complete.

Mapping to a typical banner: an "analytics" or "statistics" category maps to analytics_storage; a "marketing" category maps to ad_storage, ad_user_data and ad_personalization together; strictly necessary functions usually keep security_storage granted.

Step 1: Set the default consent state before any Google tag

The most important rule in the entire setup: the default command must run before any Google tag. A tag that loads without finding a default behaves as if consent handling does not exist.

In GTM, create a new Custom HTML tag with this content:

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

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

Attach it to the Consent Initialization - All Pages trigger, which exists for exactly this purpose: it fires before every other trigger in the container, including Initialization and Page View. Do not attach the default to a normal Page View trigger; on a slow page your GA4 tag can beat it, and the setup silently fails.

Two details worth knowing:

• wait_for_update: 500 tells Google tags to hold measurement for up to 500 ms if an update may arrive quickly, so a returning visitor's replayed choice already applies to the first pageview.
• If your CMP ships an official GTM template, you can use it instead of Custom HTML. The requirement does not change: the template must fire on Consent Initialization.

Step 2: Wire your CMP banner to send the update call

When the visitor makes a choice in the banner, your consent tool must translate it into an update command:

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

The values follow the actual choice:

• Analytics accepted: analytics_storage: 'granted'
• Marketing accepted: ad_storage, ad_user_data and ad_personalization granted
• Everything rejected: all four signals explicitly denied

Three implementation notes that prevent most real-world failures:

1. Send the update on reject too. An explicit denied update ends the wait_for_update window immediately and leaves a clean, verifiable signal trail; skipping it is a common source of confusing test results.
2. Persist and replay. Store the choice (CMPs use their own cookie for this) and resend the same update early on every later page load, so returning visitors are measured by their recorded choice.
3. Use the real gtag pattern. Consent commands must go through function gtag(){dataLayer.push(arguments);}. Pushing a plain event object into the data layer is not equivalent, and Google tags will not see the signal.

If your CMP has a GTM template, it handles this wiring through its settings; with a hand-written banner, attach the update calls to the accept, reject and save-preferences callbacks yourself.

Step 3: Configure tag consent settings in GTM

Google's own tags have built-in consent checks: GA4 and Ads tags automatically adjust their behavior to the signals, so you do not need blocking triggers for them. Still verify the configuration and cover everything that is not a Google tag:

1. Open any tag and expand Advanced Settings > Consent Settings.
2. The built-in checks are listed there; for example, a GA4 tag declares that it reacts to ad_storage and analytics_storage on its own.
3. Under Additional consent checks, choose "Require additional consent for tag to fire" and list the signals that must be granted before the tag fires. This is the right tool for non-Google tags such as Meta Pixel, Hotjar or LinkedIn Insight, which ignore Google's signals entirely.

Also enable Consent Overview in Admin > Container Settings: it adds a shield icon to the tag list and a per-tag audit view that makes tags with no consent configuration easy to spot before publishing.

Know the limits: consent checks only govern tags inside GTM. Scripts hard-coded into page templates and third-party iframes never pass through the container and need a separate blocking mechanism. A quick run with a free cookie scanner shows which cookies your pages actually set, so you can confirm each sits behind a consent check or a script blocker.

Step 4: Regional defaults for multiple markets

The default command accepts a region parameter, which lets you vary the starting state by the visitor's location:

<script>
// General default for all visitors
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500
});

// Example: an additional default scoped to one market
gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'region': ['TR']
});
</script>

The rules: a region-scoped default overrides the general one for matching visitors, the more specific definition wins, and region codes follow ISO country codes (subdivisions are supported). Always define the region-free default first, so no visitor arrives with no state at all.

A pragmatic recommendation: most multi-market sites simply run default denied globally. It is defensible everywhere and removes a whole class of region-matching bugs; regional defaults earn their complexity only with heavy traffic from markets with genuinely different consent models. Turkey and the EU, for example, are both consent-first, so denied defaults fit both; the real differences sit in banner UX, disclosure language and transfer paperwork, and our KVKK vs GDPR comparison covers those point by point.

Step 5: Verify with Tag Assistant and DevTools

Never publish a consent change unverified. Run the container in Preview mode and work through three checks.

1. Tag Assistant Consent tab. Connect your site through tagassistant.google.com and open the Consent tab. You should see the default registered at the Consent Initialization stage, before any tag fires, and an update row with the expected values after you interact with the banner.

2. GTM Preview event order. The event stream should read Consent Initialization first, then Initialization, then Container Loaded and the rest. If your default tag or CMP template fires later than Consent Initialization, go back to Step 1.

3. DevTools gcs quick check. Open the Network tab, filter for collect, and inspect requests to google-analytics.com/g/collect. The gcs parameter encodes the two core signals as "G1" plus two digits: the first is ad_storage, the second analytics_storage (1 = granted, 0 = denied).

Test all three scenarios in an incognito window: accept all (gcs flips to G111), reject all (gcs stays G100, but Tag Assistant should still show a denied update), and a partial choice. Also confirm in Application > Cookies that no _ga cookie exists before a choice is made. A richer gcd parameter carries all four signals including the v2 pair; Tag Assistant's Consent tab presents the same information in readable form, safer than decoding the raw value by hand.

Basic vs Advanced mode: what each sends

Basic and Advanced are two deployment patterns for the same API, and the choice affects both data flows and reports:

Either way, reported users and sessions will be lower than in a pre-consent setup that measured everyone: the drop is not a malfunction, it is the difference between measuring everyone and measuring people who agreed. In Advanced mode, Google's modeling can fill part of the gap once volume thresholds are met; low-traffic sites may never see modeled data. Pick Basic for the most conservative flow, Advanced if modeled measurement matters to your marketing, and record which one you chose.

How cerez.io automates the wiring

All of this can be built by hand. The realistic failure mode is drift: the update mapping breaks when banner categories change, a new tag ships without a consent check, or a redesign reorders the head scripts and the default quietly loses its first place.

cerez.io Cookie Consent ships this wiring in its SDK: a single snippet sets the denied default for all four v2 signals before Google tags run and sends the update automatically when the visitor chooses, mapped from banner categories to the four signals. Category-based script blocking covers non-Google tags, the installation screen includes a GTM guide with the Consent Initialization sequence, a preview mode lets you test banner changes before they go live, and automatic scanning keeps the cookie inventory current. These tools help you implement, measure and document the consent flow; the legal assessment of your specific setup remains work for you and your counsel.

Frequently Asked Questions

Do I need Consent Mode if I do not run Google Ads?

Short answer: Google's March 2024 requirement targets advertisers using ad personalization and remarketing for EEA and UK traffic, so a GA4-only site faces no Google enforcement deadline. You still need consent for analytics cookies under consent-first laws such as GDPR with ePrivacy and Turkey's KVKK; Consent Mode is the cleanest way to make GA4 honor it. If you run ads later, building now avoids a retrofit under deadline pressure.

What is the difference between Basic and Advanced mode?

Short answer: In Basic mode, Google tags do not load until the visitor grants consent, so Google receives nothing from visitors who decline. In Advanced mode, tags load immediately with denied defaults and send cookieless pings, which can feed Google's modeling once eligibility thresholds are met. Basic is the more conservative flow; Advanced trades some data transmission for partially modeled reporting.

Why did my GA4 numbers drop after setup?

Short answer: Because visitors who decline are no longer tracked with cookies, which is exactly what the setup is supposed to do. Compare the drop with your banner's rejection rate: if they roughly match, the installation is working. Modeled data can recover part of the gap in Advanced mode on sites with enough traffic. The wrong fix is flipping defaults to granted; the legitimate lever is improving the banner experience so more visitors actively consent.

Does Consent Mode replace a consent banner?

Short answer: No. Consent Mode is only the messenger: it tells Google tags what the visitor chose, but something must collect that choice first. You still need a banner that blocks non-essential scripts until a decision is made, offers a real reject option and records the consent event. Consent Mode without a banner leaves a permanent denied default at best; a granted default without real consent creates exactly the exposure the setup is meant to avoid.

Sources

• Google Consent Mode developer documentation
• Google Tag Manager developer documentation
• Regulation (EU) 2016/679 (GDPR), full text
• ePrivacy Directive 2002/58/EC, full text
• Turkish Personal Data Protection Authority (KVKK)

Prefer not to hand-maintain consent plumbing? Start free and add the cerez.io snippet in minutes: the Consent Mode v2 default and update signals are wired automatically, no credit card required. Plan details are on the pricing page.