Universal Analytics stopped processing data back in mid-2024, which means every site still running Google Analytics has, by now, migrated to GA4 — a migration that changed more about consent handling than most teams realized while doing it. A consent setup built around Universal Analytics' assumptions doesn't automatically carry over correctly.
The core difference: GA4 is built around Consent Mode, UA mostly wasn't
Universal Analytics predates Google's formal Consent Mode framework. Most UA consent setups were bolted on afterward — a tag manager trigger that simply didn't fire the GA tag until consent was granted, a binary on/off. GA4 was built alongside Consent Mode from the start, and Google explicitly designed it to behave differently depending on which consent signals are present, not just whether GA fires at all.
What Consent Mode actually controls
Consent Mode recognizes several distinct signals, the two most relevant being analytics_storage and ad_storage. This matters because GA4 (and Google Ads) can receive partial signals:
- Both granted — full tracking, as normal
analytics_storagedenied,ad_storagegranted — GA4 doesn't set its usual cookies, but can still send cookieless "conversion modeled" pings to Google for aggregate modeling, depending on configuration- Both denied — no cookies, no pings, full block
The key point that trips people up: "Consent Mode installed" doesn't mean "no data sent without consent." Google's own documentation describes cookieless pings and conversion modeling that can occur even when consent is denied, as part of how Consent Mode is designed to still provide aggregate signal to Google Ads. Whether that's acceptable under your specific DPA's guidance is a legal question worth checking directly — several EU regulators have published differing guidance on whether modeled/cookieless pings themselves require consent.
What actually needs checking on a GA4 setup
1. Consent Mode is actually implemented, not just "GA4 is installed"
A site can have GA4 running without Consent Mode configured at all — in which case it behaves like old-style UA setups, either fully blocked or fully unblocked with no middle ground, and your CMP needs to gate the entire tag rather than relying on Consent Mode signals.
2. The default state before any interaction is "denied," not "granted"
Consent Mode requires an explicit default state set before the GA4 tag loads. If the default is misconfigured as "granted," GA4 behaves as if consent was given until told otherwise — meaning data can flow during the window before the visitor interacts with the banner at all.
3. The CMP's signal is actually wired to Consent Mode's API
This is a common and completely silent failure: a CMP is installed, a banner displays, a visitor rejects — but the CMP was never actually configured to call gtag('consent', 'update', ...) with the right parameters. The banner and the Consent Mode layer exist on the same page without being connected to each other.
4. Advanced/cookieless pings, if you want them disabled entirely
If your reading of applicable guidance is that cookieless modeling pings themselves require consent, that needs a specific additional configuration step — it isn't the default "denied" behavior.
How to check this on your own site
Open DevTools' Network tab filtered to google-analytics.com or analytics.google.com, load the page before interacting with the banner, and look at what — if anything — fires. Then click reject and check again: a correctly configured Consent Mode setup should show either nothing, or only Google's own cookieless ping format, never a standard tracking hit with cookies attached.
We cover the broader Consent Mode v2 mechanics — what it checks and what it doesn't — in a separate breakdown if you want the full picture beyond GA4 specifically.
Run a free scan of your site to see exactly what your GA4 setup sends before and after a visitor's consent choice.