rytisbalys.com / troubleshooting

Meta Pixel not firing? The 6 real causes, in the order you should check them

Written from production audits, not documentation. Each cause comes with a verification step you can run in minutes - because "the pixel is installed" and "the pixel is firing" are very different claims.

First, know what you're looking for. A firing pixel sends network requests to facebook.com/tr. Open DevTools > Network, filter by tr, and act on the site. No requests = not firing, whatever your tag manager says.

01Consent banner is blocking it (the #1 cause in the EU)

If you run Cookiebot, OneTrust or any CMP in opt-in mode, the pixel is legally supposed to stay silent until the visitor accepts. The bug: after acceptance it often STAYS silent, because the pixel tag in GTM is not wired to the consent state, or fires before consent updates.

VERIFY - open the site in incognito, accept all cookies, then check facebook.com/tr requests. Silent even after full acceptance = your consent wiring is broken, not working.

02Pixel initialized twice (or three times)

A hardcoded base code in the theme AND a GTM tag AND a platform integration all loading the same pixel. Symptom is usually the opposite of silence - events fire 2-3x per action, purchases double-count, and audiences pollute.

VERIFY - in the console run fbq.getState().pixels (or use Meta Pixel Helper). More than one init of the same ID, or multiple IDs you don't recognize = consolidate before anything else.

03GTM trigger chain never completes

The tag exists, but its trigger waits for a dataLayer event (purchase, add_to_cart) that the site never pushes - a theme update or checkout change silently broke the push. The tag is "active" and fires exactly never.

VERIFY - GTM Preview mode, perform the action, watch the event stream. If your trigger event never appears in the left column, the dataLayer push is gone.

04Redirect checkouts eat the Purchase event

PayPal, financing providers, bank-redirect payments: the buyer leaves your site to pay and often never returns to the thank-you page where the Purchase pixel lives. The pixel works perfectly - for the customers who come back. The rest vanish.

VERIFY - compare pixel Purchase counts against real backend orders BY PAYMENT METHOD. If card orders track and redirect-payment orders don't, this is your gap. The durable fix is server-side (Conversions API from the order event, not the browser).

05Checkout runs in an iframe or on another domain

Embedded checkouts (Eventbrite, Calendly, some booking and payment widgets) run in a cross-origin iframe. Your page's pixel physically cannot see events inside it.

VERIFY - if the confirmation step's URL bar or frame ancestry is another domain, stop debugging your pixel. You need the vendor's own tracking hooks, a postMessage bridge, or server-side events.

06Ad blockers and browser privacy (the loss you can't fix client-side)

Some meaningful share of your visitors block facebook.com/tr outright - ad blockers, Safari ITP, strict browser modes. No client-side fix exists. This is exactly what the Conversions API is for: the same event, sent server-to-server, deduplicated against the browser event via a shared event_id.

VERIFY - in Events Manager check the ratio of browser vs server events per event type. Browser-only setup = you are losing whatever your audience's blocker rate is, silently.

The one-line rule

Don't trust any dashboard that says "connected". Trace one real event end to end - browser network tab, GTM Preview, Events Manager Test Events - and compare monthly totals against your backend's paid orders. The number that matches reality is your backend. Everything else is a suspect.

Numbers still don't add up? I do this for a living - tracking audits that reconcile Meta, GA4 and your backend, then server-side fixes with proper deduplication. Running in production on my own stores daily.

work@rytisbalys.com