Pre-consent tracking: what it is and why regulators treat it as a violation

Pre-consent tracking is a class of finding in our scanner. It fires when, between the start of a fresh page load and the moment a user takes any action on the consent banner, the browser sends one or more network requests that carry identifiers, contain non-essential analytics payloads, or set non-essential cookies.

This is the most common defect we detect. In our scan of 97,000 EU websites, the majority of high-risk classifications were driven by pre-consent tracking, not by missing banners or broken reject buttons.

What the scanner looks for

The detector watches the network from the moment the browser issues the document request until one of three events:

1. The user clicks a button on the consent banner (accept, reject, settings).
2. A measurable consent-state cookie or localStorage entry is written.
3. A timeout elapses (default 8 seconds) without any consent signal.

Any request that fires in that window is examined for three signals:

• Known tracker fingerprint. The destination domain, request path, or payload pattern matches an entry in our tracker database. This includes Google Analytics, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, X conversion pixels, and many others.
• Identifier-bearing payload. The request carries a stable client identifier (cookie, fingerprint hash, or query parameter that survives across pages).
• Non-essential cookie write. The response sets a cookie that, by classification, is not strictly necessary for site functionality.

Any one of these is enough to trigger the finding. All three together are the typical pattern for a Google Tag Manager container that fires before the consent gate.

The legal frame, briefly

We are not your lawyer. The bare facts:

• GDPR Art. 6(1)(a) requires a valid lawful basis for processing personal data. For non-essential trackers, this is consent.
• GDPR Art. 7 sets the standard for what valid consent looks like: freely given, specific, informed, unambiguous, and revocable.
• ePrivacy Directive Art. 5(3) specifically requires consent before storing or accessing information on a user's terminal equipment — that is, before reading or writing cookies and similar identifiers. Whether a particular pre-consent network request crosses into a violation depends on whether it reads or writes information on the device, whether it carries identifiers, and whether it can be justified as "strictly necessary" — these are the questions regulators have been weighing.

National implementations differ in detail. Germany's TTDSG (now TDDDG) and France's transposition through the Loi Informatique et Libertés as enforced by CNIL have produced the most visible enforcement. DPAs across the EU have warned about pre-consent tracking patterns; specific enforcement bars vary by jurisdiction. The underlying principle is the same everywhere: consent first, tracker second.

What regulators have actually done

A short, partial timeline of decisions where pre-consent tracking was the central finding:

• CNIL v. Google (December 2020): EUR 100 million for placing advertising cookies on google.fr without prior consent.
• CNIL v. Amazon Europe Core (December 2020): EUR 35 million for the same pattern on amazon.fr.

These are not the only cases — they are the load-bearing ones. The pattern across them is consistent: the regulator measured the network behavior and treated the technical reality as dispositive, regardless of the policy text.

The scripts that most often cause it

In rough order of how often we see them as the primary cause on a high-risk scan:

• Google Tag Manager containers configured without consent-mode gating, or with consent-mode misconfigured so the default state is "granted."
• Meta Pixel loaded directly via <script src> rather than gated behind a consent callback.
• Hotjar session recording started before the banner is dismissed.
• LinkedIn Insight for B2B retargeting, particularly on agency and SaaS sites.
• TikTok Pixel on consumer ecommerce.
• First-party analytics implementations that read navigator properties or set fingerprinting cookies before any user action.

The common factor is almost never the script itself — it is the deployment. Each of these vendors publishes a documented way to gate firing on a consent signal; the default install instructions, however, frequently do not mention it.

What a clean scan looks like

A site that passes our pre-consent check does one of the following:

1. Loads no third-party tracking at all until consent is given. Functional cookies (session, language preference, CSRF) are fine.
2. Loads tag manager in "denied" state, with all non-essential tags gated behind explicit consent signals, and updates the state through Google Consent Mode v2 or an equivalent mechanism after the user acts.
3. Loads tracker stubs that do not transmit identifiers until the consent flag is set.

In our 2026 Q1 corpus of 97,000 EU sites, 68% had a tracking service active before any consent decision. The minority of sites that pass the pre-consent check tend to share a profile: the network in the pre-consent window is dominated by the document itself, CSS and font files, and a favicon — nothing that carries an identifier off the device.

How to fix it

The honest version: there is no shortcut. Every tag has to be audited for whether it fires before the consent signal is set. Steps that work in practice:

1. Open the site in a clean browser profile with dev tools open.
2. Filter network to "third-party" and reload.
3. Anything that fires before you click a banner button is a candidate.
4. For each candidate, find the loader (usually a script tag, a tag manager trigger, or an inline snippet) and gate it on the consent signal.
5. Re-test. Repeat until the pre-consent window is empty of trackers.

If you use a consent management platform, the platform's "block until consent" mode is necessary but not sufficient — many CMPs only block the cookie write, not the request. Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on a user's device (cookies, local storage, similar identifiers). Whether a specific pre-consent network request triggers that obligation depends on what the request reads from or writes to the device — a fact-specific question.

For a worked example on your own domain, run a scan and look at the "pre-consent network" panel of the report. Each offending request is listed with its initiator stack, so you can trace it to the source file in your codebase.