"I'm staring at Meta Ads and purchases have been stuck at zero." You're sure you installed the pixel, but no numbers appear. This is the most common — and most stomach-churning — problem in ad operations. And without knowing why, your bidding, budget allocation, and optimization all become pure guesswork.
Does any of this sound familiar?
- You installed the pixel, but purchases/conversions are still at zero
- It was working yesterday, and tracking suddenly stopped
- It fires in the browser, but the conversion doesn't show up in Meta
- Events Manager status sits at "Not receiving events" (gray dot)
- Meta's numbers don't match GA4 or your backend results
This guide organizes what to check, and in what order, when Meta conversions aren't showing — into five diagnostic steps. Before you randomly start swapping out the pixel, work through them top to bottom.
First principle: there are only three kinds of "no conversions"
The biggest reason diagnosis goes wrong is treating "no conversions" as a single problem. In reality, the cause always falls into one of three categories. Simply knowing which one you're investigating makes the whole process dramatically easier.
| Category | What's happening | Typical example |
|---|---|---|
| ① Pixel/tag problem | The measurement signal isn't being sent at all | Pixel missing on the completion page / not firing on that action |
| ② Settings problem | The signal arrives but isn't counted on Meta's side | Event-name mismatch, 8-event config, domain verification, deduplication |
| ③ Timing problem | Nothing's actually broken — you're waiting for it to appear | Just set up / waiting inside the attribution window |
The key point: ① and ② live in completely different places. Staring at the event-settings screen won't fix a pixel that isn't firing (①), and vice versa. Diagnostic steps 1–5 below are ordered to knock out these three categories efficiently, top to bottom.
Diagnosis 1: Is the pixel even on the completion page?
The first thing to check is whether the base pixel code and the relevant event are present on the page where the conversion actually happens (the purchase-complete page, thank-you page, inquiry-complete page, etc.).
- Even if you think it's on every page, it's a classic miss for the completion page to be a different template where the pixel is absent
- Confirming
PageViewon the homepage is meaningless ifPurchasedoesn't fire on "the page at the exact moment the result occurs"
How to check: open the completion page directly, and use Meta Pixel Helper (Chrome extension) or your browser's DevTools "Network" tab to watch for the Meta measurement request (facebook.com/tr). If it doesn't fire, the pixel is probably missing from that page. For the pixel-only walkthrough, see How to Verify Your Meta Pixel Is Firing Correctly.
Common pitfall: if "visitors reach the purchase-complete page but it isn't tracked," this Diagnosis 1 is almost always the cause. Check the exact page at the exact moment you want to measure.
Diagnosis 2: Read the Events Manager "status" and receipt
Open Meta Events Manager, find your pixel (dataset), and check its status plus the receipt of each event. It displays an important clue.
| Status | Meaning |
|---|---|
| Active (green dot) | Recently receiving events (healthy) |
| Not receiving events (gray dot) | Nothing has arrived in roughly the past 24 hours |
| Events arrive but the target one is missing | PageView comes in, but only Purchase is absent |
Stuck at "Not receiving events" … no signal is arriving. Go back to Diagnosis 1 (pixel installation/firing).
PageView comes in but Purchase doesn't … the base is installed, but only the purchase event isn't placed/firing. Confirm that action's firing in Diagnosis 3.
To watch in real time, enter your live URL into Events Manager's Test Events, complete the action, and confirm it appears in the stream within a few seconds.
Common pitfall: Test Events only shows "this exact moment" in your own environment. Drops that occur only under specific conditions — non-consenting users, a different browser, an ad blocker — may not reproduce in your single hand-tested case.
Diagnosis 3: Is it firing, and is the event name correct? (check in DevTools)
"The pixel is installed" and "the correct event is firing" are two different things. Confirm that a request is actually sent the moment the button is clicked or the completion page loads — and that the standard event name is correct.
- Open the completion page (or the action that triggers the conversion) and open the "Network" tab in DevTools
- Filter for
facebook.com/tr - See whether a request fires on that action
- Check the request contents:
id(pixel ID),ev(event name),cd[...](custom data such as value and currency)
What it tells you: which event was sent, with what parameters (the most precise view of ② firing).
Standard event names have fixed meanings: a purchase is Purchase, a lead is Lead, a completed sign-up is CompleteRegistration. A lowercase purchase or a custom typo isn't recognized as a standard event, so it won't feed optimization or appear in the conversion column. Also confirm that the value (amount) and currency on Purchase aren't missing — without them, you may get a conversion count but no way to compute ROAS (return on ad spend).
Common pitfall: with an ad blocker or browser tracking protection on,
facebook.com/tritself gets blocked and looks like "it isn't firing." Verify in a clean state with those turned off.
Diagnosis 4: The iOS 14 / AEM / domain verification / 8-event gotcha
If it's firing and being received but the number is lower than / doesn't match expectations, Meta-specific Aggregated Event Measurement (AEM) settings may be the cause. This is easy to overlook.
- Domain verification: if your domain isn't verified, you can't set event priority in AEM, and measurement is restricted
- 8-event prioritization: AEM allows up to eight prioritized standard events per domain. If you forgot to include
Purchaseamong the prioritized events, iOS users' purchases aren't fully measured - iOS (ATT) / signal loss: because the measurable scope shrinks for users who decline ATT (App Tracking Transparency), part of iOS traffic is modeled or dropped
These aren't "broken" — they are cases where data is structurally reduced. For details, see Why iOS 14 and AEM Make Your Conversions Drop.
Common pitfall: if "Meta shows clearly fewer purchases than your web backend," an unverified domain, a missing 8-event config, or iOS signal loss are the prime suspects. Checking pixel firing alone won't surface this.
Diagnosis 5: Is it being dropped by a blind spot (consent mode, attribution window, deduplication)?
If you've found no problems so far yet numbers are missing or low, suspect a blind spot where measurement is dropped or misaligned.
- Consent mode (cookie consent banner): when users haven't consented, browser event sends can be stopped or restricted. For details, see Why Consent Mode Makes Your Conversions Drop
- Attribution window: Meta's default is 7-day click and 1-day view. For long-consideration products, too short a window means results you should be capturing don't appear in the report
- Deduplication and
event_id: if you run the browser pixel alongside the Conversions API (CAPI), they must share the same event name andevent_id— otherwise you get double counting or missing events
Common pitfall: if "even when I go through the completion page myself, nothing is tracked," you may be testing without consenting, or an ad blocker may be active. Don't conclude "zero = broken" from your own restricted test.
It may look like "nothing," but you're just waiting for it to report
A surprisingly common case: panicking when nothing is actually broken. Meta conversions have a reporting delay from when they occur to when they appear in the dashboard, and they keep accumulating later within the attribution window (7-day click by default).
If you decide "it's zero, it's broken" right after setup or swapping a pixel and start changing event settings, you may break healthy wiring instead. First wait a few hours to the next day, and confirm whether it's still zero. To verify in real time, Diagnosis 3 (firing check in DevTools) and Test Events are the tools.
Diagnostic quick-reference
A table that points you to the first place to suspect, based on the symptom.
| Symptom | Suspect first |
|---|---|
| Status stuck at "Not receiving events" | Diagnosis 1 & 3 (pixel installation / firing) |
| At the completion page but zero | Diagnosis 1 (pixel missing on completion page) |
PageView arrives but Purchase doesn't |
Diagnosis 3 (purchase event firing / event name) |
| Conversion count shows but value/ROAS is empty | Diagnosis 3 (missing value / currency) |
| Meta shows clearly fewer purchases than the web | Diagnosis 4 (domain verification / 8-event / iOS signal loss) |
| Was working yesterday, suddenly stopped | Diagnosis 1 & 5 (pixel change / consent or dedup change) |
| Nothing tracked when I test myself | Diagnosis 5 (testing without consent) / Diagnosis 3 (ad blocker) |
| Zero right after setup | Check the reporting delay (timing / attribution window) first |
Google Tag Manager (GTM) pitfalls to watch for
If you use GTM to deploy your Meta pixel, there are GTM-specific failure modes that the five diagnostic steps above won't surface directly:
- Unpublished container: Adding or editing tags and triggers in GTM draft mode doesn't take effect until you click "Submit" and publish. The tag can look correct in preview but never reach real visitors
- Trigger misconfiguration: A trigger set to fire on "Page View" won't fire on a button-click conversion. Make sure the trigger type (page load, click, form submission, custom event) matches the actual user action that constitutes the conversion
- GTM preview vs. production: GTM's preview/debug mode can show the tag firing, but if the container version in production is older, real visitors get the previous (possibly broken) version. Always confirm the published version number matches what you tested
- Multiple containers or tag conflicts: If more than one GTM container is loaded on the same page, or if the pixel is installed both directly in the HTML and via GTM, you can get duplicate events or conflicting behavior
If you suspect a GTM issue, open GTM's preview mode, walk through the conversion action, and confirm the Meta pixel tag fires on the correct trigger with the correct pixel ID.
Wrong pixel ID or duplicate pixel installations
A surprisingly common cause of "zero conversions" is using the wrong pixel ID. If you manage multiple ad accounts or have worked with agencies, you may have more than one pixel. The pixel fires correctly, but the data goes to a different ad account's dataset — so the account you're watching shows nothing.
How to check: Copy your pixel ID from Events Manager, then search your site's source code (or GTM container) for that ID. If you find a different ID, or if the same page loads two different pixel IDs, that's the problem.
Duplicate pixel installations — the same pixel loaded twice on one page — cause a different issue: double-counted events. This inflates your conversion numbers and distorts optimization. Use Meta Pixel Helper to check how many times the pixel fires per page load; it should be exactly once per PageView.
Comparing conversion numbers: Meta vs GA4 vs backend
When Meta's reported conversions don't match GA4 or your backend, the gap often isn't a bug — it reflects structural differences in how each platform counts. Before assuming something is broken, understand these differences:
| Factor | Meta | GA4 | Backend |
|---|---|---|---|
| Attribution model | Click-through + view-through (default: 7d click, 1d view) | Last-click (default) or data-driven | Direct transaction record |
| Counting method | One conversion per ad interaction within the window | Session-based | Order/event record |
| Signal source | Pixel + CAPI + modeled data | gtag / GA4 tag | Server logs / database |
| Consent impact | Drops or models non-consenting users | Drops or models depending on consent mode | Unaffected |
A 20–40% gap between Meta and your backend is normal when you rely on browser-only tracking (no CAPI). If the gap is larger, revisit Diagnosis 4 (domain verification, 8-event config) and Diagnosis 5 (consent mode, deduplication). For a deeper look at why numbers diverge across platforms, see Why Google Ads and GA4 Conversion Counts Don't Match.
What diagnosing on your own machine can't tell you
Diagnostics 1–5 are all useful, but checking once on your own machine has two structural limits.
- Your environment isn't your visitors' environment. Login state, extensions, office IP, consent state and the like mean it can look fine on your machine yet be missing under real visitor conditions.
- Conversions involving an ad click are hard to verify. To properly see "does it really track via an ad," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.
Judging "it fires on my action, so it's fine" tends to miss the problem of data going missing on the real path your visitors take.
A checklist to verify with confidence
- Is the base pixel on the completion page?
- Does the target event (e.g.
Purchase) fire on that action (facebook.com/tr)? - Does the event name exactly match a standard event name (
Purchase,Lead,CompleteRegistration, etc.)? - Are the
valueandcurrencyon the purchase event present and correct? - Is the domain verified, with
Purchaseincluded in AEM's 8-event prioritization? - With CAPI, do the browser and server events share the same event name and
event_id(deduplication)? - Is the attribution window not too short for your product's consideration period?
- Is data missing not just in your single hand-tested case, but under real production user conditions?
Frequently asked questions
Q. I installed the pixel but purchases stay at zero. A. In rough order of likelihood: ① the purchase event isn't on the completion page or isn't firing (Diagnosis 1 & 3), ② the event name doesn't match a standard event name (Diagnosis 3), ③ reporting delay (timing / attribution window), ④ an unverified domain, a missing 8-event config, or consent mode stopping measurement (Diagnosis 4 & 5). Work through this article from Diagnosis 1.
Q. It fires in the browser, but no conversion shows in Meta. A. "Firing (②)" and "Meta receiving/counting it (③)" are two different things. Consent state, iOS signal loss, a deduplication mismatch with CAPI, or domain-verification/8-event settings can all mean it fires yet isn't counted. Check Diagnosis 4 & 5.
Q. What's the difference between "Not receiving events" and "events arrive but are few"? A. "Not receiving events" means nothing has arrived (recently) from the pixel (a pixel-side problem = Diagnosis 1 & 3). "Arrive but few" means they do arrive but are reduced by a blind spot (consent, iOS, attribution window = Diagnosis 4 & 5). Where to look changes accordingly.
Q. Even when I go through the completion page myself, nothing is tracked. A. Possible causes: testing without consenting, an ad blocker blocking the request, or office-IP effects. After consenting, verify firing in DevTools and Test Events in a clean environment with blockers turned off.
Q. Is it more reliable to click the ad to verify? A. No. Clicking your own ad is treated as a policy violation (self-click) and risks account review or suspension. Verify from outside your own account — in an independent environment.
Conclusion: isolate top-down, then verify on the real path
"No Meta conversions" only has three kinds of cause: ① pixel/tag, ② settings, ③ timing. Isolating in order — Diagnosis 1 (installation) → 2 (status/receipt) → 3 (firing/event name) → 4 (iOS 14/AEM, domain verification, 8 events) → 5 (consent, attribution, deduplication) — gets you to the cause without randomly touching the pixel. For the full picture of Meta measurement, see the Complete Guide to Meta Conversion Tracking.
But firing checks on your own machine have limits. Going further — confirming the data is actually recorded, on the real path your visitors take, in production — is what "it's tracking" truly means.
ConversionOK runs your live page in an independent, isolated browser and intercepts the Meta events actually sent (standard events such as Purchase, with value and currency), then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your measurement.