Meta CAPI next to the pixel: how do you know sales aren't counted twice?

Plenty of small stores run Conversions API next to the Meta pixel and have it only half wired. The pixel fires in the browser, CAPI sends the same purchase from the server, and if the event_id doesn't match between the two, Meta counts the sale twice. That makes ROAS look great for a week, then it falls apart when you compare Meta's numbers with Shopify revenue.

I think CAPI is worth running for most stores now, mainly because browser tracking misses a real chunk of purchases to blockers and iOS limits. But I'd only lean on it once deduplication is confirmed in Events Manager, not before. Has anyone measured how big the gap was for them after going server-side?

Agreed on the order of operations, but I'd check dedup a bit differently. The deduplication indicator in Events Manager tells you browser and server events are being matched, which is useful, but it doesn't tell you whether the totals add up. A simple test catches most problems: take one full day, pull Meta's purchase count using the same attribution setting you use for ROAS, and put it next to the Shopify order count for that day. Meta often runs a little higher because of view-through and different windows, but if it's sitting at 1.5x or 2x your orders, something is firing twice.

Matching can also look fine while the IDs barely line up in some setups. Using the Shopify order ID as the event_id on both sides is the most reliable way to avoid that. Are your event_ids coming from the order, or is the browser generating a random ID?

The daily count test is the right first check, since it tells you whether the totals make sense at all. One thing to add on the ID side: deduplication needs both event_id and event_name to match. A pixel sending "Purchase" and a server event sending "purchase" won't merge, even if the order IDs are identical. So the IDs can look perfect and the sale still gets counted twice.

To verify, place a real test order and open Test Events in Events Manager. You should see one Purchase from the browser and one from the server, both carrying the same order ID. If only one shows up, the other source isn't reaching Meta at all, which is a different problem and usually a quicker fix.

Agreed on the test order, but it won't catch everything. Server events usually get sent from a webhook, and Shopify retries webhooks when the endpoint fails to respond. If your code generates a fresh event_id or timestamp on each attempt, every retry looks like a brand new purchase and the dedup match never happens. So make sure the server event uses the order ID instead of a generated value, and that a retry resends the exact same payload. A single test order won't reproduce this, which is why comparing daily counts is still the check that catches it.

Take event_time from the order's own timestamp (processed_at or created_at), not from when your server handles the webhook. If Shopify retries a few hours later and you stamp the current time, the retry carries a different time than the original send, so it's harder to trust that the two events are the same purchase. Using the order time keeps every retry identical. It also matters for the daily count test, because a retry that lands the next day would otherwise push a sale into the wrong day in Meta's numbers.

Stamping the order time helps on Meta's side too, since it only takes server events from roughly the last seven days. If a retry lands after that window it can get rejected, and the sale is left to the pixel alone. Has anyone checked how long their webhook retries actually run?

Shopify's retry window is shorter than Meta's seven days, around 48 hours as far as I know, so the Meta cutoff is rarely what breaks. What actually hurts is an endpoint that fails for a week without anyone noticing, because the pixel keeps the numbers looking normal while the server side goes quiet. My rule of thumb is to alert on webhook failures and treat any day where server purchases fall below orders as a bug to fix that day, not a gap to explain in next month's client report.

Plan around the 48-hour window, but also keep an eye on server purchases running below orders when nothing has actually failed. If your server event hangs off orders/paid, orders that get paid later, or draft orders converted in admin, may never send a purchase at all. That shows up as a steady small gap rather than a broken endpoint, so a failure alert won't catch it. Which Shopify topic is your server event tied to?

Honestly, I'm not sure the retry-with-a-different-event_time point holds. Meta's deduplication keys on event_id and event_name, so a retry with the same ID still merges even if the timestamp differs. Stamping the order time still matters, but for which day the sale lands in, not for dedup.