GTM Consent Mode v2 Setup: Technical Guide

Last reviewed: 29 August 2026

The four parameters most implementations need to map are ad_storage, ad_user_data, ad_personalization, and analytics_storage. They are technical instructions to supported tags, not proof of valid consent. Google tags can have built-in checks and change their behavior based on those states. A Meta pixel, session-replay script, or hard-coded embed does not automatically obey Google's consent signals.

Choose Basic or Advanced implementation deliberately. In Basic Consent Mode, Google tags are blocked until the visitor interacts with the consent mechanism and grants the relevant consent. In Advanced Consent Mode, Google tags load with denied defaults and can send consent-state and cookieless pings. Whether either design is legally suitable depends on the technologies, purposes, jurisdictions, disclosures, and advice applicable to your organization.

What Consent Mode v2 does—and does not do

Consent Mode is an API and tag-behavior framework. Your website or CMP communicates consent states, and supported Google tags adjust accordingly. It does not collect a valid choice, classify every vendor, block every third-party script, or decide what the law permits.

The four commonly configured parameters have different jobs:

Do not treat these names as banner copy or universal legal categories. A CMP may offer “Analytics” and “Marketing,” while the implementation must translate those choices into the relevant Consent Mode states. Your inventory may also contain functionality, preference, security, or non-Google technologies that need separate controls.

Consent Mode state is not the same as consent validity. Tag Assistant can prove that a parameter changed from denied to granted; it cannot determine whether the banner gave sufficient information, whether the choice was freely given, or whether a particular operation qualifies for an exception. Keep the technical and legal reviews separate.

For more background before implementing, read Google Consent Mode v2 explained.

Before you edit the GTM container

Prepare the implementation outside the live container first. You need:

• Publish access to the correct GTM web container;
• Access to the website or CMP configuration that records and exposes choices;
• A list of Google and non-Google tags, including scripts outside GTM;
• A mapping from each banner purpose to the Consent Mode parameters and tag gates it controls;
• A staging environment, if available, or a controlled GTM Preview session on production;
• A test plan covering first visits, returning visits, refusal, acceptance, granular choices, and withdrawal.

If there is no staging site, use a dedicated GTM workspace and Preview mode. Limit tests to your browser, do not publish speculative changes, and avoid real purchases or leads. Preview requests can still reach vendors, so use vendor test modes or internal-traffic filters where available.

Before changing consent behavior, export the container and note hard-coded tags. GTM cannot gate a pixel embedded directly in a theme, plugin, bundle, or iframe. Follow the guide to blocking cookies before consent for those paths.

Step 1: Inventory tags and choose Basic or Advanced mode

In GTM, list each tag, trigger, vendor, purpose, storage behavior, and whether it sends a request before a choice. Inspect page source, browser requests, plugins, and embeds for technologies that bypass GTM.

Basic Consent Mode

In Google's current terminology, Basic Consent Mode prevents Google tags from loading before the visitor interacts with the consent mechanism. If the visitor denies consent, no data is sent to Google through those tags. If the visitor grants consent, the relevant tags load and send data with the granted state.

In GTM, Basic mode generally requires firing rules that hold Google tags until the required consent is granted. This is more than setting a denied default. A denied default with Google tags still loading is the Advanced pattern.

Advanced Consent Mode

In Advanced Consent Mode, Google tags load when the page or app opens. Before the visitor makes a choice, the default parameters are denied. Google states that tags send cookieless pings while consent is denied and use cookies when the relevant consent is granted. The exact fields and downstream use depend on the Google product and configuration.

Do not add an additional consent requirement to a Google tag merely because its built-in check mentions that consent type. Doing so can block the tag entirely while denied and change an intended Advanced setup into Basic-like behavior. Decide the mode first, then configure triggers and checks consistently.

Google documents modeling features and eligibility conditions, but no particular site should promise modeled results, recovery percentages, or a reporting outcome. Volume, product setup, consent implementation, and Google's eligibility requirements matter.

Make the decision with legal input

Advanced mode's denied-state requests are not the same as cookie storage, but “cookieless” does not automatically mean legally exempt or anonymous. Technical staff should document the actual requests and parameters. Legal or privacy reviewers should assess purposes, notices, contracts, applicable ePrivacy implementations, GDPR where personal data is involved, and other relevant laws.

This guide can verify whether the chosen technical design works. It cannot choose a lawful design for every region.

Step 2: Enable and use GTM's Consent Overview

In the web container, open Admin → Container Settings, enable Consent Overview, and save. Then return to Tags and open the Consent Overview from the shield icon.

The overview groups tags according to their consent configuration. It helps locate tags with built-in consent checks, tags with additional checks, and tags for which no consent configuration has been applied. Enabling the screen does not change runtime behavior. It is an audit view, not a blocking switch.

Review every tag rather than assuming a vendor template behaves a certain way. In a tag's Advanced Settings → Consent Settings, GTM may show:

• Built-in consent checks: consent types the tag template's code reads or responds to;
• Additional consent checks: consent types that GTM must see as granted before it fires the tag; and
• A choice to require no additional consent, require listed consent types, or leave the setting unconfigured, depending on the tag and interface.

Built-in and additional checks are not interchangeable. Built-in checks describe template behavior. Additional checks are firing requirements you impose. An additional check does not teach a third-party script how to change behavior after it loads; it stops the tag from firing until the condition is satisfied.

Step 3: Set the default consent state first

A consent default establishes the state used before the CMP has a choice. In GTM, consent-aware templates should use the Consent Initialization – All Pages trigger. Google created this trigger so consent settings can be established before other triggers, including the ordinary Initialization trigger.

Prefer a CMP's verified GTM Community Template Gallery template or a purpose-built custom template that uses GTM's consent APIs. In a custom template, Google documents setDefaultConsentState for defaults and updateConsentState for updates. A Custom HTML tag can push gtag() commands, but a maintained consent template offers clearer permissions and is the recommended integration pattern for CMP providers.

For a direct gtag.js implementation outside a GTM custom template, the conceptual default looks like 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',
  wait_for_update: 500
});
</script>

This example is intentionally conservative and global. It demonstrates the command and its ordering; it is not a substitute for your CMP's documented installation. The default must run before Google configuration or event commands that depend on it.

Understand wait_for_update

wait_for_update tells Google tags to wait for a consent update for the specified number of milliseconds before sending data. Google uses 500 milliseconds in its implementation guidance as an example. It is not a banner timeout and does not turn denial into grant. If no update arrives within that period, tags continue using the default state.

Use it only on a default command. Keep the interval long enough for the CMP to retrieve a stored choice under normal conditions, but do not use a large delay to hide a slow or incorrectly ordered integration. Measure CMP initialization on representative devices and fix the cause of delayed updates.

Configure regional defaults carefully

Consent Mode supports the region field with ISO 3166-2 region codes. A region-specific command applies only to visitors from those regions. Google documents that the most specific regional command takes precedence when commands overlap; a default without region applies to all visitors not covered by a more specific command.

For example, a team with an approved region policy could use a restricted default for selected regions and a separate global fallback:

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  region: ['AT', 'BE', 'DE', 'FR', 'NL'],
  wait_for_update: 500
});

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

This code explains precedence; it is not a recommended legal geography. Do not copy a list labeled “EU,” “EEA,” “US,” or “rest of world” and assume all visitors in it can receive granted defaults. Rules can differ by country, state, purpose, technology, age, contract, and product configuration. Have the region policy approved, keep the list maintained, and test from the relevant locations.

If your CMP performs geolocation, establish one owner for region logic. Competing defaults from the CMP, inline code, and GTM can make the outcome difficult to predict and audit.

Step 4: Send an update from the visitor's choice

The update command communicates the consent state after the CMP has resolved a new or stored choice. It is not another default. Send an update as soon as possible on the page where the visitor chooses, and make changed or withdrawn preferences available to tags.

An analytics-only choice might map as follows:

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

An “accept all” choice would grant all four parameters only if that is what the interface actually disclosed and recorded. A refusal should explicitly keep the relevant parameters denied. Do not omit a parameter and assume it inherited the banner category you intended.

For returning visitors, follow the CMP's documented integration. The essential result is that the stored choice is applied early enough on each page load. Depending on the CMP template, that may mean deriving the initial default from a stored choice or issuing an early update after the denied default. Do not invent a second banner interaction just to restore state.

When a visitor withdraws consent, send an update with the affected values set to denied and prevent later gated tags from firing. Also assess data already stored in the browser. Consent Mode updates tag behavior prospectively; they do not by themselves guarantee that every vendor cookie already present is deleted. Use the CMP and vendor-supported cleanup mechanisms where required.

Avoid GTM Tag Sequencing as the primary consent-ordering mechanism. Sequencing arranges setup and cleanup tags around a main tag; it does not replace the Consent Initialization event or the consent APIs. A setup tag can also fail, be paused, or have different firing semantics. Use consent initialization for the default, CMP events for updates, and consent checks or triggers for gating.

Step 5: Configure Google and non-Google tags correctly

Open each tag and inspect its template and consent settings.

Google tags and built-in consent checks

Google tags have built-in checks for relevant consent types and adjust supported behavior based on consent state. The exact built-in list differs by tag type. Use the list shown in GTM rather than assuming every Google tag uses all four parameters in the same way.

For an Advanced setup, allow the Google tag to use its built-in behavior unless Google's product instructions require something else. For a Basic setup, add the documented consent-based firing controls so the tag does not load until the relevant grant. Confirm the result in Preview rather than inferring it from configuration labels.

Non-Google tags and additional consent checks

Most Custom HTML and third-party pixel tags do not interpret Consent Mode automatically. For each one:

1. Open Tags and select the tag.
2. Open Advanced Settings → Consent Settings.
3. Select the option to require additional consent for the tag to fire.
4. Add the consent type or types from your approved purpose mapping.
5. Save, then verify the tag in Consent Overview.

Do not copy a universal mapping such as “every ad pixel needs exactly ad_storage.” A third-party advertising integration may transmit user data, read browser storage, or support more than one purpose. ad_user_data and ad_personalization are Google Consent Mode parameters; a non-Google vendor does not gain native understanding of them because you use those labels as GTM gates. The check simply requires the named GTM state before the tag fires.

A defensible working table records decisions rather than pretending the labels decide them:

Additional checks affect only GTM-managed firing. Audit direct scripts, server-rendered embeds, plugins, tag chains, and scripts injected by other tag managers separately.

Step 6: Test with GTM Preview and Tag Assistant

Publish only after a repeatable preview test. Start with a fresh browser profile or clear site data between scenarios. Disable extensions that alter requests, note the region and browser, and open DevTools before navigation.

Verify the default before clicking the banner

Connect GTM Preview to the target URL. In Tag Assistant, select the earliest consent-related event and open the Consent view. Confirm that:

• A default was set before ordinary page-view and Google tag events;
• All four expected parameters have the intended initial values;
• The source of the consent event is the expected CMP or consent tag;
• Basic-mode tags have not loaded, or Advanced-mode Google tags show denied consent as designed; and
• Non-Google tags requiring consent have not fired.

Tag Assistant labels and layout can evolve, so rely on event order and state rather than a memorized screenshot. Select successive events to see whether the state changed and which tags fired or were blocked at each point.

Verify each interaction path

Run at least these isolated scenarios:

1. No interaction: wait beyond wait_for_update; confirm the default remains effective.
2. Reject non-essential: confirm all relevant states remain or become denied and gated tags stay blocked.
3. Accept analytics only: confirm only the mapped analytics state changes and advertising tags remain blocked.
4. Accept advertising where offered: confirm the specific ad-related states update according to the recorded choice.
5. Change or withdraw: reopen preferences, deny a previously granted category, and confirm the update.
6. Returning visit: open a new page or session with the saved choice and confirm it is applied without an unintended granted or denied interval.

An update event alone is not enough. In Tag Assistant, inspect Tags Fired and Tags Not Fired for the relevant event. Confirm that tags fire once when intended, not once before the update and again afterward.

Confirm browser behavior

Use DevTools Network and Application/Storage alongside Tag Assistant. Network evidence shows whether a browser contacted a vendor; storage evidence shows cookies and other browser storage. For each scenario:

• Preserve the network log and reload;
• Filter by the actual vendor hostnames in your inventory;
• Inspect request timing relative to the choice;
• Check cookies, local storage, and relevant iframe storage;
• Repeat on routes with forms, videos, checkout, and campaign tags.

In Advanced mode, a Google request while consent is denied can be expected behavior. Do not write a test that says “no Google request equals success” unless you chose Basic mode. Instead, inspect the consent state, request behavior described in Google's documentation, and absence or presence of storage. Conversely, a request to an unapproved non-Google pixel before consent may reveal missing gating.

Step 7: Diagnose Consent Mode problems

Defaults appear after Page View

Likely cause: the default tag uses Page View, Initialization, or a custom event rather than Consent Initialization, or inline Google code runs before GTM.

Fix: move the supported consent template to Consent Initialization – All Pages and inspect all inline scripts. In Tag Assistant, verify the consent default precedes events that configure or invoke dependent tags.

Consent remains denied after acceptance

Likely cause: the CMP never sends an update, maps the category incorrectly, or pushes a data layer event that no consent template handles.

Fix: select the banner event in Tag Assistant and look for a consent update. Compare all four values with the recorded CMP choice. A normal dataLayer.push() event is not itself a Consent Mode update unless a tag processes it.

Returning visitors revert to the default

Likely cause: the CMP saves the choice but restores it too late, uses inaccessible storage, or does not communicate it on every page.

Fix: inspect storage and the earliest events on a new page load. Follow the CMP's documented stored-choice flow and confirm it works across routes, not only after the initial banner click.

A non-Google tag still fires before consent

Likely cause: the tag has no additional check, another trigger bypasses the intended rule, or the same script exists outside GTM.

Fix: inspect Consent Overview, all triggers attached to the tag, page source, network initiators, plugins, and other containers. Apply a GTM gate only where GTM controls the tag; block or defer other copies at their source.

A Google tag sends no denied-state ping

Likely cause: the implementation is Basic, an additional consent check blocks the tag, or its trigger never fires.

Fix: compare the actual setup with the intended mode. If Advanced was intended, inspect additional checks and triggers without blindly removing controls. Confirm the decision with the implementation and privacy owners.

Consent states conflict or change unexpectedly

Likely cause: multiple CMPs, inline commands, region defaults, and GTM templates all write consent.

Fix: search the codebase and container for consent commands and templates. Establish one authoritative flow for defaults and updates. Do not assume there must be literally one command: valid regional configurations can contain multiple default commands, and granular interactions can produce multiple updates.

For a broader post-release review, use the website cookie audit guide.

Step 8: Publish and maintain the setup

Name the GTM version clearly, record the approved mode and region policy, and publish through your normal change process. Immediately repeat the critical tests against the live container because environment variables, content-security policies, CMP domains, and production-only scripts can differ.

Keep a small implementation record:

• Container version and publication date;
• CMP and template version;
• Default and update owner;
• Basic or Advanced mode by product and region;
• Purpose-to-parameter and tag-gate mapping;
• Tested URLs, browsers, regions, and consent paths;
• Known exceptions and follow-up owner.

Re-test after adding a tag, changing a banner category, updating the CMP, modifying region logic, deploying a new template, or changing Google product settings. Consent configuration is part of release management, not a one-time installation.

A free website scan can identify storage and requests worth investigating, but cannot verify every conditional route or provide a legal conclusion. When evaluating a platform, compare its GTM template, stored-choice behavior, regional controls, withdrawal flow, and audit trail. See cookie consent best practices for the wider review.

Technical verification versus legal judgment

Technical verification can establish event order, parameter values, tag firing, requests, storage, and whether the observed behavior matches the documented configuration. These are factual questions suitable for Tag Assistant, browser tools, container review, and repeatable test cases.

Legal judgment asks whether consent is required, whether a purpose is sufficiently specific, whether an exception applies, whether the interface supports a valid choice, and which regional rules govern. Those conclusions require the actual processing facts and applicable law. A technically correct Consent Mode deployment can still sit behind an inadequate notice or an invalid choice. A legally approved policy can still fail because a tag fires too early.

Document both reviews and their owners. Do not describe Tag Assistant's green indicators, a CMP badge, or a scanner result as a guarantee of compliance.

Sources

• Google for Developers — Set up consent mode on websites
• Google for Developers — Consent mode overview
• Google Tag Manager Help — Consent mode
• Google for Developers — Troubleshoot consent mode with Tag Assistant
• Google for Developers — Create a consent mode template
• EUR-Lex — Directive 2002/58/EC, Article 5
• EUR-Lex — GDPR, including Articles 4(11) and 7