Why do trackers keep firing before consent?

Trackers fire before consent because tag managers, analytics snippets, and embeds load on their own schedule, independent of the consent banner. The banner asks for permission while the scripts take it, and nobody notices until a scan catches the mismatch.

The banner and the scripts live in different worlds

A consent banner is usually a small piece of code added late in a project, while the tracking was wired in early by the marketing team or the agency. The two systems do not talk to each other by default. Google tags, pixels, and heatmap scripts fire the moment the page loads, and the banner has no power to stop them unless someone explicitly gated each script behind a consent decision. Most sites skip that wiring, so the banner is decorative.

Tag managers make it worse

Tag managers are convenient: one container, and anyone in marketing can add a new pixel without a deploy. That convenience is exactly what breaks consent. Every tag added through the manager fires on the triggers it was given, and those triggers were set up before the consent rules existed. The container grows over the years, nobody audits it, and new trackers slip in through a familiar interface that never asks about consent.

The fix is a scan, then gating

Run an automated scan and compare what fires before consent against what the banner promises. The gap is your work list. Then gate each script category behind the matching consent choice: necessary always on, everything else blocked until the visitor says yes. This is not a one-time job. Every new embed, plugin, or tag manager change can reopen the gap, which is why continuous monitoring exists: to catch the next script before a regulator or a customer does.