Tags that fire before consent: how to find and fix them

A cookie banner only means something if your tags wait for the answer. On a lot of sites they don't: analytics and ad pixels send their first hits while the banner is still on screen, or carry on after the visitor clicked "Reject". It is the consent problem our tracking audit finds most often, and it is a compliance risk under the GDPR and the ePrivacy rules.

What "before consent" means

Three situations count:

• Hits before the answer. A tracker sends data before the visitor chose anything, without a "denied" consent state on the hit.
• Hits after a refusal. The visitor rejected, and a tracker still sends hits as if they agreed.
• Cookies after a refusal. The browser holds tracking cookies such as _ga or _fbp after the visitor said no.

Google's Consent Mode is the exception that is allowed: with Consent Mode, Google tags can send cookieless pings with the consent state set to denied. That is fine, as long as the state really says denied.

How to find it

The Measurebase tracking audit loads your pages in a real browser, notes every tracking request it sees before the banner is answered, then clicks the banner's reject button and watches what still happens. It reports the trackers by name, for example "Before the consent banner was answered, these trackers already sent hits without a denied consent state: Google Analytics, Meta pixel".

By hand: open your site in a private window, open the browser's developer tools on the Network tab, and reload without touching the banner. Requests to google-analytics.com, your tagging subdomain, facebook.com/tr or analytics.tiktok.com at that point are hits before consent. Then click reject, browse a page further and look again, also at the cookies under Application.

The usual causes

1. Consent Mode defaults set too late, or not at all. The default must say denied before any tag fires. Set it in a tag on the Consent Initialization trigger, or with your consent tool's own Tag Manager template, never on All Pages.
2. Tags without a consent check. Non-Google tags such as the Meta pixel don't read Consent Mode by themselves. Give them a consent requirement in the tag's consent settings, or fire them on your consent tool's "consent given" event instead of All Pages.
3. Tags outside Tag Manager. A pixel pasted into the theme, a plugin's own tracking or a Shopify app pixel runs outside your container and its consent rules. Move it into Tag Manager or switch the app's tracking off.
4. The banner loads after Tag Manager. If the consent tool's script comes after the container, tags can fire before it exists. Load it first, or through its Consent Initialization template.
5. A refusal that sends no update. The banner must send a Consent Mode update with denied when the visitor rejects, not just close.

Server-side tags count too

With server-side tagging, the hits that reach your server container carry the visitor's consent state. Google's server tags respect it; tags for other platforms, such as Meta's Conversions API, need a trigger condition or exception that checks it. Otherwise a visitor who refused in the browser still reaches Meta through your server.

Checking the fix

Run the tracking audit again with Run audit now on the domain's Tracking audit page; the finding disappears once nothing fires before the answer and a refusal is respected. For testing your tags without clicking through your own banner each time, use Auto Grant Consent, and switch it off again afterwards.

Frequently asked questions

Are cookieless Google pings allowed before consent?

They are part of Consent Mode's advanced mode and carry the denied state. Whether that is enough is a legal choice for your organisation; basic mode, which sends nothing until consent, is the stricter option.

Does server-side tagging make consent unnecessary?

No. Consent is about what you do with a visitor's data, not about where the code runs. Server-side tagging gives you more control over it, not an exemption.