Consent Mode v2 technically: default, update, page_view, and the right order in GTM

Short Answer

Consent Mode v2 is not a cookie banner. It is a signal layer that tells Google tags how to behave according to user consent. Correct setup rests on two steps: first set the default consent state before any measurement, then update it immediately when the user clicks the banner.

The most common technical mistake is the wrong order. Consent default must exist before tags start reading consent state. If the user interacts with the cookie banner on the first page, good practice is to send the consent update on that same page and only then send the first full page_view or conversion event. When page_view leaves before consent update, you often voluntarily worsen data about the source, campaign, click ID, and first interaction.

At the same time, Google tags and non-Google tags do not behave the same way. GA4, Google Ads, Floodlight, Conversion Linker, and the Google tag have built-in consent checks. Meta Pixel, TikTok, LinkedIn Insight Tag, Hotjar, and other tools need to be controlled in GTM through additional consent checks or custom rules.

What Consent Mode v2 Actually Solves

Consent Mode v2 deals with two things: storing data and using data. It is therefore not enough to say whether an advertising or analytics cookie may be stored. Advertising systems also need to know whether you may send user data to Google for advertising purposes and whether data can be used for personalization.

That is why Consent Mode v2 works with multiple consent types. The two original signals, ad_storage and analytics_storage, were mainly joined by ad_user_data and ad_personalization. For websites in the EEA, this is essential for both measurement and Google Ads advertising functionality.

Default vs. Update: the Difference That Decides Data Quality

Default is the initial consent state. It must be set as early as possible, ideally on Consent Initialization in GTM or directly in code before the Google tag. Default says: until the user decides, behave like this.

Update is the change in state after user interaction. The user clicks "Accept all", "Reject all", or saves custom preferences. At that moment, the implementation must send an update immediately. Not on the next page. Not after a reload. Not on the next event. The update should be recorded on the page where the decision happened.

Consent Mode itself does not store the user's decision. The cookie banner or CMP must save the decision in a cookie, localStorage, server-side session, or another storage mechanism. On subsequent pages, the implementation then reads this decision and sends the correct consent state immediately at the start.

Recommended Order in GTM

In GTM, order matters more than the mere existence of a cookie banner. A website can have an expensive CMP platform and still measure incorrectly if the CMP tag runs late, if it blocks all of GTM, or if page_view is sent before tags know the consent state.

A safe technical framework looks like this:

1. Consent Initialization - All Pages: run the CMP tag or consent default tag. This is where default consent values are set and any already saved choice is read.
2. Consent update from a saved choice: if the user decided previously, the update must happen immediately at the start of the new page.
3. Initialization / All Pages: only after that should the Google tag, GA4 configuration, or other measurement run according to the chosen mode.
4. Banner interaction: on click, send a consent update and ideally a custom event such as consent_ready or cookie_consent_update.
5. Page_view and other events: send them only once the consent state is clear or once you have deliberately chosen advanced mode with cookieless pings.

How to Handle the First page_view

The first page_view is the most sensitive event in the entire measurement setup. It contains the landing URL, traffic source, referrer, and often an advertising identifier from the URL. If you send it incorrectly, you can damage attribution for the entire visit.

There are three reasonable scenarios. The first is strict/basic mode: Google tags do not run before a decision and you send the first page_view only after consent is granted. If the user rejects, you do not send any analytics or advertising page_view. This is clean, but you lose part of measurement.

The second is advanced mode: Google tags load with default denied and send limited cookieless signals. After consent, the state is updated and subsequent events can carry full data. This mode can improve modeling, but you need to know what you are doing legally and technically.

The third is a practical hybrid for websites with a clear modal banner on the first page: set default immediately, disable or defer automatic page_view, require the user to choose accept/reject, and after the update send an explicit page_view according to the resulting consent. If the user does not interact and continues, you need a policy decided in advance: either send a denied/cookieless signal or do not send measurement.

// Example of the principle in gtag.js. In GTM, it is better to use consent APIs in a template.
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500
});

// After clicking the banner:
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});

// Only then send page_view explicitly if you previously disabled/deferred it.

wait_for_update Is Not a Fix for a Slow Banner

The wait_for_update parameter can give a CMP a short time to finish and send an update. It is not, however, a replacement for a well-built banner. It should not hold the user for three seconds and it should not mask the fact that the CMP script is heavy, slow, or loaded late.

In practice, only a short wait makes sense, typically in the hundreds of milliseconds. If the CMP cannot set default and read saved consent quickly, the problem is in the architecture, not in the value of wait_for_update.

URL Passthrough and ads_data_redaction

URL passthrough helps when storage is denied and advertising or analytics identifiers cannot be saved to cookies. Google can then pass some information between pages through URL parameters, for example gclid, dclid, gclsrc, _gl, or wbraid. It is not a universal rescue. It works only under Google's conditions, and you must verify that the website does not remove these parameters, that redirects preserve them, and that analytics does not count URLs with them as different pages.

ads_data_redaction is the opposite safety mechanism. If ad_storage is denied, you can set additional redaction of advertising data. Google then redacts advertising click identifiers for certain requests. That does not mean the parameters are automatically removed from the browser address bar. It means that what is sent in Google tag network requests is limited.

Google Tags vs. Meta, TikTok, LinkedIn, and Others

A big mistake is to think that when GTM shows Consent Mode, all tools automatically follow it. Consent Mode is native mainly to the Google ecosystem. Google tags can adjust their behavior according to consent state. Non-Google tags must either be blocked or run only with an additional consent condition.

In practice, this means you can let GA4 and Google Ads tags work with built-in consent checks in advanced mode. Meta Pixel, TikTok Pixel, LinkedIn Insight Tag, Hotjar, Clarity, or other scripts should have an explicit consent requirement in GTM. Typically analytics_storage for analytics tools and ad_storage for advertising pixels. In some cases, you will want custom consent types, such as marketing_storage or embeds_storage, so it is clear exactly what you are allowing.

Most Common Technical Mistakes

• The CMP or consent default runs on All Pages instead of Consent Initialization. Consent is set late and tags read it before it exists.
• All of GTM is blocked. This often blocks the very tag that should set consent. The result is a blind implementation, not privacy-safe measurement.
• page_view is sent automatically before the banner click. The user may later give consent, but the first page_view already happened in the wrong state.
• The update is sent only after a reload or on the next page. Google may lose data about the original page, entry source, or session_start.
• Marketing pixels remain outside GTM. Consent in GTM will not affect them because they are hardcoded in the website code.
• There is no way to change the decision. This is technically and legally problematic; the user must be able to reopen preferences.
• Consent Overview is not enabled. Nobody can quickly see which tags are protected and which run without checks.

FAQ

Frequently Asked Questions

Does page_view always have to be delayed until after consent?

Is it a mistake if page_view is before default?

Is enabling Consent Overview in GTM enough?

Can analytics_storage be granted by default?

What is the worst mistake?