Web tracking introduction

Google Consent Mode explained

Updated 28 October 2026

TL;DR

Consent Mode is required when you use Google Analytics 4 or Google Ads with traffic from the European Economic Area. It works out of the box with Google tags for those services, and it can be adapted to other platforms such as the Meta (Facebook) Pixel. It does not replace a full Consent Management Platform, but when implemented correctly it can be the only, lightweight consent solution, without tricky tag-blocking techniques.

What is Consent Mode?

Consent Mode is an extension of the dataLayer, a core part of all Google tracking scripts (both Google Tag Manager and the Google tag). It adds two dedicated actions and a set of standard parameters, called consent types, that have a special meaning for Google services. In Google Tag Manager they work like an additional trigger condition that can be applied to any tag.

Quick example

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', { ad_storage: 'denied' });

Actions

• default sets the default values of the consent types.
• update should be sent as soon as the user gives (or changes) their consent.

Consent types

• analytics_storage: storage of user identifiers (cookies, localStorage, device identifiers) for analytics purposes
• ad_storage: storage for advertising purposes
• ad_user_data: whether user data may be sent to Google for advertising purposes
• ad_personalization: whether data may be used for personalised advertising (remarketing)
• functionality_storage: storage that supports website functionality, such as language settings
• personalization_storage: storage for personalisation, such as recommendations
• security_storage: storage for security purposes, such as authentication and fraud prevention

Each consent type can be set to either granted, meaning the user agreed to that type of data storage and processing, or denied, the opposite.

As a result, the most basic Consent Mode entry in the dataLayer looks like this:

[
  'consent',
  'default',
  { ad_storage: 'granted', analytics_storage: 'denied' }
]

The first parameter is always consent. The second says whether this is the default state or the one the user provided (update). The third is an object with the consent types and their states.

That’s it!

What is Consent Mode v2?

In November 2023 Google announced an upgrade of the framework, Consent Mode v2, which became mandatory for using its advertising platform with EEA traffic.

It sounds like a significant update (a second major version, after all), but it basically adds two advertising-related consent types, already listed above:

• ad_user_data
• ad_personalization

These new consent types are a more specific and precise way to tell Google APIs how to process user data for advertising purposes.

As on many other platforms, you can opt in to personalised ads by agreeing to more precise tracking. If you don’t agree, you still see ads, just possibly less relevant ones. Before Consent Mode v2 this fine-grained choice could not be expressed.

How does it work?

Consent Mode does two things for you.

Changes the behaviour of Google tags

This happens automatically as soon as you implement Consent Mode on your website. It only affects Google tags (Google Analytics 4 and Google Ads), whether you installed them directly or through Google Tag Manager. It does not change the behaviour of other tracking tags, such as the Meta Pixel.

Introduces consent checks

Consent Mode added dedicated UI elements to the GTM workspace.

The first is in the advanced settings of the tag configuration screen. It lets you decide that a tag should only fire after a certain consent type is granted: these checks work like a special type of trigger.

The second is the Consent Overview, which you enable in the container settings. It lists all tags in the workspace with their consent checks and lets you apply new consent checks to one or more tags in bulk.

What doesn’t it do?

Google Consent Mode does not interact directly with cookies, and it does not handle complex tag firing sequences. You can implement Consent Mode and get it somewhat working, but still be non-compliant with cookie-related privacy regulations, or have tags fire in the wrong order and lose data as a result.

Consent user interface

Before getting into cookie handling and tag sequencing: Consent Mode, as a dataLayer extension, has no user interface.

In other words, it does not include a consent or cookie banner that actually captures the user’s consent. It is up to you to build or install such a banner and connect it to Consent Mode.

If you need a lightweight (~3 kB), basic banner for that, we have open-sourced one: consent-banner-js on GitHub.

Creating and deleting cookies

Unlike most Consent Management Platforms, Consent Mode is a low-level framework that passes trigger-like data to the dataLayer; it knows nothing about cookies. But if the right consent checks are applied to all relevant GTM tags, and those tags don’t fire before the required consent is given, the cookies won’t be created.

Learn more about configuring Consent Mode so that all tags are blocked when necessary: How to configure GTM Consent Mode?

One thing GTM cannot do is delete cookies when a user revokes their consent later: consent was granted, tags fired and cookies were created. Deleting those cookies needs a dedicated solution.

Tag firing sequence

In ecommerce and in single-page applications, many events can be tracked within a single page view. Google tags handle this relatively well when only the built-in consent checks are used: events before consent is given are dropped, and every event after consent is given is sent.

With non-Google tags, such as the Meta Pixel, or when blocking Google tags entirely, it gets trickier. A typical setup loads the base Meta Pixel SDK (the snippet installing the pixel) on the page load event, because it has to load before any actual event is tracked. If consent was not known at page load (the user visits the page for the first time), that tag won’t fire again during the visit, and the other tags fail because they try to use a pixel that was never loaded.

To handle this, we created a dedicated preset for users of our GTM plugins: How to use the Consent Mode Triggers preset?

How to install it?

There are two ways to install Consent Mode.

Google tag

This way is useful if:

• you don’t use Google Tag Manager and embed the GA4 and Google Ads snippets directly,
• or you can easily add custom code to your website.

It requires defining the gtag function, a wrapper around the dataLayer, and then calling it to set the default and update consent states:

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

gtag('consent', 'default', { ad_storage: 'denied' });

// when the user's consent is provided
gtag('consent', 'update', { ad_storage: 'granted' });

The most important part of this method is to make these calls as early as possible in the page loading sequence. The default consent state must be set before any Google tag loads; otherwise Google tags run without knowing the consent state, and Google’s Tag Assistant reports an error.

Google Tag Manager

Installing Consent Mode with Google Tag Manager sounds like a no-brainer if you already use GTM. It is a bit more complex than we would hope, because inside GTM you can only interact with Consent Mode through special Consent Mode API functions. Those functions are only available in tag templates, so you either write a custom template, which is inconvenient if you need to repeat it across many GTM workspaces, or use an existing Consent Mode template. Most of those in the Community Template Gallery belong to SaaS Consent Management Platforms.

If you decide to write your own template, this is what you start with:

const setDefaultConsentState = require('setDefaultConsentState');
const updateConsentState = require('updateConsentState');

// as early as possible:
setDefaultConsentState({ ad_storage: 'denied' });

// as soon as the user's consent is provided
updateConsentState({ ad_storage: 'granted' });

Your final code will be more complex than that: you need to pass the actual consent state around, get it from a consent banner, store it in a cookie or localStorage, and so on. Doing that can make your code asynchronous, so Google introduced a special parameter, wait_for_update, that tells the GTM container to wait a given number of milliseconds before running anything, so that the asynchronous updateConsentState call can happen.

For a working example, see our basic Consent Mode template, which you can use without a CMP account or subscription. It is also in the GTM Community Template Gallery, so you can install it directly from the GTM UI: tagconcierge-gtm-cookies-template on GitHub.

Summary

Consent Mode is an elegant yet robust way of handling information about users’ privacy preferences. That information is very actionable with the right GTM features, but it still needs some manual configuration or coding, which takes time and can be harder to maintain.

That’s why we built ecommerce plugins and a banner that deploy a complete Consent Mode setup to your website or store in a few simple steps.