Facebook Pixel Not Tracking Purchases? A Diagnostic Checklist for 2026

When the Meta pixel stops recording purchases, everything downstream breaks at once. Your ROAS reads near zero, the optimizer loses the signal it needs to find buyers, and campaigns that are genuinely working look like failures. It is the most damaging problem on this list precisely because it is invisible: the ads keep running, the money keeps spending, and the only sign is a number that quietly stops making sense. Here is the ordered checklist to find the break.

First, confirm it is actually a tracking problem

Before diagnosing the pixel, make sure the pixel is the issue and not the sales themselves. The two look identical from the top line: spend going out, few or no purchases recorded.

The separator is your own source of truth. Check your store backend or payment processor. If orders are coming in that Meta is not attributing, the sales are real and the tracking is broken, so this checklist is the right place to be. If your backend also shows no orders, the problem is not tracking, it is conversion, and you should be in the funnel and landing page diagnosis instead. Establish which one you have before spending an afternoon on the wrong fix.

Step 1: does the Purchase event fire at all

Start at the most basic point. Complete a real purchase on your own site, then open Events Manager and check Test Events. A healthy setup shows the Purchase event firing once, on the order confirmation page, with the correct value and currency attached.

The common failures reveal themselves immediately here. The event does not appear at all, which means it is not installed on the confirmation page or a site change removed it. It fires on the wrong page, such as the cart or a thank-you page that also loads on non-purchases, which inflates and corrupts the data. Or it fires with no value, so Meta records a purchase but cannot optimize for revenue or report ROAS. The Meta Pixel Helper browser extension gives you the same view live as you click through the site. If the event is not firing cleanly here, stop and fix this before touching anything else, because nothing below matters if the base event is broken.

Step 2: is it firing twice

The opposite failure is just as damaging. If the Purchase event fires twice on one order, your conversion count doubles, your cost per purchase looks artificially great, and the optimizer chases a number that is not real. Duplicate firing usually comes from the pixel being installed both through a tag manager and hardcoded in the theme, or from a page that reloads and re-fires the event.

In Test Events, a single purchase should produce a single Purchase event. If you see two, find the second source and remove it. This one is insidious because it makes performance look better than reality, so it rarely gets investigated until the account has been scaling on phantom conversions for weeks.

Step 3: is tracking prevention eating the browser event

If the event fires correctly in your own test but your recorded volume is still far below your actual orders, the browser pixel is being blocked in the wild. Modern browsers block third-party tracking by default, ad blockers strip the pixel entirely, and a share of your real buyers simply never send a browser event no matter how perfectly it is installed.

This is not something you fix on the pixel itself. It is the reason the Conversions API exists, and it is the next step.

Step 4: is the Conversions API set up and deduplicated

The Conversions API sends conversion events from your server directly to Meta, which sidesteps the browser blocking that drops so much of the pixel's data. In 2026 it is not optional for any serious account, it is the difference between seeing most of your conversions and seeing a fraction of them.

The critical detail is deduplication. When you run the browser pixel and the Conversions API together, the same purchase can arrive twice, once from the browser and once from the server. Meta deduplicates these only if both events share the same event ID and event name. Get the shared event ID right and you recover the conversions the browser lost while counting each real purchase once. Get it wrong and you either double-count, which corrupts everything, or you fail to send one path, which leaves the gap open. Check in Events Manager that your Purchase events show a healthy deduplication rate and that both the browser and server are contributing. A high-quality event match, with good customer information parameters passed server-side, is what makes the Conversions API actually recover the lost signal rather than just duplicate the pixel.

Step 5: account for iOS and the event limits

Some of the gap is not a bug, it is the privacy landscape, and it is worth understanding so you do not chase conversions that cannot be recovered. After Apple's App Tracking Transparency, users who opt out cannot be tracked the old way, and their conversions are modeled and delayed rather than directly attributed. On top of that, Aggregated Event Measurement caps each domain at eight prioritized conversion events for opted-out users, and only your highest-priority events get measured for them.

The practical implications are two. First, verify your domain is verified in Business Manager and that your eight events are prioritized correctly, with Purchase at the top for a store, because misconfigured event priority silently drops your most important conversion. Second, accept that a permanent, structural gap between Meta-reported and true conversions is normal now. The goal is not perfect tracking, which no longer exists, it is recovering as much signal as possible through the Conversions API and good event configuration.

Why Meta and Shopify never match

This is the question that sends people looking for a bug that is not there, so it is worth settling. Meta, Shopify, and GA4 will never report the same purchase numbers, because they count different things. Meta only counts conversions it can attribute to an ad interaction within the attribution window, and misses what tracking prevention and iOS opt-outs remove. Shopify counts every order regardless of source. GA4 applies its own attribution model. A steady discrepancy between them is expected and not a problem.

What matters is the trend, not the match. A stable gap is normal. A gap that suddenly widens on a specific day is the signal to investigate, because that is usually a real tracking break, and it often coincides with the kind of overnight ROAS drop covered in Facebook ads ROAS dropped overnight.

The checklist in order

Run these top to bottom: confirm sales are real, confirm the Purchase event fires once with a value on the right page, rule out double firing, then recover the blocked browser conversions through a properly deduplicated Conversions API, and finally configure your iOS events so your most important conversion is never the one that gets dropped. Each step assumes the one above it is clean, because a perfect Conversions API cannot fix an event that fires on the wrong page.

Tracking problems are the hardest to catch because nothing looks broken, which is why an automated check earns its keep here. FixAds reads your pixel and event health alongside the campaign data, flags when recorded conversions do not line up with spend and delivery, and tells you whether the problem is tracking or something further down the funnel, so you are not scaling on numbers that were never real. When it is tracking, this is usually the first thing worth fixing, because until the signal is trustworthy every other decision in the account is being made in the dark. For the full picture of where else campaigns break, start from the diagnostic decision tree.