A consent banner is a promise about what happens next. If your analytics and advertising tags fire as the page loads, before the visitor has chosen anything, the promise is broken before anyone reads it, and that gap between what the banner says and what the site does is the problem whichever privacy law applies to you.

Pre-consent firing is common and easy to miss, because the people who own the banner rarely look at the network traffic. It's also easy to test for. You need a browser, a clean profile, and an afternoon. Below: how to test it, why it happens, how to fix it, and why it matters. This is not legal advice; what your obligations are is a question for your attorney.

What counts as firing too early

A tag fires too early when it sends data to a third party, or stores an identifier in the visitor's browser, before the visitor has made a consent choice, or after they've declined. It shows up in four ways:

  • Script loads. The vendor's library downloads. On its own this can be harmless, but it usually comes with the next item.
  • Beacons. Requests carrying event data: a page view, a product ID, a click. They often go to endpoints with names like collect, tr, or events, sent as image requests, fetch calls, or navigator.sendBeacon pings.
  • Identifiers. Cookies or local storage entries such as _ga, _fbp, or _gcl_au, set before the visitor has chosen.
  • Recording. Session replay or heatmap scripts that start capturing clicks, scrolls, and sometimes typed text on load.

Loading the consent platform itself is expected. The question is what else talks to whom before the visitor answers.

How to test it in an afternoon

Use a fresh browser profile, or a private window, for every run. Your consent platform remembers the last choice, and stale state hides the bug. In Chrome, the Application panel's Clear site data button resets cookies and storage for the site.

  1. Open DevTools before you load the page. In the Network panel, tick Preserve log so requests survive navigation, and Disable cache.
  2. Filter out your own domain with a negative filter such as -domain:*.your-store.com, so only third-party requests remain.
  3. Load the page and don't touch the banner. Scroll, wait thirty seconds, and visit a second page, since some tags fire on scroll, on a timer, or on exit.
  4. Export the log as a HAR file named before-consent.har, and check the Application panel for cookies and local storage entries.
  5. Clear site data, reload, and click Reject. Browse two pages and export after-reject.har.
  6. Clear site data again, click Accept, and export after-accept.har. This proves the tags still work when allowed, which keeps your marketing team from "fixing" the gate by removing it.

Then compare the three files from the command line:

# Third-party hosts contacted before any choice, most frequent first
jq -r '.log.entries[].request.url' before-consent.har \
  | cut -d/ -f3 | grep -v 'your-store.com$' \
  | sort | uniq -c | sort -rn

Two more tests catch problems the basic run misses.

The blocking check. In the Network panel, right-click the consent platform's script and choose Block request domain, then reload. If the consent banner fails to load, because of an ad blocker, a slow network, or a script error, what does your site do by default? If tags fire freely with the banner blocked, your default is "allow."

The server-side check. If your tags send events to a first-party address such as collect.your-store.com, the browser only shows a request to your own domain. What gets forwarded to vendors happens on your server, so you have to review the server container's tags and check that the consent state travels with every event and is enforced there.

CheckHow to run itA pass looks like
Clean stateNew profile, or Clear site data in the Application panelThe banner appears on load
Nothing sent before a choiceNetwork panel with Preserve log, own domain filtered out, scroll and waitOnly the consent platform and essential services contact third parties
No identifiers before a choiceApplication panel: cookies and local storageNo analytics or advertising identifiers
Reject means rejectClick Reject, browse two pages, leave the siteNo analytics or ad requests, including pings sent on exit
Default when the banner failsBlock the consent platform's domain and reloadTags stay off
Accept worksFresh state, click AcceptTags fire and receive the consent state
Server-side forwardingReview server container tags and consent conditionsForwarding follows the consent state sent from the browser
Session replayLook for replay requests before a choiceRecording starts only after consent

The causes are mundane, which is why they persist.

  • Hard-coded pixels. A snippet pasted into the theme's <head> years ago, outside the tag manager. The consent platform can't gate a script it doesn't control.
  • Tag manager triggers. Tags set to fire on "All Pages" or at initialization, with no consent condition attached.
  • Consent mode defaults. No default command at all, a default that runs after the tags, a default of "granted," or region rules that don't cover all your visitors. Also check which implementation you run: in what Google calls advanced consent mode, tags load before consent and send cookieless pings while consent is denied. Whether that matches your banner's wording is a decision for your privacy counsel, not your tag manager.
  • Session replay on load. Replay tools often start recording immediately, and some capture form input unless fields are masked.
  • Platform apps and plugins. E-commerce apps and CMS plugins that inject their own pixels without asking the consent platform.
  • Embeds. Video players, maps, and chat widgets that set cookies as soon as they render.
  • Race conditions. The consent platform loads asynchronously, and a synchronous tag earlier in the page wins the race.

How to fix it

Default to deny, first thing in the page. Set the consent defaults before any tag loads, and load anything outside the tag manager only after consent:

<!-- First script in <head>, before the tag manager or any pixel -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }
  gtag("consent", "default", {
    ad_storage: "denied",
    ad_user_data: "denied",
    ad_personalization: "denied",
    analytics_storage: "denied",
    wait_for_update: 500
  });

  // A vendor script that lives outside the tag manager
  function loadAfterConsent(src) {
    const s = document.createElement("script");
    s.src = src;
    s.async = true;
    document.head.appendChild(s);
  }
  // Wire this to your consent platform's own event or callback API
  window.addEventListener("consent-updated", (e) => {
    if (e.detail.marketing) loadAfterConsent("/vendor/pixel.js");
  });
</script>

Gate every trigger. In the tag manager, only the consent platform should run at initialization. Every other tag needs a consent condition, and a tag with no condition should fail review.

Move hard-coded pixels into the tag manager, or wrap them in a consent-gated loader like the one above. Then delete the old snippet from the theme, and search the codebase for the vendor's domain to make sure it's gone.

Use click-to-load facades for embeds. Show a static preview of the video or map and load the real embed when someone asks for it. It's better for consent and much better for page speed.

Treat server-side tagging with care. Moving collection to your own domain can reduce page weight and give you control over which fields reach vendors. It doesn't change what consent requires, and it takes the data flows out of view of anyone inspecting the browser. Send the consent state with every event and enforce it on the server.

Why it matters

Kentucky's Consumer Data Protection Act took effect on January 1, 2026. It applies to businesses that control or process the personal data of at least 100,000 Kentucky consumers in a year, and it gives consumers the right to opt out of targeted advertising and the sale of their data. It requires consent before processing sensitive data, such as a health diagnosis, and it requires data protection assessments for targeted advertising. The Attorney General enforces it, there is no private right of action, and businesses get a cure period of 30 days after written notice. Kentucky's model is opt-out for advertising, so a pixel firing before a banner choice is not automatically a violation there. The exposure comes from the mismatch: a banner offering a choice the site doesn't honor, a privacy notice that describes practices you don't follow, or sensitive pages sending data to ad platforms without consent. Our Kentucky privacy law checklist covers the rest of the statute.

In California, plaintiffs have filed many lawsuits under the California Invasion of Privacy Act arguing that pixels, session replay, and chat tools capture visitors' communications without consent, much like a wiretap. Courts have reached different conclusions, and outcomes depend heavily on the facts. Tags firing before anyone consents is the fact pattern those complaints describe.

The FTC's Office of Technology has also written about how pixels can collect more than site owners intend, including sensitive information. And there's a cost even without a regulator: every tag that runs before consent also runs before your content finishes loading, so the visitor pays in speed as well as privacy.

Run the test before someone else does

Run the six-step test on your home page, a product or service page, and your checkout or contact form this week. Then add an automated version to your release pipeline, so a new campaign tag can't quietly undo the fix.

If you'd like help, our Tag & Script Governance audit inventories every script, its cost in milliseconds, and when it fires relative to consent. Baclion Watch then alerts you when a new script appears or an old one starts firing early again.

Sources

  1. Kentucky General Assembly, 2024 Ky. Acts ch. 72 (HB 15), Section 12
  2. Kentucky Revised Statutes 367.3613
  3. Kentucky Revised Statutes 367.3627
  4. FTC Office of Technology: Lurking Beneath the Surface: Hidden Impacts of Pixel Tracking