Google Consent Mode v2: What It Is and How to Set It Up Properly

If you advertise to anyone in the EEA or the UK and you have not implemented Consent Mode v2, your audiences are shrinking and your conversion reporting is quietly incomplete. Most people find out from a warning in Google Ads rather than from anyone explaining it.

This is the explanation.

What it actually is

A cookie banner tells the visitor you are asking for consent. Consent Mode is how that answer gets communicated to Google's tags.

Before it existed, the two systems were disconnected. Your banner set a cookie somewhere, and separately your Google tags either fired or did not, usually decided by a bit of custom code someone wrote once. Google had no standard way to know what the user had chosen.

Consent Mode replaces that with a defined signal. Your tags load in a default state of "no consent", the visitor answers the banner, and the banner updates the signal. Google's tags then adjust their own behaviour based on that answer, without you writing the branching logic yourself.

v2 is the current version. It added two signals to the original two.

The four signals

The last two are the v2 additions, and they are the ones that carry the consequences. They are about permission to use the data, not just permission to store a cookie. Sending an event without the right signal is not a technical failure, it is a policy one.

Each is either granted or denied. That is the whole vocabulary.

What breaks if you skip it

Not implementing v2 does not produce a dramatic error. Things degrade instead, which is why it goes unnoticed.

• Remarketing audiences stop growing for EEA and UK traffic. Existing lists shrink as people age out and nobody is added.
• Personalised advertising becomes unavailable for that traffic.
• Conversion modelling does not run. This is the expensive one. When consent is denied, Google can normally estimate the conversions it could not observe, but it can only do that if it received a properly signalled "denied". No signal at all means no modelling and no estimate, so those conversions simply do not exist in your reports.
• You are non-compliant with Google's own EU user consent policy, which is a contractual issue on top of the regulatory one.

The last point is worth sitting with: the difference between "denied" and "nothing" is enormous. A correct denied signal still gets you modelled data. Silence gets you nothing.

Basic mode versus advanced mode

There are two ways to run it, and the choice matters more than most guides admit.

Basic mode: tags do not load at all until consent is granted. Nothing is sent for a user who declines.

Advanced mode: tags load immediately in a denied state and send cookieless pings, containing no identifiers, for users who decline. When consent is granted, they switch to normal behaviour.

Advanced mode is better for almost everyone, because those cookieless pings are what conversion modelling is built from. Basic mode is more conservative and easier to defend to a strict legal team, but you give up the modelling.

Pick advanced unless someone with legal responsibility tells you otherwise. And if they do tell you otherwise, that is a legitimate decision, not a mistake.

The three ways to implement it

1. A certified CMP (easiest, and what I usually recommend)

Google maintains a list of certified consent management platforms that handle Consent Mode v2 natively. Cookiebot, CookieYes, Iubenda, Osano, Usercentrics and others are on it.

You install the CMP, switch on its Consent Mode integration, and it manages the defaults and the updates for you. Most of them have a Google Tag Manager template that does the wiring.

This is the right choice for the overwhelming majority of sites. It is not the cheapest option, but consent logic written by hand is a thing you have to maintain forever.

2. Google Tag Manager consent settings

If your CMP writes a consent state you can read, GTM can consume it. Every tag in GTM has built-in consent settings where you declare which signals it requires, and GTM holds the tag until those signals are present.

This is the middle path: more control, more to configure, and you own the correctness of it.

3. By hand with gtag

You set defaults before your tag loads, then update after the visitor answers:

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

  // Defaults must run BEFORE the Google tag loads.
  gtag('consent', 'default', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    analytics_storage: 'denied',
    wait_for_update: 500
  });
</script>

Then, when the visitor accepts:

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

The two rules that decide whether this works:

• The default block must execute before the Google tag loads. If the tag loads first, it has already made its decisions. This is the single most common implementation bug.
• wait_for_update buys a short window, in milliseconds, for a consent decision to arrive before tags act on the defaults. It stops a race condition on returning visitors whose choice is being read from storage.

How to check yours is working

Do not trust the CMP dashboard. Verify it on the page.

1. Google Tag Assistant. Load your site in Tag Assistant and look at the consent state on the tag. It shows the current value of all four signals, before and after you interact with the banner. This is the fastest check.

2. The Network tab. Open DevTools, filter for google-analytics.com or googletagmanager.com, and look at the outgoing request. There is a gcs parameter on it. G100 means denied, G111 means granted. Decline the banner, reload, and confirm you see G100 rather than no request at all. Seeing no request is the failure case, because that means no cookieless ping and no modelling.

3. Google Ads diagnostics. In Google Ads, check the consent status under your conversion actions. It will tell you plainly whether it is receiving the signals, though it lags by a day or two.

4. Decline, then browse. Click reject, then move through your site normally. Nothing should set an advertising cookie. Check Application, Cookies in DevTools.

The mistakes I see most

Defaults after the tag. Covered above, and it is the top one by a distance.

Only setting two signals. Plenty of implementations were written for v1 and never updated, so they set ad_storage and analytics_storage and omit ad_user_data and ad_personalization. It looks like it is working. It is half broken.

No region targeting. You can scope defaults by region, so EEA and UK visitors get denied-by-default while other regions do not. Applying denied-by-default worldwide when you are not required to is a self-inflicted data loss.

The banner is decorative. The visitor clicks reject, and the tags fire anyway because nothing was ever wired to the answer. This is the worst outcome available: you carry the conversion cost of the banner and none of the compliance benefit.

Where server-side tracking fits

Consent Mode and server-side tracking solve different problems and people conflate them constantly.

Consent Mode governs permission. Server-side tracking governs delivery: getting the events you are permitted to send actually through to Google and Meta, past ad blockers and browser restrictions.

You need both, and the order matters. Consent Mode first, because sending data you do not have permission to send is not a measurement problem you can engineer around. Then server-side, so the permitted data actually arrives.