When Meta's numbers don't match your backend

Almost every advertiser eventually notices it: Meta’s ads manager reports one number of purchases and the store’s own backend, Shopify, a CRM, an order management system, reports a different one. Neither number is wrong. They’re measuring different things by design.

Why the two numbers diverge

Attribution window. Meta credits a conversion to an ad if it happened within a set window after a click or view (commonly a default like 7-day click and 1-day view, though configurable). A backend system just logs the order the moment it’s placed, with no concept of which ad gets credit. A sale closing nine days after an ad click may show up as a backend order but fall outside Meta’s window entirely.

View-through credit and modeling. Meta can count a conversion from someone who saw an ad but never clicked it, based on modeled attribution. A CRM has no way to record that a person merely saw an ad. Similarly, when Meta can’t directly observe a browser-side event, due to ATT opt-outs or ad blockers, it sometimes estimates conversions statistically, and those estimates appear in the platform total with no matching backend record.

Cross-device journeys. Someone clicks an ad on their phone and buys later on a laptop. Meta can stitch some of this together via login state, but not perfectly, and a backend system tied to a different customer ID scheme may not connect the two events the same way.

Deduplication and timing. A backend counts one order once. A pixel and a Conversions API event for the same order can, without correct deduplication using an event ID, get counted twice on the platform side. Separately, Meta’s reporting day may not align with the store’s timezone, shifting conversions into an adjacent day when the two are compared.

Refunds. A backend total typically reflects net revenue after refunds. Meta’s conversion count may still include an order that was later refunded or cancelled.

Which number to trust for what

Use the backend number as ground truth for how much revenue actually came in and what shipped. It’s the number for finance, inventory, and anything reconciling with real money.

Use the platform number, read consistently over time rather than compared to backend totals, for judging whether a specific ad is trending better or worse than last week. It’s directional, not absolute.

Use blended ROAS or MER, total backend revenue over total ad spend across channels, when the question is whether marketing overall is working. It sidesteps the mismatch by not relying on platform attribution at all.

How to reconcile the gap

Fix deduplication first: confirm pixel and Conversions API events for the same order share one event ID. Compare totals over a period, not per-day, and let the attribution window fully elapse before comparing. Check whether view-through conversions are inflating the platform number, and confirm timezones match. Expect a gap to remain even after all this: a small, stable gap is normal, a wide or growing one points to a specific breakage worth tracking down.

Common mistakes

Comparing same-day platform and backend totals before the attribution window has closed. Assuming the platform number is inflated rather than checking deduplication and view-through counting first. Cutting spend on a campaign because its reported conversions dropped, when backend revenue held steady, without checking whether the drop is a measurement artifact rather than an actual demand drop.

How YieldBI helps

YieldBI’s attribution layer lets you set the incremental attribution model and effective window explicitly, and pairs pixel data with Conversions API and offline conversion import so platform numbers stay closer to the backend. Growth Controls report ad-level performance against that configured model, keeping scaling decisions anchored to a consistent, reconciled view.