99.62% of “Bannered” Sites Still Trigger Tracker Signals Pre‑Consent (Runtime Data)

99.62% of “Bannered” Sites Still Trigger Tracker Signals Pre‑Consent (Runtime Data)

posted Originally published at securespells.com 3 min read

TL;DR: Audited 276 websites and found that 95.65% of them had Cookie Banner (proxy checks) installed and 99.62% of bannered sites have pre-consent third‑party tracker signals still flagged by runtime audit engine.

In other words: banner presence was common, pre‑consent drift was almost universal in this sample.

The takeaway isn’t “banners are useless” It’s: a banner is UI but compliance is behaviour.
If you don’t verify what actually runs and what actually hits the network on a cold visit, you’re trusting configuration screens over browser reality.

Scope: EU/EEA GDPR + ePrivacy (cookies and similar identifiers). Educational, not legal advice.

THE ILLUSION: “BANNER INSTALLED” ≠ “BEHAVIOUR CONTROLLED”

Most teams treat “banner installed” as the finish line. Engineers and reviewers care about something stricter:

On a cold visit (no prior consent stored), do non‑essential scripts stay inert?
Do non‑essential third‑party requests stay off the network until consent is captured?
A CMP dashboard toggle can say “blocked” while load order, tag manager triggers, or embeds still fire early.

WHAT WE MEASURED (RUNTIME SNAPSHOT)

Dataset and scans were run with SecureSpells - GDPR & ePrivacy–focused runtime browser audit.

Dataset (aggregated only):

  • Sites scanned: 276
  • Consent banner detected: 95.65%
  • Pre-consent third‑party tracker signals flagged: 99.62% (of bannered sites; simplified proxy check)
  • Critical risk issues flagged: 68.06% (sites with ≥1 critical issue in issue counts)
  • 30‑day regression rate: 3.57% (monitored domains with ≥1 regression event)
  • Interpretation: banners are common. Observed behaviour still drifts unless you verify it in a browser on a cadence.

Important:flagged” here means the scan observed behaviour consistent with third‑party tracking/embeds happening pre‑consent under the scan profile. It does not decide lawful basis, jurisdiction, or final legal classification for a specific tag.

WHY AGENCIES SEE DRIFT AFTER LAUNCH (EVEN WHEN THE BANNER LOOKS “RIGHT”)

Drift usually comes from small changes that bypass the banner’s assumptions:

Tag manager edits (new triggers, containers, templates)
Third‑party embeds added by marketing (video, chat, booking widgets)
CMS/plugin updates introducing new scripts/endpoints
Consent mode configuration drift (signals update, but load order still leaks)
If your process ends at “banner installed,” drift accumulates until a client notices—often via a complaint or a screenshot.

THE WORKFLOW THAT HOLDS UP (AGENCY VERSION)

Treat privacy behaviour like performance regressions: a workflow, not a checkbox.

  1. Baseline on staging (before launch) Run a runtime scan on the entry page under a “no consent yet” profile. Save the output as
    evidence.
  2. Gate the usual sources of drift Route marketing tags through a single policy/owner. Keep a written rule like:
    No non‑essential third‑party requests before consent (adapt to your legal interpretation).
  3. Re‑scan on change + on cadence After any GTM change, plugin update, or marketing release: re‑scan. Then re‑scan production
    weekly/monthly depending on risk.

WHAT TO TELL CLIENTS (LANGUAGE THAT AVOIDS OVERCLAIMS)

  • “We installed a banner” → “We control and verify tracking behaviour under defined consent states.”
  • “We’re GDPR compliant” → “Here is runtime evidence for pre‑consent behaviour on the pages we tested; broader compliance still requires legal and operational work.”
  • “We blocked everything” → “We validated non‑essential third‑party requests don’t occur before consent in the tested profile; we monitor for regressions.”

CONCLUSION

The average state of public websites is, frankly, worryingly sloppy. A cookie banner creates a convincing UI, but it often creates a false sense of compliance when the underlying behavior still leaks: tags fire early, embeds bypass assumptions, and GTM/container edits drift after launch. The big gap isn’t “lack of CMPs” — it’s lack of runtime proof that a cold visit actually stays quiet until consent.

For agencies, this is an opportunity: “compliant websites” can be a real differentiator if you can back it with evidence, not promises. Make runtime scans part of delivery (staging baseline → launch evidence), then sell monitoring as a retainer (re-scan on change + cadence). If you want to reproduce this workflow, SecureSpells is a GDPR & ePrivacy runtime compliance browser audit: https://securespells.com/

READ THE FULL METHODOLOGY + LIMITATIONS

Full post (with methodology, limitations, and the agency workflow):
https://securespells.com/blog/banner-installed-tracking-stopped-runtime-data/

More Posts

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

Own Your Consent Layer: Vibe Code, AI, and Runtime Proof With SecureSpells

Ott Ristikivi - Apr 29

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

Sovereign Intelligence: The Complete 25,000 Word Blueprint (Download)

Pocket Portfolioverified - Apr 1

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan - Feb 9
chevron_left

Related Jobs

Commenters (This Week)

4 comments
3 comments

Contribute meaningful comments to climb the leaderboard and earn badges!