Consent Mode v2 doesn't excuse pre-consent trackers

Google’s Consent Mode v2 has become the most widely deployed “consent signal” mechanism on the EU web. It is also one of the most widely misread. Many sites assume that once Consent Mode v2 declares ad_storage: denied and analytics_storage: denied, the work is done — Google’s tags receive the signal, advertising and analytics behave in a reduced-data mode, and ePrivacy compliance is achieved.

That assumption is wrong. The European regulators that have spoken on it — most prominently the French CNIL and the Belgian Autorité de Protection des Données — agree on a simple legal point: the network request itself is the trigger of ePrivacy Article 5(3), not the server-side handling of the data once it arrives. If the tracker fires before consent, you have a violation, regardless of how denied any flag is.

This post explains the gap, why it matters for your audits, and what we changed in our audit engine this week to detect it correctly.

What Consent Mode v2 actually does

Consent Mode v2 is a signalling layer between your website and Google’s tags. When the user has not consented, the page sets ad_storage: 'denied' and analytics_storage: 'denied'. Google’s tags receive that signal and switch into a reduced-data mode: cookieless pings, modeled conversions, no persistent identifiers.

What it does not do is prevent the tag from making a network request to Google’s servers. Google reCAPTCHA, Google Ads, and Google Analytics all still call out to google.com, googleadservices.com, gstatic.com. Each of those calls — the HTTP request itself, not the data Google subsequently writes to disk — is precisely the act that ePrivacy Article 5(3) regulates.

What ePrivacy Article 5(3) actually requires

The directive’s wording is precise. It prohibits “the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user” without prior consent. Two operations, neither limited to cookies: storing information in the user’s device, and reading information already there.

A network request to a third-party domain reads at minimum the user’s IP address, User-Agent, and any pre-existing cookies for that domain. That alone constitutes “gaining access to information already stored”. Whether Google then chooses not to write a _ga cookie because consent is denied is irrelevant: by the time that decision is made server-side, the access has already happened.

The CNIL has restated this position repeatedly in its guidance on cookies and other trackers, and the Belgian Autorité de Protection des Données has affirmed it in recent enforcement actions: server-side denial signals do not retroactively undo the violation. For a more practical breakdown of what counts as a proper rejection in the first place, see our earlier post on what counts as rejection of cookies.

Why our audits missed it (until now)

Until this week, Elgarde’s audits gave Consent Mode v2 sites partial credit. If we observed Google’s tags loading with ad_storage: 'denied', we treated the absence of identifiers in the response as a strong signal that no tracking was occurring. In other words, our heuristic was: if the site told Google not to track, and Google’s response complied, the regulatory question was answered.

That heuristic had two practical effects we now consider unacceptable. Sites running Google Analytics 4, Google Ads, or reCAPTCHA pre-consent received better grades than they should have, because the network request itself was not surfaced as a violation. And audits we generated could be cited by the site owner as evidence of compliance — when a CNIL or Belgian APD inspection would have found the opposite. Both are positioning failures for a privacy-first platform. Our audits must align with how the regulators actually read the law, not with how vendors hope it will be read.

What changed this week

The audit engine now flags any third-party tracker network request that fires before explicit, granular consent — irrespective of any ad_storage, analytics_storage, or other Consent Mode v2 signal. The detector matches against the same tracker categories already documented in our analytics-pre-consent violation page: analytics, advertising, social, and fingerprinting. Each pre-consent tracker request now produces a violation entry in the cookie-consent section of the report, with the regulatory citation pointing back to ePrivacy Article 5(3) and the relevant national DPA guidance.

If your existing audit on Elgarde is more than a few days old, consider rerunning it. Sites that were graded B or C may now grade C or D depending on how many pre-consent trackers we detect — not because the legal position changed but because our detection caught up with it.

Also in this release

A handful of smaller user-facing improvements landed alongside the audit-engine update:

• Report grade labels now use legally precise language. The grades read “Violations detected” (B), “Non-compliant” (C), and “Critical risk” (F), instead of the previous softer phrasing. The change is purely linguistic — the underlying scoring is unchanged — but the labels now match how a DPA would describe the same posture.
• Mobile navigation fixed. The hamburger menu icon was toggling correctly but the navigation panel was not opening on phone-sized viewports. Fixed.
• Screenshot rendering on scan reports. Device-preview screenshots were overflowing the viewport on narrow screens. They no longer do.
• Rescan button visibility. The rescan option is now correctly hidden for visitors who are not logged in, matching the intent that rescans are an account feature.
• Stripe promotion codes. Discount codes created in Stripe are now accepted at checkout. If you have a code from us or from a partner, the field is on the checkout page.

For broader context on what EU regulators are actually fining over, see our overview of cookie-consent fines in the EU in 2026.

What to do if you run Consent Mode v2

The short version: do not rely on Consent Mode v2 as your ePrivacy compliance layer. Treat it as a defence-in-depth signal for Google’s downstream processing, but block tracker network requests at the source until the user has given prior, granular consent. Concretely, that means using a Consent Management Platform (CMP) that holds tag execution back rather than just informing Google what to do once the tag has already loaded.

If you are unsure whether your site clears that bar, run a free audit on Elgarde — the new methodology will surface any pre-consent tracker requests directly, with the regulatory article and the DPA reference attached to each one.

---

Released 2026-05-05.