Polaris Audit

Case #002 · 20 Apr 2026 · 7 min read

The Meta Pixel Fires Before You Click Accept. Here’s the Proof.

A working cookie banner doesn’t stop Facebook. Here’s exactly what gets sent and when.

TL;DR

  • Meta Pixel sets _fbp (browser fingerprint) and fires a PageView event on script load — before any consent click
  • The cookie is written to connect.facebook.net at the moment your GTM container initialises, not when the user accepts
  • Facebook's own "Advanced Matching" sends hashed email and phone data in the same pre-consent window if enabled
  • Fix requires a GTM consent trigger on analytics_storage or a Facebook-specific consent check — not just a CMP banner

Verdict

If your Meta Pixel is deployed via GTM with an “All Pages” trigger and no consent check, it is firing pre-consent on every page load. A cookie banner on the same page does not change this. The ICO and CNIL have both issued fines for exactly this configuration.

What happens the millisecond your page loads

The browser requests your page. GTM loads. GTM reads its container configuration and fires every tag assigned to the All Pages or DOM Ready trigger. If your Meta Pixel tag has either of these triggers and no consent condition, it fires. Immediately.

What “fires” means specifically: a request to connect.facebook.net/en_US/fbevents.js loads the Pixel script. That script then sets a first-party cookie called _fbp — a browser fingerprint tied to your domain — and sends a PageViewevent to Facebook’s servers. All of this happens before the consent banner has registered any user decision.

The _fbpcookie has a 90-day expiry. The PageView event contains your site URL, the user’s IP address, their User Agent string, and the _fbp identifier. That is personal data under GDPR Article 4(1). Sending it without consent is a violation of Article 6.

Advanced Matching makes it worse

Facebook’s “Advanced Matching” feature — often enabled by default in newer Pixel configurations — automatically scrapes form fields on your page for email addresses and phone numbers, hashes them with SHA-256, and sends them with every Pixel event.

If a user lands on a logged-in page, a prefilled checkout, or any form with a visible email field, Advanced Matching sends that hashed data with the pre-consent PageView. Hashing does not anonymise data under GDPR — the CJEU has confirmed that pseudonymous data remains personal data when the original can be recovered with additional information.

To check if Advanced Matching is enabled: open the Meta Pixel Helper browser extension and look for “Automatic Advanced Matching” in the event details. If it shows hashed parameters, it’s active.

Why the banner doesn’t stop it

CMPs (Cookiebot, OneTrust, CookieYes) present the consent UI and store the user’s decision. They do not, by default, pause GTM or block individual tags from firing.

The CMP sets a consent signal — a cookie or localStorage value — that GTM can optionally read. But unless your Meta Pixel tag in GTM is configured to check that signal before firing, GTM ignores it completely. The banner is a separate system. The two are not connected unless you wired them together.

Most Pixel implementations are not wired together. The CMP vendor configured the banner. The developer added the Pixel in GTM. Neither party checked what the other did.

Your site is leaking data before consent.

Free headless-browser scan. Catches GA4, Meta Pixel, TikTok and more firing before the click. Results in 10 seconds.

Run a free scan

The GTM fix

Two approaches, in order of correctness:

Option 1: Consent Mode trigger

In GTM, open your Meta Pixel tag. Under “Triggering,” add a condition: Event equals gtm.consent_update AND ad_storage equals granted. This fires the Pixel only after the CMP has registered an “Accept” decision and emitted a consent update event. It will not fire on page load for users who decline or haven’t interacted.

Option 2: Custom consent variable

Create a GTM Variable of type “1st Party Cookie” pointing to your CMP’s consent cookie (e.g. CookieConsent for Cookiebot). Add a trigger condition that checks this variable contains marketing:trueor equivalent. Attach that trigger to your Pixel tag. This is more brittle than Option 1 but works for CMPs that don’t emit consent update events.

After implementing either fix: hard reload the page in a private browser window, open DevTools Network, and filter by connect.facebook.net. You should see zero requests before clicking “Accept.” If any requests appear, the fix did not work.

What regulators have said

The French CNIL issued formal notices to multiple major publishers in 2022 for exactly this configuration — Meta Pixel firing pre-consent via a “functional” GTM setup. The notices required remediation within 30 days.

The Belgian DPA fined a media company in 2023 for pre-consent cookie writes including _fbp. The defence that “the banner was visible when the cookie was set” was explicitly rejected — visible and not-yet-declined is not consent.

If you manage sites for clients, each of those sites is a separate exposure. A single DPA complaint can name the agency as a joint data controller if you deployed the tracking implementation.

Check any site in 10 seconds

The manual DevTools method above gives you the answer but produces no documentation. The free scan runs a headless browser, loads the page without interacting with any consent UI, and captures every request to connect.facebook.net, facebook.com/tr, and 12 other tracker endpoints — with timestamps and cookie write events.

If the Pixel is firing pre-consent, it shows up in the timeline. Unlock the full report for the GTM remediation steps specific to your configuration.

Run a free scan

Related

Does Your Cookie Banner Actually Block GA4? →

The same pre-consent problem, from the Google side.

← All posts