Fireshift / Features / Consent checks
Consent checks: tags that fire before accept
We open the site in a fresh browser with no cookies, wait before touching the banner, and log every request to Meta (facebook.com/tr), LinkedIn, Google Ads and GA4. Any event hit before accept, or a marketing cookie like _fbp, is a finding. This needs a live browser, so it is not part of the free score: we run it in the Fix Sprint, and you can run it yourself in three minutes. We have not yet published how common it is.
What we look for
| Before accept | What it means |
|---|---|
facebook.com/tr with ev=PageView | The Meta Pixel sends events before consent |
_fbp cookie set | The pixel stored its browser ID |
px.ads.linkedin.com hits | The LinkedIn Insight Tag is running |
/pagead/conversion or remarketing hits | Google Ads tags fire with no consent check |
GA4 hits with gcs=G111 | Consent Mode says both ad and analytics storage are granted, before anyone granted them |
The gcs parameter on Google hits carries the Consent Mode state. It is commonly read as G1 plus one digit for ad storage and one for analytics storage, 1 granted and 0 denied: G100 means both denied. A G111 before accept usually means the default consent state was never set to denied. Our capture records gcs on every GA4 hit.
Why a consent setup leaks
- Consent Mode covers Google tags only. A Meta or LinkedIn tag in a Custom HTML tag ignores it unless the tag has its own consent requirement or fires from a consent trigger.
- A hardcoded pixel. Pasted in the theme or added by a plugin, so the banner has nothing to block.
- Two copies. One in GTM behind consent, one hardcoded without it.
- A banner that records the choice and blocks nothing.
Check it yourself in 3 minutes
- Open a private window. Open DevTools, Network, before loading the page.
- Load your homepage. Don't touch the banner. Filter on
facebook, thenlinkedin, thencollect. - Look at DevTools, Application, Cookies for
_fbp. - Reject, reload, repeat. Nothing marketing-related should go out after a reject either.
Meta specifics and the fbq('consent', 'revoke') fix: Meta Pixel firing before cookie consent.
Why it matters for bidding too
Fixing consent lowers what Meta and Google receive, which is expected. Done right with Consent Mode, Google tags still send cookieless pings when consent is denied, so Google can model some of the conversions it can't observe (Google Ads Help: about consent mode). Done wrong, you either leak or lose the signal entirely.
What we can't see
- Server-side tags and the Conversions API. If your server sends events to Meta or Google, it must respect the same choice. Nobody can check that from outside, us included.
- Every market. Banners often behave differently by country. We test from one location per run.
- Whether it is legal. We report what fired and when. What each market requires is for your privacy counsel. This is not legal advice.
Where our data stands
We have the method and the capture, but not yet a measured rate across many sites. A consent scan of 30+ sites is on our research list; when it runs, the number goes here with its date.
FAQ
Is loading fbevents.js before consent a leak?
The script request sends the IP address and browser details to Meta, so some reviewers count it. The bigger issue is /tr event hits and the _fbp cookie.
Does Google Consent Mode cover Meta and LinkedIn?
No. Consent Mode changes how Google tags behave. Other vendors need their own consent condition in GTM or their own consent API.
Is the consent check in the free scan?
No. The free scan reads tag containers and can't see timing. The consent check needs a live browser visit, which we run in the Fix Sprint.
Rather have it fixed?
Fix Sprint: we clean up Google Ads, GTM and GA4 conversion tracking in 5 working days, with a scan before and after. €1,500 fixed. You pay the second half only when our after-scan shows the flagged issues fixed.
See the Fix Sprint