Two different gaps
When Ads Manager shows fewer purchases than your store, two very different things can be going on, and they need different fixes.
- Attribution. Meta only credits purchases to its own ads, inside its attribution window. A customer who bought after a Google search will never show up as a Meta purchase. That is normal and not something to "fix".
- Signal loss. The purchase never reached Meta, or reached it without the identifiers Meta needs to connect it to a click or a person. This is a real problem: the algorithm optimizes on a smaller, skewed sample of your buyers, and your reported ROAS looks worse than reality.
So stop comparing attributed purchases with orders. Measure how many purchases Meta received, and how many of those it could match. That is the gap you can close.
Rule of thumb: real orders → events Meta received → events Meta could match → purchases attributed to Meta ads. Only the first two steps are losses.
Step 1. Compare like with like
Before you look for a broken tag, remove the differences that only look like losses.
- Time zone. If the store and the ad account use different time zones, daily numbers shift between days. Align the time zones; converting reports to UTC doesn't solve it.
- Date basis. Your store reports by order date. Ads Manager reports by impression or click date by default, and late conversions keep arriving for days. Compare at least 14 days, not yesterday.
- Currency and value. Check that both sides use the same currency and that the value sent is the order total you expect, with or without shipping and tax.
- Test and draft orders. Exclude them from your order count.
Step 2. Count what Meta actually received
Ads Manager shows attributed purchases. Events Manager shows received events, which is what you need.
- Open Events Manager, choose your dataset (pixel) and open the Purchase event.
- Look at the total number of events for the last 14–28 days and split it by connection method: browser and server.
- Put the daily totals next to daily orders from your store in a sheet.
Read the result like this:
| What you see | Likely meaning |
|---|---|
| Received ≈ orders, attributed much lower | Mostly attribution. Tracking is fine; look at match quality next. |
| Received clearly below orders | Signal loss. Purchases don't reach Meta at all. |
| Browser events dropped on a specific date, server steady | A browser tag stopped firing. Check step 3. |
| Only browser events, no server events | No Conversions API. Every ad blocker or declined banner is a lost purchase. |
| Received above orders | Duplicates. Check step 4. |
Step 3. Check where the purchase is sent from
A purchase tag that used to work can stop firing without anyone touching it: a theme update, a new checkout, a removed app. Find out exactly which code sends Purchase today, and from where.
- Confirmation page scripts. Many platforms are retiring custom code on the order confirmation page in favor of sandboxed tracking pixels. Code pasted there years ago may no longer run.
- Integrations. Check that your platform's official Meta integration is connected, subscribed to purchase, with data sharing at the highest level your consent setup allows.
- Tracking apps and tag managers. Confirm with the vendor or developer which event and which page triggers Purchase now.
If your store runs on Shopify
Shopify set 26 August 2026 as the deadline for moving stores to the new Thank you and Order status pages. Code in the old Additional scripts field, or added to those pages through theme code, stops running once a store is on the new pages. Plus stores were moved earlier, so their drop, if any, happened earlier. Check:
- Settings → Checkout in Shopify: shows whether your store is on the new Thank you and Order status pages. If the switch lines up with the drop in Events Manager, you've likely found the cause.
- Settings → Customer events: the Facebook & Instagram app should be connected, subscribed to purchase, with data sharing set to the highest level your consent setup allows.
- Custom pixels in the same screen: if a developer or tracking app added one, make sure it subscribes to
checkout_completed. - Third-party tracking apps: confirm in writing with the vendor that their purchase tracking runs on Shopify's Web Pixels, not on the old Order status page.
Merchants in the Shopify Community report that stores relying only on the official Facebook & Instagram channel were often unaffected, because that integration didn't depend on the old page.
Step 4. Check deduplication
If you send purchases from both the browser and the server (you should), Meta needs a way to know they are the same order. That is the event_id: both events for one order must carry the same value.
- Place a real test order, then look for it under Test events in Events Manager. You want one browser and one server event with the same event ID, counted once.
- If the browser generates a random ID per event and the server uses the order number, deduplication silently fails and you count everything twice.
- Look for two pixels on the site, or two server integrations (for example, the native app plus a custom setup) both sending Purchase.
Duplicates are dangerous in the other direction: they inflate ROAS and hide a real loss on one side.
Step 5. Check match quality
A purchase Meta received but couldn't match to a person or click helps much less. In Events Manager, open the Purchase event and look at Event Match Quality and the list of parameters sent.
- Server events should include hashed email and phone where you have consent, plus the
fbpandfbcvalues from the browser. fbccomes from thefbclidin the ad click URL. If redirects strip it, or the cookie isn't set, Meta can't tie the purchase to the click.- Value and currency should be present on every Purchase.
Step 6. Test the hard paths: payment redirects, Safari, consent
Most tests use a card on desktop Chrome. Real customers don't.
- PayPal, Klarna and express wallets take the buyer to another domain and back. Run a real order through each and confirm the purchase arrives in Test events.
- Safari and iPhone: browser cookies set by scripts expire after 7 days, so returning buyers can look new. A server-side setup on your own subdomain helps here.
- Consent: decline cookies on your banner and buy again. In the EU the browser pixel should respect that; check that your server events follow the same consent state, and that Consent Mode is set up for Google.
What not to do while you fix it
- Don't cut budgets or change targets because of the drop alone. If Meta stopped receiving purchases, the campaigns didn't necessarily get worse. Judge them on real orders and spend for the same days.
- Don't reconnect integrations blindly. Reconnecting the Meta channel while a custom setup is running can create duplicates.
- Annotate the dates. Missed events are not backfilled, so your reports for those days will stay low. Note it so nobody draws conclusions from them later.
One-page checklist
| # | Check | Where |
|---|---|---|
| 1 | Time zones and currency match | Store settings, ad account settings |
| 2 | Received Purchase events vs. real orders, 14–28 days | Events Manager → Purchase |
| 3 | Browser and server events both present | Events Manager → connection method |
| 4 | Checkout or theme changes vs. date of the drop | Store platform settings and changelog |
| 5 | Meta integration connected, purchase subscribed | Store platform integrations |
| 6 | No legacy confirmation-page scripts relied on | Store platform settings |
| 7 | Same event ID on browser and server | Events Manager → Test events |
| 8 | Event Match Quality, hashed email, fbp, fbc | Events Manager → Purchase → details |
| 9 | Wallet, PayPal and Safari orders arrive | Real test orders |
| 10 | Consent respected on browser and server | Cookie banner + test order |
If the numbers still don't add up, or you want this done across Meta, Google Ads, TikTok and GA4 at once, that's exactly what a Signal Check does. The express scan is free.