Meta Reported 65 Purchases, Our Store Had 34: How We Reconcile Ad Data With Real Orders

Meta reported purchases vs actual orders: 65 vs 34 in our store

TL;DR: Between 15 August and 27 September 2026, Meta Ads↗ reported 65 purchases for Taolilife, the dried-peach shop we run in Taiwan. Our order database had 34 paid orders that we could trace back to Meta. Using Meta's number, ROAS looks like about 1.49; using our orders, it's about 0.78, so we were losing money (both are our estimates, method below). Nobody miscounted. Ads Manager and an order database answer different questions. We make every decision from our own orders, and we make that possible by saving the UTM tags and Meta click ID on each order the moment it's created.

This is part of a series where we publish the numbers from our own stores, including the ones that don't look good. The store's full story is on the Taolilife case page.

How big was the gap?

Test orders are excluded. The store had 38 paid orders in total over that period, NT$35,279.

65 ÷ 34 ≈ 1.9, so Meta reported 31 more purchases than we could find. Here's what that does to ROAS. Meta spend over the period was USD 1,309.76, which at 31 TWD per USD (the fixed rate our reporting system uses) is about NT$40,603.

The first row uses our average order value as a stand-in, because we didn't pull the purchase value Meta reported. The direction is the point. Ads Manager says every dollar came back as 1.49. Our orders say 0.78. The first number tells you to raise the budget. The second tells you to stop and find out what's wrong.

Cost per Meta-attributed order works out at about NT$1,194 (40,603 ÷ 34). Our own financial model put break-even at roughly NT$248–288 per order, so we're a long way off. That's a separate problem; this post is about why the two counts disagree.

Why does Meta report more purchases than you see?

We don't read this as Meta inflating numbers. The two systems are answering different questions:

• Your order database asks: where did this order come from? Each order has one source. Ours is whatever UTM or Meta click ID we stored when the order was created.
• Meta asks: was this purchase connected to my ads? If the buyer clicked or saw an ad within the attribution window, Meta counts it. Someone who saw an ad, then came back through LINE or Google and bought, shows up as Meta in Ads Manager and as something else in your database.

So some gap is normal. What matters is how big it is and whether it's stable. Ours was close to double, which is big enough to flip decisions.

Technical causes to rule out

On top of attribution, a few setup problems can make Meta over-count. We check them one by one:

In our setup, Purchase is sent only from the server, triggered by the payment gateway's webhook. The browser never sends Purchase, so the Pixel-plus-CAPI double count doesn't apply to us. We did hit the last one: our admin pages and the pages inside our LINE mini app loaded GTM for a while, which polluted our GA4↗ data.

One stretch we still can't fully explain. From 31 August to 4 September 2026 we'd just switched payment gateways, and the convenience-store map at checkout was broken: 21 checkout starts, 0 completed orders. Meta reported 17 purchases for the campaigns running in that window. We haven't split those 17 out by day and order. Attribution may have pulled in orders from later days, or something else is going on. Until we break it down, we're not drawing conclusions from it. It's just one more reason not to use the platform number directly.

What are CAPI and event_id deduplication?

The Conversions API (CAPI) sends conversion events from your server straight to Meta instead of through the buyer's browser. Browser-side Pixel events get lost to ad blockers, in-app browsers and privacy settings; server-side events lose fewer.

event_id deduplication: if the browser and the server both send the same purchase, they need to carry the same event_id so Meta knows it's one event and counts it once. Without it, it's counted twice.

Most of the big hosted store platforms build CAPI in. SHOPLINE turns it on automatically after you install Facebook Business Extension↗, EasyStore enables it once you connect Facebook↗, Shopify does it through its Facebook & Instagram app↗, and Wix has a native integration↗. The official feature lists for meepShop and SHOPSTORE, two other Taiwanese platforms, don't mention CAPI.

Built-in CAPI doesn't mean you can trust the numbers as-is. You usually can't change which events or parameters it sends, and you still have to check deduplication yourself. Whatever the platform, in the first week of working on a store we run Events Manager's deduplication check and then reconcile Meta's numbers against the store's orders. There's more on what each platform lets you change in our Taiwan e-commerce platform comparison.

How we reconcile Meta with real orders

We learned this the hard way. When Taolilife launched, orders didn't store UTM tags. Our first real order came in and we couldn't tell which ad brought it. After that we started saving the source on every order at creation. That's how we could build the "29 with utm_source=facebook, 5 with only fbc" table above.

Our process now:

1. Save the source when the order is created. UTM parameters (source, campaign at minimum) plus the Meta click ID (fbc / fbclid). When UTMs get stripped, the click ID recovers some of them. Five of our 34 orders were identified that way.
2. Send Purchase from the server, only once money has actually arrived. Trigger it from the payment gateway's notification, not from a click on the checkout button.
3. Keep a full record of every CAPI event you send. Event name, event_id, order number, send time, Meta's response. Without it you can't check whether an order was sent twice.
4. Pull both numbers on a fixed schedule. Same date range: Meta's reported purchases vs your paid orders attributed to Meta, tests excluded.
5. Track the over-reporting ratio. Ours was about 1.9. If the ratio is stable, you can use it to discount Meta's numbers. If it jumps around, go back and check your tracking.
6. Decide on your own orders. Whether to raise budget or kill a campaign depends on cost per order and ROAS from your database.

Meta's numbers aren't useless. Comparisons inside Ads Manager (which creative did better, which audience did worse) are still fair, because they're measured the same way. What you can't do is subtract them from revenue or margin as if they were orders.

FAQ

Is Meta inflating purchase numbers?

We don't think so. Meta counts purchases connected to an ad within its attribution window; your store counts where each order came from. Our gap was about 1.9× (65 vs 34), large enough to change decisions, so we always decide from our own orders.

How do I know if the Pixel and CAPI are double counting?

Check that the browser and server send the same event_id for the same purchase; Events Manager shows the deduplication status. If, like us, you only send Purchase from the server, also check for repeated payment-gateway notifications.

Is my store platform's built-in CAPI enough?

SHOPLINE, EasyStore, Shopify and Wix all have official CAPI integrations, but you usually can't change the events or parameters. Run a deduplication check and reconcile Meta's numbers against your orders anyway.

Which fields should each order store?

At least utm_source, utm_campaign and the Meta click ID (fbc or fbclid), saved when the order is created. Five of our orders had no UTM and were only identifiable through fbc.

What was the real ROAS?

About 0.78 on Meta-attributed revenue and about 0.87 on all paid revenue, against roughly 1.49 if you trusted Meta's purchase count. All three are our estimates at 31 TWD per USD.

Want us to reconcile your numbers?

If Ads Manager looks fine but the money in your account isn't growing, this gap may be why. See our e-commerce coaching service or message us on Telegram↗.

---

Explore our e-commerce coaching service →