How to check if your Meta Pixel is working, and counting correctly
The short answer: use Events Manager's Test events and a real test order. A working setup shows exactly one Purchase per order, with a value and currency, and if you also use the Conversions API, the browser and server events share an event_id and show as de-duplicated.
"The pixel is installed" and "the pixel is counting correctly" are different claims. Most problems live in the gap between them.
Meta optimises your campaigns on the conversions it receives. If Purchase stops arriving, or arrives twice, the algorithm learns the wrong lesson and keeps spending. Here is how to check it properly.
Step 1: find every pixel on the site
View the source and search for fbevents.js and fbq('init'. Note every pixel ID. Then check the Network tab for requests to facebook.com/tr, which catches pixels loaded by apps or a tag manager. You are looking for:
- The same pixel installed twice, for example a hardcoded snippet left in the theme after connecting a platform integration. Every event doubles.
- Old pixels from a previous agency or ad account still firing.
- No pixel on a site that is running Meta ads.
The Meta Pixel Helper browser extension lists the pixels and events on each page and warns about some duplicates.
Step 2: watch events arrive with Test events
In Events Manager, select your dataset, open Test events, and open your site from there (or use the test code it gives you for server events). Browse a product, add to cart, start checkout. Each should appear within seconds: PageView, ViewContent, AddToCart, InitiateCheckout.
Step 3: complete a test purchase and read the payload
Place a real low-value order and watch for Purchase. Then open it and check:
valueis present and matches the order total.currencyis present, for exampleGBP.content_idsmatch your catalogue IDs, if you run catalogue or dynamic ads. Mismatched IDs break product-level optimisation.- It arrives once. Reload the confirmation page and check it does not fire again.
Want to know which pixels are on your site right now? AuditTag detects the Meta Pixel, GA4, Google Ads and Tag Manager on your public pages. Run a free audit →
Step 4: check browser and server de-duplication
If you send events through the Conversions API as well as the pixel (many platform integrations do this automatically), each purchase reaches Meta twice by design. Meta treats them as one event only when the event name matches and the event ID is identical on both. Check:
- In Test events, the Purchase shows as received from both browser and server, and marked as de-duplicated.
- In the pixel code, the purchase call passes an event ID:
fbq('track', 'Purchase', {...}, {eventID: 'order-1234'}), and the server event sends the same value asevent_id. - In Events Manager's Diagnostics, there are no warnings about de-duplication or missing parameters.
A missing or mismatched event ID is one of the most common reasons Meta's purchase count is inflated.
Step 5: check Event Match Quality
For server events, Events Manager shows an Event Match Quality score: how well Meta can connect the event to a person, based on the customer information parameters you send (hashed email, phone and so on, within what your privacy policy and consent allow). A low score means fewer conversions can be attributed to ads, even when the event itself fires perfectly.
Step 6: reconcile with your orders, knowing what Meta counts
Compare a week of Meta-reported purchases with your real orders. Meta will usually differ, for reasons that are not faults:
| Difference | Why | Fault? |
|---|---|---|
| Meta shows more than the store | Default attribution counts views as well as clicks | Not by itself |
| Meta shows far more, on every day | Duplicate pixel, or browser and server events not de-duplicated | Yes |
| Meta shows fewer | Only ad-attributed sales count; ad blockers; declined consent | Usually not |
| Meta dropped to near zero on one date | Pixel removed or broken by a theme, app or checkout change | Yes |
How AuditTag handles it
What AuditTag checks
- Whether a Meta Pixel is detectable on your public pages
- Analytics installed but no advertising conversion pixel at all
- Re-checks after deploys so a pixel that disappears is flagged (Guardrails)
What this doesn't prove
AuditTag does not read your Events Manager, so it cannot see de-duplication, Event Match Quality or what Meta actually received. Detecting the pixel doesn't prove Purchase fires with a value. Automated browser-versus-Conversions API cross-checking is not built yet: in Guardrails early access it is a hands-on concierge review.
See which pixels your site is really running
The free audit reads your public pages and lists the tracking it can detect, Meta Pixel included, and flags a missing conversion pixel. About a minute, no account, nothing installed.
Run a free audit →Questions people ask
How do I know if my Meta Pixel is working?
Open Events Manager, choose your dataset (pixel), go to Test events, enter your website URL and browse it. Events should appear within seconds. For purchases, complete a real test order and confirm a Purchase event arrives with a value and currency. The Meta Pixel Helper browser extension shows the same thing from the page side.
Why does Meta report more purchases than Shopify?
Partly by design: Meta's default attribution includes view-through conversions (people who saw an ad but did not click), so it credits sales other tools do not. Beyond that, the usual causes are duplicate pixels, browser and Conversions API events that are not de-duplicated because event_id is missing or different, and Purchase re-firing on page reload.
What is event_id and why does it matter?
When you send the same event from the browser pixel and from the Conversions API, Meta needs a way to know they are one event. It matches them on the event name plus an identical event ID. If the ID is missing or differs between the two, Meta counts both, and your purchases double.
Do I still need the pixel if I use the Conversions API?
Meta recommends running both: the browser pixel and the Conversions API together, de-duplicated. The server-side events survive ad blockers and browser restrictions; the browser events carry signals the server may not have. The combination only works if de-duplication is set up correctly.