Passing a test once doesn't keep you compliant

Here's the uncomfortable part of consent compliance: your setup can pass every test on Monday and be violating the rules by Friday, without anyone touching a line of your code. A vendor pushes an update that adds a cookie. A tag in Google Tag Manager gets published by someone who skipped the consent settings. A third-party script starts loading a new tracker from a partner. Your banner still looks fine. Underneath it, trackers are firing that shouldn't be.

That's consent drift: the gap that opens over time between what your consent setup is supposed to enforce and what's actually happening in visitors' browsers. Point-in-time scans catch it when you run them. Between runs, drift is invisible, which is exactly when it does the most damage.

Drift is the norm, not the exception

The research is blunt about how common this is. A 2024 study by the University of Amsterdam and ETH Zurich that analysed around 100,000 European websites found that 65% ignored users' rejection choices and kept tracking anyway. Many of those sites almost certainly believed they were compliant. Their banners worked. Something downstream didn't.

Regulators are watching for exactly this pattern. The core violation in France's CNIL enforcement, which drove much of its roughly 486.8 million euros in 2025 sanctions, is trackers that fire before consent or keep running after a decline. Those aren't design decisions. On most sites they're drift that nobody caught, because nobody was monitoring for it.

What to actually monitor for

"Monitoring" is vague until you name the specific failures. These are the ones that turn into complaints and fines:

Trackers firing before consent

The headline violation. Any non-essential cookie or third-party connection that happens on page load, before the visitor clicks anything, is a problem. Watch for network requests to analytics and ad domains in the pre-consent window.

Tags that ignore a rejection

The subtler failure. The banner records a "reject," but a tracker keeps firing because it was added outside the consent gate. This is the 65% problem. Monitor the reject-all state, not accept-all alone.

New cookies and connections you never approved

A tracker that appears in your inventory without a corresponding entry in your cookie policy. It got added by a plugin update, a new embed, or a partner's script pulling in a fourth party.

New data recipients

A new vendor domain receiving data is a material change. It can invalidate the consent you already collected and needs to appear in your re-consent decisions and your records of processing.

Cookies are only half of it

A lot of modern tracking doesn't use classic cookies at all. It works through network requests, beacons, and browser storage. That's why cookie-only monitoring misses so much. Effective drift detection watches outbound connections, the calls a page makes with fetch, XMLHttpRequest, and sendBeacon, rather than the cookie jar alone. If your monitoring only counts cookies, a tracker that phones home without setting one slides right past it.

Scheduled scans versus runtime monitoring

These are two layers, and you want both. A scheduled scan crawls your pages on a fixed cadence, monthly for most sites, and gives you a clean inventory snapshot. It's thorough but periodic. Between scans, you're blind.

Runtime drift detection fills that gap. Instead of crawling on a schedule, it runs inside the live page and watches what actually happens in real visitors' browsers, catching a new tracker the first time it fires rather than weeks later at the next scan. The two complement each other: scheduled scans give you depth and a defensible record, runtime monitoring gives you speed. Relying on scans alone leaves a window; relying on runtime alone loses the systematic inventory. Run them together.

Turn monitoring into action, not noise

Detection is worthless if nobody sees it. Three practices keep monitoring useful:

Alert on new, not on everything. You don't want a notification for every known cookie on every page load. You want to hear when something new and unapproved appears. Good monitoring baselines your known-good inventory and surfaces only the deltas.
Require repetition before you promote a finding. A single anomalous request might be a fluke. A connection that shows up repeatedly across sessions is real drift. Waiting for a small number of confirmations before flagging cuts false positives without hiding genuine problems.
Send a regular digest to someone who owns it. A weekly or monthly summary of what changed, delivered to the person responsible for consent, turns monitoring from a dashboard nobody opens into a habit. Assign an owner or the reports pile up unread.

Server-side tagging can hide trackers from browser monitoring

When you move tracking server-side, the third-party calls happen from your server, not the visitor's browser, so browser-based monitoring can't see them. That doesn't make the consent obligation disappear. If you run a server-side setup, your consent state has to travel to the server and gate the tags there too. Monitor the consent signal reaching your server, not the browser alone. See our guide on server-side consent enforcement.

Consent monitoring checklist

Monitor the pre-consent window
Nothing non-essential should fire before the visitor chooses.
Test the reject-all state, never accept-all alone
The 65% failure is trackers that ignore a rejection.
Watch connections, not the cookies alone
Beacons and network calls track without setting a cookie.
Baseline known-good, alert on the deltas
Surface new and unapproved trackers, not every known one.
Confirm repeat sightings before flagging
Repetition separates real drift from a one-off fluke.
Route a digest to a named owner
A weekly or monthly summary that someone actually reads.
Cover server-side tags if you run them
Consent has to gate tags on the server too.

Continuous drift detection, built in

CookieBeam's script watches the running page and wraps the browser's own request methods (fetch, XMLHttpRequest, and sendBeacon) to catch new trackers and connections as they fire, then promotes a finding once it's been seen repeatedly rather than on a single hit. Combined with automatic monthly re-scans and a weekly or monthly digest of what changed, that gives you both the systematic inventory and the real-time signal. To see what a full scan inspects, read how cookie scanners work.