Your Shopify pixel is losing 25% of conversions. Here's the math.

If you sell on Shopify and run paid ads, your browser pixel is missing events. Not “maybe”, not “in some cases” — measurably, predictably, every day. The only question is how much.

Most stores I look at are between 18% and 32% lossy. Here’s how to work out your number, and what closing the gap actually buys you.

Where the loss comes from

Five sources, in rough order of impact:

1. iOS Safari + ITP. Apple’s Intelligent Tracking Prevention caps first-party cookie lifetimes to 7 days (down to 1 day for some bounce scenarios) and blocks third-party cookies entirely. On Shopify, that breaks both Meta and Google attribution windows.
2. Content blockers. uBlock Origin, Brave’s built-in shields, AdGuard, Pi-hole, and corporate network filters all drop pixel requests at the browser or DNS layer. Estimates vary, but 12–18% of US desktop traffic blocks ad pixels by default.
3. JavaScript errors. Any uncaught exception earlier in the page load can stop the pixel from firing. We see this constantly on stores running 4+ third-party scripts.
4. Network drops. Mobile networks in particular drop a non-trivial slice of beacon requests. The pixel “fired”, the network ate it.
5. Late navigation. Customer hits “Buy” and immediately closes the tab. The pixel had 200ms to fire and it didn’’t make it.

Calculate your loss

Open your last 30 days of Shopify orders. Now open your Meta Ads Manager and look at “Website purchases” attributed to that same window. The ratio is your client-side capture rate.

capture_rate = pixel_purchases / shopify_orders
loss_rate    = 1 - capture_rate

If your capture rate is 0.78, you’re losing 22% of your conversions.

You can do the same exercise on Google Ads. The numbers usually agree within a couple of points.

Why this is a paid-ads problem, not just a reporting problem

If Meta only sees 78% of your conversions, two things happen:

• Your reported ROAS is wrong — your real ROAS is roughly reported / 0.78. So a “1.4x” campaign is actually 1.79x.
• Meta’s bidding model is wrong. This is the bigger one. Meta’s algorithm bids on the features of converting users. If 22% of them are invisible, the model picks worse audiences and worse placements. You pay more per conversion because the algorithm is half-blind.

Closing the loss recovers spend in two ways: better-attributed reporting and a smarter bidder.

What server-side tracking actually fixes

Server-side conversion APIs (Meta CAPI, Google Enhanced Conversions, TikTok Events API) sidestep most of the five loss sources because they run on your server, not in the shopper’s browser:

• ITP and content blockers can’’t touch them.
• They don’t depend on JavaScript loading correctly.
• They don’t compete for the user’s last 200ms.

A well-configured server-side setup typically pushes capture rate from the 70s to the 95+ range. The recovered conversions then back-feed each ad platform’s bidder, which is where you see ROAS lift compound over the next 1–2 weeks.

What “well-configured” actually means

Three things matter, in order:

1. Identifier coverage. Each platform’s matching algorithm scores you on how many identifiers you send: email, phone, name, address, IP, user agent, click ID. Meta calls this Event Match Quality (EMQ). The bidder weights high-EMQ events more.
2. Deduplication. If you send a purchase from both the browser pixel and the server, you need to dedupe on event_id so the platform counts it once. Stores that screw this up double-report and tank their reported ROAS.
3. Consent. None of this is allowed without consent in the EU/UK and most US states. Server-side fanout has to be gated on the visitor’’s consent state, with replays for upgrades.

This is what eventabee does: server-side capture, identifier enrichment, dedup on event_id, and a geo-aware consent layer with replay. Install it from apps.shopify.com/eventabee and you’ll see your capture rate in the Performance dashboard within an hour.

What to do if you want to fix this yourself

If you’d rather build it: Meta has reasonable CAPI docs, Shopify has Web Pixel APIs, and there’s a small mountain of edge cases around consent, identifier hashing, and Shopify’s checkout. Budget a few engineer-weeks. The work isn’t hard, just unforgiving — get the identifiers wrong and you’ll do worse than the browser pixel you replaced.

If you’d rather not, that’s why eventabee exists.