Shopify orders = distinct eligible order IDs after status and scope filters
“Eligible” must be written down: stores, sales channels, test orders, cancellations, refunds, and the date field all matter.
Two measurement objects
Attributed purchase events are not an order ledger
A Shopify order can exist without a Meta touch or a successfully matched purchase event. A Meta-attributed purchase can be assigned to a reporting date or campaign using platform rules that do not match the order’s creation date. Other ad platforms may also claim the same order.
event match rate = matched purchase events ÷ eligible Shopify orders
This requires implementation-level event or order identity. Platform campaign reports alone may not expose an order-level identifier.
claim ratio = Meta purchase conversions ÷ eligible Shopify orders
Use this as a discrepancy signal only. It is not Meta’s causal share of orders and can exceed expectations because the numerator and denominator follow different rules.
Disagreement matrix
Where the gap usually enters
| Mechanism | Meta Ads view | Shopify view | Diagnostic |
|---|---|---|---|
| Measurement object | Purchase actions attributed to ads under platform rules. | Distinct orders recorded by the commerce system. | Label every chart “attributed purchases” or “observed orders,” never simply “conversions.” |
| Collection coverage | Depends on Pixel, Conversions API, consent, browser behavior, and matchability. | Does not require an advertising event to create the order. | Compare event logs with orders where available; do not infer tracking health from campaign totals alone. |
| Browser/server deduplication | Browser and server events need consistent event identity to avoid double counting. | One order remains one order ID. | Inspect browser/server event IDs, event names, timestamps, and order references. |
| Attribution and lookback | Uses configured and platform-supported attribution windows and identity rules. | Does not assign advertising credit to create the order record. | Record the Meta attribution setting with every extract and compare alternative windows separately. |
| Date assignment | Reporting may assign credit using ad-interaction or conversion reporting rules. | Typically groups using an order date in the store timezone. | Compare the same cohort by order ID, not just daily totals. |
| Status and refunds | A reported purchase may persist unless later adjustment tracking and platform processing change it. | Orders can be cancelled, refunded, or edited after creation. | Choose created-order, paid-order, or net-after-refund policy and state the close window. |
| Value and currency | Purchase value comes from the event payload and platform reporting currency rules. | Order facts can contain item, discount, refund, tax, shipping, and original currency components. | Compare matched orders on one explicit value formula and currency policy. |
| Cross-platform overlap | Meta can claim a purchase that another platform also claims. | The underlying order is still counted once in the store. | Never sum platform-attributed conversions and call the result total incremental orders. |
| Modeling and privacy | Some platform results may use statistical estimation or aggregated signals. | The order ledger does not reproduce the platform’s attribution model. | Keep modeled or attributed fields labeled; do not force a row-level explanation where the source cannot provide one. |
Diagnostic sequence
Separate implementation health from attribution policy
- Define the Shopify denominator.Freeze the date range and list eligible stores, order statuses, channels, test-order rules, refund policy, and currency.
- Validate event generation.For a controlled sample, confirm the purchase event fires with the intended value, currency, event ID, and order reference. Test browser and server paths independently.
- Validate deduplication.Where the same purchase is sent by Pixel and Conversions API, verify that both copies use the same event identity and compatible event details.
- Measure collection coverage.If implementation logs expose event-level IDs, classify Shopify-only, event-only, duplicate, and matched records. Do not use Meta-attributed campaign conversions as a substitute for raw event coverage.
- Align reporting definitions.Match timezone, extraction timestamp, currency, value basis, and status. Keep conversion date and order date differences visible.
- Apply attribution last.Record Meta’s attribution window and reporting setting. Compare attributed conversions with eligible orders as two labeled series, not as a forced one-to-one ledger.
- Track the residual by cause.Report collection loss, duplicates, unmatched identities, timing, adjustments, and attribution effects separately.
Required evidence
Reports and fields to collect
Meta Ads reporting
Use campaign, ad set, or ad reports with spend, purchase conversion count, purchase conversion value, account currency, date, account, campaign identity, and the recorded attribution setting. Preserve the native platform meaning.
Shopify Orders
Use distinct order IDs with timestamps, status, store or channel, currency, discounts, refunds, tax, shipping, and the revenue components needed for your policy.
Pixel and Conversions API evidence
Where available, inspect event name, event ID, order reference, timestamp, event source, value, currency, test status, and diagnostics. Metric Hive report ingestion should not be assumed to replace implementation logs that the source does not expose.
Definition evidence
Open contract library
Trace every metric to its report contract
Use the Semantic Contract Library to inspect report fields, then review the Meta Ads connector and Shopify connector pages for source-specific coverage. Check report grain and semantic capability before joining or aggregating them.
Interpretation limits
What a clean reconciliation proves
Can prove: event coverageWith event-level evidence, identify which eligible orders produced valid purchase events and where duplicates occurred.
Can prove: definition alignmentShow how status, value, currency, date, and scope choices change the comparison.
Can prove: reporting differenceKeep observed orders and platform-attributed purchases distinct and reproducible.
Cannot prove: incremental liftA platform attribution result is not a randomized incrementality estimate.
Cannot prove: exclusive creditMultiple platforms can claim the same outcome under their own attribution systems.
Cannot always prove: row-level causeAggregated or modeled source results may not expose enough identity to reconcile every attributed conversion to an order.
Primary sources: verify current Meta and Shopify behavior
Meta's event products and reporting controls evolve. Check the active setup and Ads Manager settings in your account, and use current official documentation before treating an implementation or attribution rule as fixed.
Related guides
Put the comparison in context
Build reporting that does not erase attribution caveats
Metric Hive is built to preserve source metric meaning while applying explicit grains, date rules, currency policies, and canonical commerce definitions. It can make the gap explainable; it cannot turn platform-reported attribution into causal incrementality.