Tracking & Privacy
iOS, ad blockers and privacy: how much Shopify tracking are you losing?
Some real Shopify orders never show up as a conversion in Meta or Google Ads at all — not because the ad didn't work, but because Safari's tracking restrictions, an ad blocker, or a declined consent prompt stopped the browser-based purchase event from ever reaching the ad platform. There's no clean single percentage for how much this costs any given store, but the mechanism is real, documented, and worth understanding before you write off a campaign as underperforming.
What Safari's Intelligent Tracking Prevention actually restricts
ITP is Safari's built-in anti-tracking system, and it's the default on every iPhone and iPad, since Safari is the system browser there — it also runs on macOS Safari and inside many iOS in-app browsers that use Apple's WebKit engine. Two of its restrictions matter most for ad tracking. First, it blocks third-party cookies outright, which is the mechanism most cross-site ad tracking historically relied on. Second, it caps the lifespan of first-party cookies set via JavaScript for domains it classifies as having tracking capability — commonly down to about seven days — rather than the months or years a cookie might otherwise persist. A customer who saw an ad, didn't buy that session, and returned more than a week later on Safari can look to the ad platform like a fresh, untracked visitor, because the identifier that would have linked the two visits already expired.
This is a documented, deliberate privacy feature, not a bug or an edge case affecting a sliver of traffic. iOS holds a large share of mobile traffic for most Shopify stores, and Safari is the default browser on it, which means ITP's restrictions apply to a substantial, ordinary slice of a typical store's visitors, not a rare configuration.
Ad blockers are a blunter, more complete block
Where ITP narrows what a tracking script can persist, an ad blocker (a browser extension, a built-in blocking feature, or network-level filtering like some VPNs and DNS blockers) is closer to a wall. It typically works from a maintained list of known tracking and advertising domains and request patterns, and it stops the browser from ever sending the request to those domains — the Meta Pixel or Google tag script simply never loads, or its request to log an event never leaves the browser. There's no cookie lifespan to reason about because there's no successful request in the first place. Anyone running an ad blocker who completes a purchase on your Shopify store is, from the ad platform's perspective, invisible for that order — full stop, not partially tracked.
Why iOS traffic concentrates the problem
iOS traffic tends to stack several of these factors on top of each other rather than facing just one. Safari's ITP applies by default with no extra installation required, unlike a desktop ad blocker extension that a smaller share of users actively install. A large amount of iOS traffic also arrives through in-app browsers — someone tapping a link inside Instagram or another app rather than opening full Safari — which can behave differently again depending on how that in-app browser handles cookies and scripts. And Apple's broader privacy positioning across the platform, including prompts asking users to allow or block cross-app tracking, adds another layer where a customer can decline tracking before an ad platform ever gets a chance to observe anything. None of these individually guarantees tracking loss for a given customer, but together they make iOS the segment most likely to show a real gap between orders Shopify recorded and purchases the ad platform reports.
How you'd actually tell this is happening to you
This isn't something to assume from general knowledge about iOS — it's something to check against your own data. A few concrete comparisons are more useful than intuition:
Segment Shopify orders by device and browser and compare that split against the device and browser breakdown the ad platform reports for attributed conversions from the same campaigns, over the same period. If iOS/Safari makes up a noticeably smaller share of attributed conversions than it does of actual completed orders, that gap is a tracking signal.
Compare checkout completions to purchase events fired. If your analytics or Shopify data shows a checkout was completed but the ad platform's purchase event count for that period runs meaningfully below actual order count, especially concentrated on iOS traffic, that's a more direct signal than an abstract CPA comparison.
Watch for a CPA or ROAS shift that's isolated to iOS-heavy placements without a corresponding change in spend, creative, or targeting. A campaign that leans heavily on Instagram or other mobile-first placements showing a sudden CPA increase, while a desktop-leaning campaign in the same account stays flat, points toward a tracking gap rather than an actual drop in ad effectiveness.
What this does to reported ROAS and CPA
The mechanism is straightforward and easy to misread. Spend on a campaign is recorded accurately regardless of tracking loss — the ad platform always knows what it charged you. Attributed revenue is what gets undercounted, because it depends on the purchase event successfully reaching the platform. Divide accurate spend by undercounted revenue and ROAS comes out lower than the campaign actually delivered. The same logic pushes reported CPA higher than the real cost per customer acquired. A campaign that's genuinely working can look mediocre or get paused on the strength of a number that's measuring tracking loss, not ad performance.
Where an order can drop out before the platform sees it
What server-side tracking can actually fix
Meta's Conversions API and Google's Enhanced Conversions both work on the same underlying idea: instead of relying only on the customer's browser to successfully send a purchase event, your server sends it too, triggered by something like a Shopify order webhook that fires once the order genuinely exists. That path doesn't depend on whether ITP trimmed a cookie or whether an ad blocker stripped the pixel script, because it never asks the browser to be the one to report the purchase. It depends instead on your server reliably knowing the order happened, and on having enough matching data — usually a hashed email or phone number — to let the platform connect that order back to the right ad interaction.
What it honestly can't fix
Server-side tracking recovers a meaningful share of the otherwise-missed signal — it does not recover all of it, and any claim of complete or near-complete recovery, with a specific percentage attached, isn't something to trust. A few concrete limits are worth naming directly:
Consent still applies. A customer who declined tracking consent should be excluded from the server-side event exactly as they'd be excluded from the browser event. Server-side tracking changes the route data travels, not whether you're allowed to send it — it never bypasses consent, and no legitimate implementation of it does.
Matching still requires data. If a customer checks out as a guest with minimal information, or the order lacks a usable email or phone number to hash and match, the server-side event has less to work with and the ad platform has a harder time connecting it back to the original ad interaction, even though the event itself reached the platform successfully.
It doesn't reconstruct the original journey. A server-side purchase event confirms an order happened and offers matching signals for the platform to work with — it doesn't hand back the exact click or impression path that ITP's cookie expiry already erased. The platform's own matching logic decides what to credit; server-side tracking improves the odds, it doesn't guarantee the outcome.
Where Attribix fits
Attribix connects Meta CAPI and Google Enhanced Conversions to your Shopify order webhooks, so a purchase that a customer's browser never successfully reported still has a second, server-side path to reach the ad platform. See how the architecture works on Shopify server-side tracking, Meta CAPI for Shopify and Google Ads conversion tracking for Shopify.
Common questions
How much Shopify tracking does iOS actually lose?
Do ad blockers and Safari's ITP cause the same kind of tracking loss?
Does server-side tracking (CAPI) fully fix iOS and ad blocker tracking loss?
How can I tell if I'm actually losing iOS tracking, or if my ads just underperform on iOS?
Want your iOS tracking gap measured?
Send an inquiry and we'll compare your actual iOS/Safari order volume against what Meta and Google report as attributed, on your own account.