Pre-consent scripts: which trackers sit in the source before consent

Trackers referenced before consent only become a violation once they execute. The check lists the references; whether CMP blocking or Consent Mode stops execution is what the deep scan shows.

What we check

In the HTML: the scan looks for thirteen cookie-based trackers in the executable part of the page, script sources, inline scripts and pixel URLs: Google Tag Manager, gtag.js, Meta Pixel, LinkedIn Insight, TikTok Pixel, Hotjar, HubSpot, Microsoft Clarity, Google Ads, Intercom, Mixpanel, PostHog and Adobe Analytics. Cookieless tools such as Plausible or Fathom are deliberately not on the list. Every match carries its evidence, host, path or container ID. No match means "ok". Matches are critical, unless they are Google tags only and Consent Mode is active; then the line reads "to review", and the deep scan settles in the reject state whether anything fires.

What the scan cannot see: scripts the CMP serves as type="text/plain", code in examples and documentation, and trackers that another script loads later.

Why it matters

Referenced does not mean executed. Under the EU ePrivacy rules, accessing device information needs consent, so what counts is what actually runs before opt-in. Basic Consent Mode blocks the tags entirely; advanced loads them and sends cookieless denied pings, whose legal standing is contested. A tag with neither simply fires. That is the critical case.

Common causes

GTM or gtag.js is built straight into the template instead of behind the CMP blocking.
Shop and CMS plugins inject their pixels themselves, bypassing the tag manager and the CMP categorisation.
"Just testing quickly" snippets from old campaigns were never removed again.
The CMP loads asynchronously, but the trackers already sit in the initial HTML.

The fix

Move every listed script behind the CMP blocking or the tag manager's consent triggers. Then the counter-test without interaction: load the page, click nothing, read the network tab. Whatever still sends, sends without consent.

Matching template

CMP and GTM Consent QA Template

The repeatable test plan for default-denied, consent update and reject, across all four signals.

Get the QA template →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

The scan lists GTM as a pre-consent script. Is that automatically a violation?

No. With Consent Mode active the line reads "to review", because what the container does before consent depends on the mode: basic blocks until opt-in, advanced loads and sends cookieless pings with a denied stamp. Without Consent Mode and without CMP blocking the tag simply fires, then the finding is critical. Whether anything really leaves after "reject" is shown by the reject respected finding in the deep scan.

Our CMP blocks the scripts, but the scan still finds them. Why?

The scan only counts what is executable. If the CMP serves a script as type="text/plain" and releases it only after consent, it stays invisible. If it is found, it sits executable in the source, either as a normal script tag or as an inline snippet, and then it runs. The evidence behind every match (host, path or container ID) shows which snippet is meant.

Is the static finding enough to prove the violation?

No, it is an indicator. Proof is behaviour: load the page, click nothing, read the network tab. Whatever sends then, sends without consent. That is exactly what the deep scan does with a real browser, writing the result into the findings reject respected and Consent Mode: basic or advanced.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint