Rejected Consent Banners in the EU: The Cookieless Signal-Recovery Blueprint

Quick answer: “Cookieless” describes what a tool writes to a device, not whether EU law requires asking first. Article 5(3) of the ePrivacy Directive governs access to the device, and that reach extends to embedded review widgets, software telemetry in desktop and SaaS clients, and anything else reading device state — regardless of where the vendor’s servers are hosted. The European Commission has proposed relocating this rule into the GDPR with a carve-out for audience measurement (COM(2025) 837 final, November 2025), but it isn’t law yet. The engineering question that actually matters once you accept this is: what do you build to keep usable data once 50-70% of EU visitors decline the banner?

Cookieless doesn’t mean the banner is optional

Article 5(3) covers two operations: storing information on a user’s device, and accessing information already there. Writing no cookie removes the first; it says nothing about the second. The EDPB’s Guidelines 2/2023 on the technical scope of Art. 5(3) are explicit that a script reading device parameters and transmitting them “clearly falls within the scope of Article 5(3)” whether or not it writes anything first (para 33). Under EDPB Opinion 5/2019 (para 40), ePrivacy is lex specialis over the GDPR here, so GDPR legitimate interest can’t substitute for consent you failed to collect under Art. 5(3).

This site has the full breakdown — the country-by-country exemption table for France, Italy, Germany, Spain, Ireland and the UK, and the Breyer analysis of when a rotating hash still counts as personal data — in Do Cookieless Analytics Need Consent in the EU and UK?. What follows here assumes that conclusion and extends it to two places people routinely assume it doesn’t reach.

Review widgets and third-party embeds

Dropping a review or rating widget’s script tag into a page template feels like adding a static element, not activating a tracker. Legally it isn’t static. The widget’s script runs on the visitor’s device with the same access as any first-party script you wrote yourself, and in the CJEU’s Fashion ID ruling, the operator who embeds a third party’s code can become a joint controller for what that code triggers — even without ever seeing the resulting data:

“the fact that the operator of a website, such as Fashion ID, does not itself have access to the personal data collected and transmitted to the provider of the social plugin with which it determines jointly the means and purposes of the processing of personal data does not preclude it from being a controller.” — Fashion ID GmbH & Co. KG v Verbraucherzentrale NRW eV, C-40/17, para 82

Fashion ID was decided under the pre-GDPR Data Protection Directive, but the joint-controllership reasoning is the one regulators and courts carry forward under the GDPR for the same fact pattern: your site embeds a third party’s script, and that script does something on the visitor’s device you didn’t code yourself and can’t fully inspect. A review widget that reads a session identifier, sets its own storage, or fingerprints the visitor to deduplicate submissions is in that fact pattern regardless of what it’s called.

Hosting location doesn’t change this analysis. Art. 5(3) refers only to “the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user” — nothing in the text turns on where the recipient’s servers sit. An EU-hosted widget that reads device state still needs consent; a US-hosted one that reads nothing still doesn’t trigger Art. 5(3) at all. What hosting location does affect is GDPR’s international-transfer regime (Chapter V, Articles 44-49) — a separate question about where collected data is allowed to go, decided after the collection question, not instead of it. “We host in the EU” answers a transfer question nobody asked yet, while leaving the consent question untouched.

Vet any embedded widget the same way you’d vet your own analytics tag: what it writes to storage, what device parameters it reads, and whether it fires before or after your CMP resolves. The DevTools audit checklist for cookieless analytics tools applies to third-party embeds without modification.

Software telemetry outside the browser

Art. 5(3)‘s operative phrase is “terminal equipment,” and nothing in the Directive restricts that to browsers. A desktop application, a mobile app, or a SaaS client that phones home with usage telemetry is accessing and transmitting information from a user’s device in exactly the structure Art. 5(3) addresses. The fact that there’s no DOM, no document.cookie, and no page load doesn’t move the operation outside the rule’s text — it moves it outside where most engineering teams think to look for it.

In practice this means: a telemetry SDK bundled into installed software, reporting crash data, feature usage, or device specs back to a vendor, needs the same consent analysis as a web analytics tag if the user is a natural person using the device for non-professional purposes. The common gap is treating “we don’t run in a browser” as if it were a legal exemption rather than a change of transport.

The production blueprint: what to build when visitors decline

Once you accept that consent is required and a majority of EU visitors will decline it — real-world opt-in rates in the 30-50% range are common — the engineering question becomes what you can still measure without that consent, and what you shouldn’t try to.

1. Default to denied, and mean it. Every tag that touches analytics_storage or ad_storage should start denied before the visitor interacts with the banner. Google’s own guidance is explicit that unset values should not be read as granted. Loading your CMP through the same container you’re trying to gate defeats the gate; the CMP has to load first and independently.

2. Layer Advanced Consent Mode’s cookieless pings on top, not instead of, that default. With Advanced Consent Mode, Google tags still fire while consent is denied, sending a ping without identifiers but with the consent state and functional data the browser adds automatically. GA4 and Google Ads can model aggregate behavior from these pings once a property clears Google’s volume threshold — at least 1,000 daily events with analytics_storage denied for seven straight days, plus 1,000 daily consented users. Below that threshold, the pings are being sent for nothing recoverable: there’s data leaving the browser with no modeling benefit coming back. The Consent Mode v2 setup post covers the Basic/Advanced trade-off, the GTM wiring, and why this read of Art. 5(3) makes Advanced the higher-risk option for EU traffic specifically — that’s a legal judgment call for your DPO, not an engineering default.

3. Put server-side tagging between your tags and your vendors — as an architecture decision, not a compliance one. A server container (GTM Server-Side, Tealium) sits between the browser and the upstream analytics or ad platform, and its Transformations feature can be configured to drop fields like ip_override and the user_agent from an event before it’s forwarded to a given tag. That’s real: it reduces what a third-party vendor receives per event, independent of what your own first-party logs retain. What it does not do is change whether the original client-side collection needed consent. If the browser-side script collecting the event already triggered Art. 5(3) without a lawful basis, redacting fields on the way out the server doesn’t fix the collection that already happened upstream of the redaction.

4. Build your aggregate reporting around what’s actually consented, not around backfilling the gap. A clean first-party event log from consented sessions, reported honestly as a partial sample, is more defensible and more useful than a modeled estimate stretched across a user base where most visitors said no. Where modeling thresholds aren’t met, say so in your own reporting rather than presenting a Google-side estimate as a measured number.

5. Watch the EU’s own direction of travel, but don’t build for it yet. The Commission’s Digital Omnibus proposal (COM(2025) 837 final, 19 November 2025) would repeal Art. 4 of the ePrivacy Directive and move terminal-equipment consent into new GDPR Articles 88a and 88b, with a stated exception category for audience measurement and provisions for browser-level, machine-readable consent signals. If adopted as proposed, aggregate analytics could get a narrower version of the exemption France and Italy already carve out nationally — but as of October 2026 this is a Commission proposal that still has to clear the European Parliament and the Council under the ordinary legislative procedure. Nothing about today’s consent requirement changes until it does.

None of the above is a way around Art. 5(3). It’s how you keep the aggregate data usable once consent has been properly asked for, and a majority of visitors have properly said no. Setting up that pipeline — Consent Mode configuration, server-side container, and the reporting layer that doesn’t overstate what it’s actually measuring — is part of my consent mode work.