Facebook Pixel Not Firing? Diagnose by Symptom

The symptom split that replaces guesswork

"Pixel not firing" is not one problem — it's a family of at least five, and the forums treat them as one because the dashboard symptom looks identical: numbers too low. The fastest diagnostic question in Meta tracking is: which events are missing, and for whom? If everything is dead, your base code never loads — a loading problem. If PageView fires but Purchase doesn't, your base code is fine and the event's placement is wrong. If everything fires but only for some visitors, nothing is broken at all — you're looking at the privacy layer doing what it's designed to do. Three branches, three completely different repair kits, and the first two are fixable this afternoon.

Three symptoms, three branches — identify yours before opening a single settings page.

The 10-minute verification loop (do this first)

Before touching code, establish ground truth. Open your site in an Incognito window with no ad blocker — a startling share of "my pixel is broken" reports are the store owner's own uBlock. Install Meta Pixel Helper and load your homepage: a lit badge with PageView means the base code loads and you can skip the entire first branch. Then open Events Manager → Test Events, browse your own store and run a test purchase: this shows browser and server events side by side in real time, per event type — the exact screen that turns "something's wrong" into "Purchase is missing from the browser channel only." Ten minutes, zero code, and you've replaced twelve possible causes with two or three.

Symptom → cause → fix

Five symptoms, five different repairs — the diagnosis IS the fix selection.

Branch 1: ALL events dead — the loading problem

The base snippet (or your GTM container) never executes. On WordPress the overwhelming favorite is a cache or speed plugin deferring JavaScript: WP Rocket's "Delay JavaScript execution," Flying Press, LiteSpeed and friends hold third-party scripts until the user interacts — scroll, click, keypress. Visitors who land and bounce, the exact traffic you're paying Meta to measure, never trigger the interaction, so the pixel never loads for them. The fix is one line: exclude connect.facebook.net and fbevents.js from the delay/defer list, purge the cache, re-test in Incognito. The runners-up: a GTM container edited but never published (the preview works, production doesn't — the classic), a consent banner in "block until accept" mode that nobody accepts (see branch 3), a wrong or retired pixel ID pasted from an old integration, and two theme/plugin installs fighting each other. Meta's pixel docs show the canonical snippet if you need to compare against what your theme actually outputs.

Branch 2: Purchase-only — the placement problem

PageView proves your base code loads everywhere; a missing Purchase means the event call lives somewhere users never go. The classic: the Purchase snippet sits on /thank-you/, but your payment gateway redirects buyers to its own confirmation page — or a checkout app replaced the template, or a custom funnel skips the page entirely. Single-page-app checkouts add a subtler version: the "page" changes without a page load, so a pageview-triggered Purchase tag never sees a trigger — it needs a history-change or custom-event trigger instead. The robust fix for gateway flows is to stop depending on the browser at that moment entirely: fire Purchase server-side from the payment webhook (the order exists whether or not the buyer ever sees your thank-you page), with an event_id shared with the browser event so deduplication merges the copies whenever both fire.

Branch 3: some users only — the privacy layer, not a bug

If events flow but sit 20–40% under your backend, nothing is "not firing" — a share of your visitors is invisible by design. Safari and iOS strip and expire tracking parameters (iOS 26 now removes fbclid entirely), EU consent banners see 40–70% rejection rates — for those visitors the pixel is legally forbidden to fire, and firing it anyway is a compliance problem, not a fix — in-app browsers inside Instagram and TikTok mangle scripts, and ad-block share runs 15–40% depending on your niche. The honest repair kit: a server-side channel (CAPI) with rich match keys to recover the recoverable share — that's an Event Match Quality project, not a pixel project — plus the discipline to accept that a fraction of the gap is structural. What no tool can do, despite the sales pages: a server cannot forward an event the browser never created. CAPI complements the pixel; it doesn't resurrect it.

The loop that turns a vague complaint into a named branch — run it before every 'fix'.

The usual suspect is your speed optimization, the biggest 'gap' is legal, and no server resurrects an unfired browser event.

Frequently asked questions