TRACKFIX · Shopify tracking repair
Guide · Meta CAPI dedupe
Shopify DTC · Pixel + CAPI

Shopify Meta CAPI Not Deduplicating? Fix Duplicate Purchases Without Guessing

Events Manager shows ~2× Purchases vs Shopify — or browser and server events that never merge. If Shopify Meta CAPI not deduplicating is the search that brought you here, the usual culprit is a mismatched or missing event_id across Pixel and CAPI paths. Here’s the contract, where Shopify stacks break, and when a $497 prepaid diagnostic is worth it.

What dedupe actually requires (same event_name + event_id)

Meta deduplicates a browser Pixel hit and a server Conversions API hit when both share the same event_name (e.g. Purchase) and the same event_id inside Meta’s matching window. Same order, two different IDs = two Purchases. Missing ID on one path = same failure mode.

Pick one shared key and force both paths to use it — typically Shopify order id, order name, or checkout token — then stick to that scheme. “We send CAPI” is not enough. “We send CAPI with a random UUID while Pixel uses order name” is how Meta purchase events duplicate Shopify reality.

Practical test: place a $1 test order (or use Test Events). In the Purchase payload, copy the browser event_id. Find the server event for the same order. If the strings differ by even one character — order name #1001 vs numeric id 5678901234 vs a UUID — Meta will not merge them. Fix the generator once; do not “average” the discrepancy in a spreadsheet and call it attribution.

event_id missing on Shopify is often a config gap, not a platform bug: Customer Events custom pixels that fire Pixel without passing the order key; GTM tags that use {{Random Number}}; CAPI apps defaulting to their own idempotency key while the channel app uses Shopify’s. Inventory beats intuition.

Contract: one Purchase per order after dedupe = shared event_name + shared event_id on browser and server. Everything else is stack inventory.

Where Shopify stacks break

Duplicates are almost never “Meta being weird.” They are multiple senders without a shared ID:

Related breakage after Checkout Extensibility: purchase never fires on thank-you, so someone adds a second CAPI path “to be safe.” That fixes undercount theater and creates overcount. See our Checkout Extensibility tracking guide for the rebuild path; see the GA4 ↔ Shopify purchases guide when the store number and GA4 also disagree.

EMQ vs purchase fidelity

Event Match Quality measures parameter richness (email, phone, fbp/fbc, etc.). It does not prove your Purchase count matches Shopify. You can have decent EMQ and still double-count. You can have mediocre EMQ and still be directionally honest on order volume.

Chasing “EMQ 8.5+” without checking dedupe is theater. Fidelity here means: after Meta’s dedupe, Purchase count is explainable vs Shopify paid web orders for the same window — not that every advanced matching field is perfect.

Signal table (symptom → cause)

SignalWhat you seeLikely cause
~2× Purchases vs ShopifyEvents Manager Purchase ≈ 2× ordersTwo senders; event_id missing or mismatched
“Deduplication parameters” warningDiagnostics complain on PurchasePixel or CAPI omitting event_id (or both sending different ones)
Browser + server unpairedOverview shows both; rarely mergedDifferent ID schemes (order name vs id vs UUID)
High EMQ, wrong volumeQuality looks fine; finance hates the numberDedupe failure, not match-quality failure
Only CAPI, no browserServer-only PurchasesPixel blocked or never installed — different problem than double count
Sudden double after “fix”Added CAPI app / GTM / sGTMStacked on native channel without killing the old path

15-minute checklist

  1. List every Purchase sender: Meta channel app, GTM web, GTM/server CAPI, theme Pixel, third-party CAPI apps.
  2. In Events Manager → Test Events / recent Purchase: open a single order and note browser vs server event_id.
  3. Confirm both paths use the same ID string for that order.
  4. Compare 7–14 days Meta Purchases (after dedupe if shown) to Shopify paid web orders.
  5. If gap ≈ 2× or diagnostics scream missing dedupe params → stop adding apps.

Decide: one sender + matching event_id + explainable volume → monitor. Multiple senders or mismatched IDs you cannot reconcile in 15 minutes → AUDIT-497, not another install.

Still seeing duplicate Purchases?

AUDIT-497 quantifies Shopify ↔ GA4 ↔ Ads variance in 72 hours from confirmed access. $497 prepaid; credits into a Tracking Sprint.

Soft CTA · diagnose only on the audit · live fixes = Sprint

When SERVER-50 (not more Pixel paste)

If the honest fix is a single authoritative server path (sGTM / hardened CAPI), checkout redirects dropping browser hits, or privacy-aware routing — that is SERVER-50 Sprint territory, not another theme snippet. AUDIT-497 still comes first: quantify the mismatch and recommend the tier. Do not paste a third Pixel “while you’re in there.”

AUDIT-497: quantify ads↔store mismatch in 72h

No live tag changes on the audit. No ROAS guarantee. No ad management.

FAQ

Does Meta always need CAPI on Shopify?

Browser Pixel alone under-reports under ITP, blockers, and redirects. CAPI helps only when it shares event_id with the browser event so Meta can dedupe.

Will matching event_id fix my ROAS?

No. It fixes double-counting and noisy optimization. Creative, offer, and spend still drive results. We do not guarantee ROAS.

Is the native Facebook & Instagram app enough?

Sometimes — if it is the only Purchase source. Stacking GTM, leftovers, or a second CAPI app without a shared ID is what breaks dedupe.

Will you fix tags for $497?

No. $497 is diagnosis. Fixes are fixed-scope Sprints; audit fee credits into the first Sprint within 30 days.

Do you guarantee ROAS?

No. Signal fidelity only. Media stays yours.

Quantify the ads↔store gap

If Meta Purchases and Shopify disagree and DIY cannot reconcile event_id, buy the diagnostic.

$497USD · prepaid

What’s included on fixmypixels.com · GA4 vs Shopify · Checkout Extensibility · 72h from confirmed access · credits into Sprint