Pre-Consent Tracking in 2026: How It Works, Why Regulators Are Cracking Down, and How to Build a Site That Actually Waits

I scanned ten popular consumer websites — household names in retail, travel, social, and news — and timed what happened in the first few hundred milliseconds after each page started loading. Every single one fired non-essential third-party requests before any consent banner had even painted to the screen. Most of them did it within the first 200 milliseconds. Some shipped IP addresses, full referrer URLs, and cookie identifiers to advertising networks before the user had any chance to see, let alone click, anything.

This is what "pre-consent tracking" means in 2026, and it is the most direct violation of European privacy law that the modern web routinely commits. The ePrivacy Directive's Article 5(3) — the rule the entire cookie-banner industry exists to satisfy — does not say "obtain consent eventually." It says "obtain consent before storing or accessing information on a user's device." By the time the banner asks the question, the answer no longer matters. The data is already gone.

The standard defence is some version of "we use Google Consent Mode v2" or "we set the trackers to denied by default" or "we're moving to server-side tagging anyway." None of these survive a careful reading of the law, the EDPB's 2023 guidelines, or the last five years of CNIL enforcement decisions. This post walks through what pre-consent tracking actually is, what regulators have actually said about it, why each of the popular technical defences fails, and what a site that genuinely waits for consent looks like in code.

It is aimed at the engineers, tag-management owners, and privacy-engineering functions who are usually the people best placed to fix this — and who are usually the last people consulted about it.

The Short Version#

• ePrivacy Article 5(3) requires consent before any non-essential storage on or access to a user's device. The "strictly necessary" exemption is narrowly construed (CJEU Planet49, C-673/17). Analytics, advertising, A/B testing, session replay, and fraud-fingerprinting all fall outside it.
• In a corpus of 10 popular consumer sites I scanned, every single one fired non-essential trackers, pixels, or cookies before any consent banner appeared. Most did it within 200 milliseconds.
• Real-Time Bidding makes the scale of this concrete: a single ad placement can broadcast a user's IP, User-Agent, referrer URL, cookie IDs, geographic data, and behavioural segments to 100 to 500 third parties in 50–200 milliseconds, on every page load. The EDPB's 2023 Tracking Guidelines say this requires consent before the broadcast.
• CNIL has issued nine-figure fines for the cluster of violations around cookie consent: Google LLC + Ireland €150M (2021), Facebook Ireland €60M (2021), Microsoft Ireland €60M (2022), Amazon Europe Core €35M (2020). The Amazon and Microsoft decisions explicitly cite pre-consent placement; the Google and Facebook decisions cite refusal mechanisms that were not equivalent to acceptance — meaning cookies were deposited before genuinely-available refusal existed.
• The popular technical defences — Google Consent Mode v2, server-side tagging, GA4, Privacy Sandbox, "we delete cookies if the user rejects" — do not cure the violation. The EDPB and the UK ICO have addressed each one explicitly.
• The fix is straightforward in principle and organisationally hard in practice: no non-essential network request, no non-essential storage write, no non-essential storage read, until a valid consent decision has been recorded. Everything else is engineering.

What "Pre-Consent" Actually Means#

The legal hook is twenty-three years old and only forty-six words long. ePrivacy Directive 2002/58/EC, Article 5(3), as amended in 2009:

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information.

There are three things that matter in that sentence, and most pre-consent violations come from misreading at least one of them.

First, "storing of information, or the gaining of access to information already stored." This is not limited to HTTP cookies. The EDPB's Guidelines 2/2023 on the technical scope of Article 5(3)↗ confirmed what most national DPAs had already concluded: Article 5(3) covers HTML5 localStorage, sessionStorage, IndexedDB, the cache, browser fingerprinting, pixel-based tracking that reads device attributes, and even IP-only tracking from <img> tags or invisible beacons. The guidelines also clarify that gaining access covers reads, not just writes. A script that reads installed fonts, the WebGL renderer, or navigator.deviceMemory is performing an Article 5(3) operation and triggers the consent requirement, even if it never sets a single cookie.

Second, "is only allowed on condition that... has given consent." Consent must precede the storage or access. There is no provision in the Directive for retrospective cure. A cookie set on the first byte and deleted thirty seconds later when the user clicks "Reject" was still set unlawfully — the violation occurred at the moment of placement, not at some later steady state. CNIL has been explicit on this point in multiple decisions.

Third, "strictly necessary." Article 5(3) has one exemption: storage or access that is strictly necessary for a service the user has explicitly requested. The CJEU's Planet49 ruling (C-673/17, 2019) construed this narrowly. The exemption covers session cookies for cart and login state, load-balancer cookies, language and accessibility preferences, and CSRF tokens. It does not cover analytics — even "anonymous" analytics. It does not cover advertising. It does not cover A/B testing. It does not cover session replay. It does not cover fraud-prevention fingerprinting except in narrowly-scoped, properly-documented cases relying on legitimate interest, with a balancing test on file. Most marketing teams will tell you analytics is "essential to operate the site." Most regulators have rejected that reading consistently for the last six years.

The diagnostic question for any first-byte network call is therefore not "do we have consent for this?" — it is "would this site be functionally impossible to deliver without this exact storage or access, and is the user the one who explicitly requested it?" The answer for nearly all marketing, analytics, and behavioural infrastructure is no.

The Three Tiers#

Not every pre-consent network request is the same kind of violation. The scanner I built classifies pre-consent activity into three tiers, because lumping them together undermines credibility with technical readers and obscures where the actual harm is.

Tier 3 — Tracking Fires. A pixel event, a beacon, a collect?v=2 request, a Floodlight conversion ping, a Facebook fbevents.js PageView event with a payload. These are the calls that explicitly transmit user identifiers, page URLs, and behavioural data to a third-party tracking endpoint. Pre-consent, these are unambiguous Article 5(3) violations. They are also the calls that most often draw enforcement.

Tier 2 — Consent-Mode Pings. Tags firing while a consent state of denied is in effect, typically Google Consent Mode v2 or Microsoft UET in consent-status mode. The vendor argument is that these are "modelled" or "cookieless" pings — no persistent identifier is set, no individual user is profiled. The strict ePrivacy reading, which the EDPB endorsed in 2023, is that the IP address, User-Agent, and referrer URL transmitted by the ping are themselves "information" within Article 5(3), and that the ping therefore still requires consent. This is legally debatable in the sense that the question has not yet been ruled on by the CJEU, but several DPAs already treat it as a violation.

Tier 1 — SDK Loads. Loading gtm.js, fbevents.js, bat.js, an Adobe Launch container, or a Cookiebot/OneTrust stub. The script file itself contains no user data. The act of loading it does send a request, with the user's IP and User-Agent, to a third party — but if the script loads and does not execute any tracking calls until consent is granted, most DPAs accept that the load itself is not a violation. The risk is what happens after load: many SDKs auto-initialise on parse, and a tag manager that fires GA pageviews or pixel events in its own bootstrap routine slides immediately back into Tier 3.

The reason this taxonomy matters is that the fix differs by tier. Tier 3 must be blocked before consent. Tier 2 should be blocked under a strict reading and is at minimum a documented risk. Tier 1 can be allowed but must be inert — and proving it is inert is its own engineering problem, addressed below.

The Patterns I Keep Seeing in Code#

Across the corpus of sites I scanned, the same handful of mechanisms produced the same Tier 3 violations over and over again. None of them are exotic. All of them are the result of an entirely predictable interaction between common web infrastructure and a CMP that loads asynchronously.

The race condition. A page-level <script> tag for gtag.js or fbevents.js is placed in <head>, often by a CMS plugin or a tag-management snippet that pre-dates the consent integration. The CMP loads asynchronously a few hundred milliseconds later. By the time the CMP has injected its banner DOM, the analytics script has already initialised, fired its pageview, and (on Facebook Pixel) sent the PageView event with the visitor's referrer URL and IP. The "consent integration" was added to the same site months later by a different team. Nobody removed the original synchronous script.

The hard-coded vendor pixel. A retail or media CMS has a "marketing" template field that takes a free-text HTML pixel for an advertising vendor. Someone pasted in an <img src="https://..."> pixel five years ago for a campaign and never removed it. The pixel renders on every page, server-side, before any client-side CMP can intervene. The fix requires a CMS-template change, not a tag-management toggle.

The "performance" SDK. A Real User Monitoring or session-replay tool (LogRocket, Hotjar, FullStory, FS, Mouseflow, and others in this category) is configured as "essential" on the basis that it tracks technical performance. In practice it captures behavioural data — clicks, mouse movement, form input, sometimes full session video — and transmits an identifier on first byte. The marketing team treats it as analytics-adjacent. The privacy team treats it as session replay, which is unambiguously not strictly necessary. It fires before the banner.

Form-field leakage. A page contains a form. A tag-management rule binds an event listener to the form's input fields, transmitting the user's typed input to an analytics or advertising vendor on each blur or every few keystrokes — for "intent capture" or to enable email-retargeting if the visitor abandons the form. The user has not submitted the form. The user has not consented. The data has already left.

The synchronous Google Tag Manager bootstrap. GTM itself is well-behaved when correctly integrated with a CMP — it can be configured to wait for a consent signal before firing tags. But when the GTM container is dropped into a site without consent integration, GTM fires its built-in Page View and History Change triggers immediately. Any tag bound to those triggers — and many sites have GA4, Floodlight, Bing UET, and a handful of vendor tags bound to Page View — fires before consent. The site believes it is "using GTM." It is in fact using GTM as a synchronous tracker loader.

I am writing these as patterns rather than naming the sites where I observed each one, because the point is structural. None of these are unusual configurations. All of them ship on tens of thousands of sites. All of them are caused by a CMP that was added on top of a tracking stack rather than gating it from the start.

The Consent Management Platforms wiki page in the privacy-engineering knowledge base I maintain puts it bluntly:

Tags firing before the CMP loads is a systemic issue, not just a CMP configuration error.

That is the right diagnosis. Pre-consent tracking is not a per-site bug. It is what the modern marketing stack does by default unless you build the gate to stop it.

The Defences That Don't Work#

When you point any of this out to the team that owns the site, you will get one of five answers. None of them work.

"We use Google Consent Mode v2"#

Consent Mode v2 is a signalling protocol. A site calls gtag('consent', 'default', {...}) with four flags — analytics_storage, ad_storage, ad_user_data, ad_personalization — set to denied or granted, then calls gtag('consent', 'update', {...}) after the user interacts with the CMP. Google tags read these flags and adjust behaviour accordingly. So far, so reasonable.

The problem is that Consent Mode operates in two modes, "Basic" and "Advanced," and most marketing teams pick Advanced because it preserves modelled conversion data. Under Advanced, tags load and fire even with denied signals. No persistent cookie is set, no _ga ID is generated — but the request still hits Google with the user's IP, the full URL of the page, the User-Agent, and a parameter set (gcs=G100, gcd=...) indicating the consent state. Google calls these "consent mode pings." From an ePrivacy strict-reading perspective, they constitute "gaining access to information stored in terminal equipment" — the IP and URL are the information, and the request is the access — and they still require prior consent.

The EDPB's 2023 Article 5(3) guidelines are the operative framework here, and they treat IP and referrer transmissions to third parties as in scope. CNIL's enforcement track record makes the same reading. "We use Consent Mode" is not a defence against having broadcast IP, URL, and User-Agent to Google before the user had any chance to refuse. It is a defence against having set a cookie, which is a narrower question than the law actually asks.

The compliant configuration of Consent Mode is Basic mode with all four signals set to denied by default and tags genuinely blocked from firing until update is called. Basic mode is what most sites should be running and what most marketing teams will resist running, because it loses the modelled-conversion data.

"We delete the cookies if the user rejects"#

This is the most common engineer-side rationalisation. The site sets analytics or advertising cookies on first byte. If the user clicks "Accept," they stay. If the user clicks "Reject," they are deleted. The team treats the deletion as a cure.

The deletion does not cure the violation. The cookie was set without consent. Setting it without consent is the offence under Article 5(3). What happens to the cookie afterwards is irrelevant to whether the offence occurred. CNIL's December 2022 Microsoft Ireland decision (Bing) addressed this exact pattern: cookies were set, the "Reject" button removed them, and the CNIL fined Microsoft €60 million regardless. The decision is unambiguous that retrospective deletion does not cure pre-consent placement.

There is also a practical problem: the cookies are usually deleted from the first-party domain only. The third-party cookies that were set during the same load — by the pixel beacons that fired in those first 200 milliseconds — sit on the third party's own domain and are not within the first-party site's reach to delete.

"We're moving to server-side tagging / GA4 / Privacy Sandbox"#

Server-side tagging, GA4, and Google's Privacy Sandbox APIs are all reasonable engineering responses to the deprecation of third-party cookies. None of them removes the consent obligation.

GA4 still processes personal data — IP addresses, user IDs, event payloads — and the UK ICO and most EU DPAs have stated that EU users require a valid Article 6 legal basis for that processing. Consent is the default. Server-side tagging via Google Tag Manager Server Container moves the processing to a first-party server context, which can improve data quality and reduce client-side cookie dependency, but it does not change the legal basis. The ICO has been explicit:

Consent will not be bypassed simply because an API is browser-native.

The same logic applies to Privacy Sandbox APIs (Topics, Protected Audience, Attribution Reporting). They reduce some consent obligations by design — Topics is on-device, Protected Audience runs on-device auctions — but Article 5(3) and Article 6 GDPR still apply to whatever processing happens after the API returns its result. A "cookieless" architecture is not a "consentless" architecture. It is a different technical pathway to the same legal question.

"Our CMP is IAB TCF certified"#

The IAB Europe Transparency & Consent Framework is the consent-signalling standard for the programmatic advertising ecosystem. A TCF-compliant CMP encodes the user's consent decisions into a base64 string (the "TC String"), which is then read by hundreds of registered vendors to determine what processing they may carry out.

In February 2022, the Belgian Data Protection Authority fined IAB Europe €250,000 and ruled, among other things, that the TC String is personal data and that IAB Europe is a joint controller for the creation and use of TC Strings. The decision also found systemic issues with granularity, legitimate-interest claims, and DPIA documentation, and required IAB Europe to submit a corrective action plan. The ruling was partially modified on appeal: the Belgian Market Court rejected the broader view that IAB Europe is a joint controller for the entire programmatic-advertising data flow, but upheld the narrower finding that IAB Europe is a joint controller for the TC Strings themselves. The CJEU subsequently weighed in along similar lines.

Using a TCF-certified CMP is not a defence. It does not transfer liability away from the publisher. The CMP is a processor under Article 28; the publisher remains the controller. If the TCF string is constructed without genuinely-granular consent, the publisher carries the violation.

"It's the marketing team's fault, not engineering"#

The CJEU disposed of this argument in 2019 in the Fashion ID ruling (C-40/17). A clothing site embedded a Facebook "Like" button. The button transmitted user data to Facebook on page load, before any user interaction. The court held that the embedding site is a joint controller with Facebook for the data collection, even though Facebook wrote the code, set the cookie, and received the data. The site chose to embed the button. That choice made the site jointly responsible.

The same logic applies to every embedded pixel, every third-party SDK, every marketing snippet. The engineering team that ships the site is part of the controller's organisation. "We didn't build the tracker, we just put it in the page" is not a separation of liability that exists in EU privacy law.

The "Strictly Necessary" Trap#

The single most-quoted phrase in pre-consent disputes is "strictly necessary." Marketing teams apply it generously. Regulators construe it narrowly. The gap between those two readings is the source of more pre-consent violations than any other single misunderstanding.

The strictly-necessary exemption in Article 5(3) is per-purpose, not per-cookie. The same cookie can be strictly necessary for one purpose and non-essential for another. A session cookie for cart state in an e-commerce checkout is strictly necessary. The same session cookie repurposed to feed a remarketing pixel is not.

The wiki I built for the scanner has the canonical list:

Strictly necessary (no consent needed):

• Session cookies for shopping cart, login state, or checkout flow
• Load-balancer cookies for sticky sessions
• User preference cookies for language, locale, or accessibility
• CSRF tokens

Not strictly necessary (consent required):

• Analytics cookies, including Google Analytics, Adobe Analytics, and any first-party "we built our own" pageview tracking
• Advertising cookies, including remarketing, conversion, and frequency-capping cookies
• Social-media tracking pixels, including Like and Share buttons that load before interaction
• A/B testing and personalisation cookies
• Session replay and behavioural monitoring tools
• Fraud-prevention fingerprinting, except where narrowly scoped under a documented Article 6(1)(f) legitimate-interest balancing test

The temptation is to treat anything that helps the site function as "essential." The CJEU's Planet49 reading does not allow that latitude. The test is whether the service the user explicitly requested could be delivered at all without the storage or access. Almost no analytics or advertising cookie passes that test.

Verified Enforcement#

The enforcement record on pre-consent tracking is consistent enough that no site operating in the EU should be relying on lack of attention. National DPAs — CNIL especially — have issued nine-figure fines for the exact patterns described above.

Two patterns to note. First, all of the CNIL fines above are issued under Article 82 of the French Data Protection Act — the French national transposition of ePrivacy. They are not GDPR fines, they do not appear in the GDPR enforcement-tracker dataset, and they sit alongside parallel GDPR proceedings rather than replacing them. CNIL has the discretion to use either regime; they have been using Article 82 because it covers the cookie-specific conduct directly. Second, the same companies that pay these fines have also been fined for related GDPR violations (forced consent, dark patterns, transfer issues) in separate decisions. Pre-consent tracking is rarely the only violation — it is the most easily proved one.

The CNIL's "Cookie Sweep" between 2020 and 2022 issued more than 100 formal warnings to organisations of all sizes for placing non-essential cookies before consent. The enforcement is not concentrated on the largest tech companies. It is systematic, and the warnings often cite the exact patterns described in this post.

What a Site That Actually Waits Looks Like#

The compliant configuration is conceptually simple: no non-essential network request, no non-essential storage write, and no non-essential storage read until the CMP has recorded a valid consent decision. Implementing this is conceptually straightforward and organisationally hard, because it requires actual control over what the marketing stack does.

Block tags by default in the tag manager. Every analytics, advertising, and behavioural tag must be configured to wait for a consent signal before firing. In Google Tag Manager, this is done with the Consent Configuration settings: every tag is associated with one or more required-consent types (analytics_storage, ad_storage, etc.), and the tag does not fire until that consent is granted. In Tealium, Adobe Launch, and Segment, the same pattern is implemented through extension rules or consent-aware destinations.

Run Consent Mode in Basic, not Advanced. If you use Google Consent Mode v2, the configuration that is unambiguously compliant is Basic mode, with all four signals (analytics_storage, ad_storage, ad_user_data, ad_personalization) defaulted to denied, and tags genuinely held until update is called. Advanced mode preserves modelled conversions at the cost of pre-consent pings. Pick one.

Audit the page source for hard-coded vendor pixels. Tag-management consent gating only works for tags routed through the tag manager. Free-text pixels embedded in CMS templates, third-party widgets pasted into article bodies, and historical analytics scripts left in <head> from a previous integration are all outside the gate. They have to be removed at the source.

Test the ignore variant. Before declaring the site compliant, run an end-to-end test that loads the page, does not interact with the banner, and inspects every outbound network request and every storage write. Anything beyond strictly-necessary cookies and the CMP itself is a violation. The scanner I built does this automatically; the test is also straightforward to run with Puppeteer or Playwright in CI.

Set a strict Content Security Policy. A connect-src and script-src policy that whitelists only the domains genuinely required for the page to function will, as a side effect, stop most accidental pre-consent leakage. The tag manager and CMP go on the whitelist; vendor SDKs that should be consent-gated do not go on it until consent is granted (which can be done by adding them dynamically post-consent or by using nonces).

Record consent the way the law actually requires. Article 7(1) GDPR places the burden of proof of valid consent on the controller. The wiki spec for what proof actually looks like:

For each consent event, store user ID (or session ID), timestamp, consent version (important when privacy notices are updated), and granular per-purpose consent choices. Records must be tamper-resistant and retained for verification.

A boolean consented: yes/no stored in localStorage is not proof. It does not identify the user, the version of the privacy notice they saw, the specific purposes they agreed to, or when they decided. Many CMPs store consent receipts that meet the spec; some store a stripped-down version that does not. Audit yours.

Where This Is Going#

Three trends are shaping the 2026 landscape and will shape the next two years of enforcement:

• The ePrivacy Regulation, if and when it is adopted, will align maximum fines with GDPR (€20M or 4% of global revenue). It has been in negotiation since 2017 and is still not adopted. When it does land, the cap on cookie-specific enforcement triples or quadruples for most large operators. The current Directive-based regime is, by comparison, lenient.

• Real-Time Bidding is the next major enforcement front. The EDPB's 2023 Tracking Guidelines explicitly addressed RTB. CNIL's Google Authorized Buyers investigation continues. The fundamental architecture of programmatic advertising — broadcasting personal data to hundreds of bidders before the auction has resolved — is structurally incompatible with prior consent, and regulators have started to say so out loud.

• The "we delete after reject" defence is fully dead. Five years ago it was a grey area. After the CNIL Microsoft decision and the EDPB 2023 guidelines, no DPA accepts it. Engineering teams that are still relying on it are running on borrowed time.

Pre-consent tracking is not a misconfiguration. It is what the modern marketing stack does by default unless somebody builds the gate to stop it. If your privacy programme assumes the banner is the gate, the gate is in the wrong place.

Part of an ongoing series on web privacy, built on a structured knowledge base of GDPR and ePrivacy jurisprudence. Related reading: the privacy audit series, browser fingerprinting, cookie-banner dark patterns.