Google ad requirements since March 2024 for the EEA, UK & Switzerland

Consent Mode v2,
initialized in order.

ConsentEase sets denied Consent Mode v2 defaults before the Google Tag Manager container, then sends a consent update on the visitor's choice — so supported Google tags read the right state from the start.

Read the Docs

Initialization order

Illustrative

step 0Page load
The document begins parsing.
Defaults before GTM
step 1ConsentEase snippet
```
gtag('consent', 'default', { denied })
```
Defaults set before Google Tag Manager.
Defaults before GTM
step 2GTM container loads
Supported Google tags read the denied consent state.
Supported tags read state
step 3Banner appears
Visitor is presented with consent choices.
Choices presented
on choiceVisitor decides
```
gtag('consent', 'update', { … })
```
A consent update reflects the visitor's choice.
Update on choice
afterSignals adjust
Supported Google tags respond to the updated consent state.
Behavior adjusts

Order is illustrative. ConsentEase sets denied defaults before the Google Tag Manager container; supported Google tags then adjust their behavior from the consent state.

Implementation risk

Order is the whole game.

A late consent default creates a race
If the consent default is declared after tags already run, early requests are made without an established consent state.
Missing updates limit downstream behavior
Without a consent update reflecting the visitor's choice, supported Google tags cannot adjust their behavior for that choice.
Hand-wiring the dataLayer is fragile
A single mistake in a hand-written dataLayer can break the consent flow, and without diagnostics it can go unnoticed.

The timeline is illustrative and shows sequence, not fixed timings. Setting the consent default before the Google Tag Manager container is what keeps the order correct.

Late default: an initialization race

Illustrative

Relative order only — bars show sequence, not fixed timings.

gtm.js

container loads

Analytics tag

fires

Runs before a consent default

Ads tag

fires

Runs before a consent default

CMP script

loads late

Consent banner

appears

Consent default

set (too late)

Set after tags already ran

The gap: when the consent default is set after tags already ran, early hits carry no established consent state. Setting the default first is what closes this gap.

How it works

Four stages, in order.

Defaults first, dependent tags next, choices presented, updates sent. Supported Google tags adjust their behavior from the consent state; non-Google tags require their own GTM consent checks or vendor controls.

Establish defaults

The ConsentEase snippet runs first and sets denied defaults before the Google Tag Manager container loads.

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  analytics_storage: 'denied',
  security_storage: 'granted',
  wait_for_update: 500
});

Defaults set first

Load dependent tags

Google Tag Manager loads. Supported Google tags read the denied consent state and adjust their behavior; non-Google tags need their own GTM checks or vendor controls.

Supported tags adjust

Present choices

The banner appears and the visitor makes a choice. Nothing is inferred — the update reflects exactly what the visitor selects.

Visitor decides

Send updates

A consent update is sent for the choice. Supported Google tags respond to the new state.

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

Update on choice

The gcs parameter

Diagnostics-supported

The consent state on a Google request is encoded in gcs. These are the interpretations ConsentEase diagnostics inspect — no outcome is guaranteed.

G111

ad_storage: granted
analytics_storage: granted

Both granted — expected after a visitor accepts.

G110

ad_storage: granted
analytics_storage: denied

Ads granted, analytics denied.

G101

ad_storage: denied
analytics_storage: granted

Analytics granted, ads denied.

G100

ad_storage: denied
analytics_storage: denied

Both denied — the state before a visitor chooses.

Interpretations are observed from initial-load evidence, not an outcome guarantee.

Compact examples reflect the current ConsentEase embed. It initializes ad_storage, ad_user_data, ad_personalization, analytics_storage, functionality_storage, and personalization_storage as denied; security_storage as granted; wait_for_update at 500; enables ads_data_redaction and url_passthrough; then loads the script asynchronously.

Observable evidence

What diagnostics can see.

The initial-load scan reports what it can observe and is explicit about what it cannot. It never claims a verified accept or reject journey.

ConsentEase diagnosticsexample initial-load evidence

Observed before interaction

Banner script presenceobservable
Consent default declarationobservable
Google request consent statewhen present
Consent default countbrowser mode only

Not measured on this scan

Default-before-GTM orderingnot proven
After accept — gcsnot measured
After reject — gcsnot measured
Storage grants per choicenot measured

What the evidence is

The diagnostic scan inspects the initial page load. It can observe the banner script, a consent default declaration, and consent state on eligible Google requests. Browser-mode evidence can also count default declarations; fallback scans may report that as unavailable.

What it is not

Finding a default does not by itself prove it ran before Google Tag Manager. The scan also never answers the banner, so the after-accept and after-reject journey is not simulated or verified. It is implementation evidence — not legal clearance or a compliance verdict.

Read the diagnostics documentation

Diagnostics are observed initial-load implementation evidence. Availability depends on the scan mode. The evidence does not by itself prove ordering, is not legal clearance, and does not simulate a full accept or reject journey. Confirm your setup against current Google documentation and your own vendor controls.

Feature comparison

Setup responsibilities, compared.

Responsibility	ConsentEase	Cookiebot	CookieYes	Manual implementation
Default set before GTM	Set before the container	Configuration-dependent	Configuration-dependent	You control the order
Consent update on choice	Sent automatically	Configuration-dependent	Configuration-dependent	You write it
Consent Mode v2 signals	ad_user_data / ad_personalization set	Configuration-dependent	Configuration-dependent	You map each signal
Initial-load diagnostics	Built-in	Check the vendor's tooling	Check the vendor's tooling	Browser DevTools
Setup path	Guided install + verification	Vendor setup flow	Vendor setup flow	Fully manual

Default set before GTM

ConsentEase: Set before the container
Cookiebot: Configuration-dependent
CookieYes: Configuration-dependent
Manual implementation: You control the order

Consent update on choice

ConsentEase: Sent automatically
Cookiebot: Configuration-dependent
CookieYes: Configuration-dependent
Manual implementation: You write it

Consent Mode v2 signals

ConsentEase: ad_user_data / ad_personalization set
Cookiebot: Configuration-dependent
CookieYes: Configuration-dependent
Manual implementation: You map each signal

Initial-load diagnostics

ConsentEase: Built-in
Cookiebot: Check the vendor's tooling
CookieYes: Check the vendor's tooling
Manual implementation: Browser DevTools

Setup path

ConsentEase: Guided install + verification
Cookiebot: Vendor setup flow
CookieYes: Vendor setup flow
Manual implementation: Fully manual

Neutral, configuration-dependent comparison. Where a vendor's behavior depends on its own configuration, it is labelled as such rather than asserted. Verify current vendor capabilities and Google policy before deciding.

See Full Comparison

Verify your Consent Mode
setup for free.

Scan your site to see the initial-load evidence, then talk to us if you want a hand getting the order right.

Consent Mode v2 defaults handled

Denied by default, security granted

Diagnostics on initial load

Consent Mode v2,initialized in order.