Article
Safari ITP, ad blockers and the pixel Shopify paused: what you actually lose
Three causes of loss almost always end up in the same paragraph and carry very different weight. One is large, one is smaller than it's made out to be, and the third arrived on 13 January 2026.
Three causes of loss almost always end up in the same paragraph, and they carry very different weight. One is large and well known, one is smaller than it’s made out to be, and the third arrived on 13 January 2026 without anyone announcing it to merchants. This guide separates them and says how much you actually get back.
Category: implementation · 12 minute read · Mattia Minafò · updated 18 August 2026
What this is about
You’ve read that ITP and ad blockers cost you 20 or 30% of conversions, you’ve put in the server channel, and you can’t say how much you actually recovered or where the rest went.
The questions this guide answers: how much each of the three causes weighs, how much of it the server channel recovers, and what stays out regardless.
In order: what ITP does to cookies and since when, how much ad blockers really weigh, what changed on Shopify in January, how much is recovered according to the vendor and according to our own measurements, the limit nobody writes down, and the checklist.
Method and limits. Safari’s behaviour is verified on WebKit’s blog, the Shopify change on the official changelog, both as of 18 August 2026. Project numbers come from our own audits, with the window stated. This is not a guide to debugging your setup.
You’ll find three labels in the text. Documentation when the source is official, measured by us when the number comes from one of our audits, recommendation when it is a professional judgement rather than a fact.
Contents
- What ITP really does to your cookies, and since when
- Why a cookie written by the server doesn’t necessarily last longer
- How much ad blockers weigh, which is less than you’re told
- The pixel Shopify paused on 13 January 2026
- How much is recovered, according to the seller and according to us
- The limit nobody writes down
- The checklist
What ITP really does to your cookies, and since when
The dates circulate wrongly, and they get the version wrong as well as the year.
Documentation. The seven-day cap on persistent cookies written by JavaScript arrives with ITP 2.1, on 21 February 2019, not with Safari 12 in 2018. WebKit writes that “all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry”. Session cookies are out of scope.
The restriction then widened three times.
| When | What changed | What it hits |
|---|---|---|
| February 2019 | 7-day cap on cookies written by JavaScript | _fbp, _ga and any cookie set by the browser |
| November 2020 | 7-day cap on cookies written in HTTP responses with CNAME cloaking | The tagging subdomain pointing at the vendor |
| 2022 | 7-day cap on responses from third-party IP addresses | The container hosted elsewhere |
| September 2025 | Advanced fingerprinting protection on by default | Click identifiers stripped on some redirect paths |
Recommendation. The three middle rows matter more than the first, and they are the ones almost nobody cites. The next section explains why.
Why a cookie written by the server doesn’t necessarily last longer
You read almost everywhere that a cookie set by the server via HTTP header isn’t subject to the cap, and therefore lasts months again. That is true under one condition, and the condition is not having a container.
Documentation. Since 12 November 2020 WebKit also caps at seven days cookies written in HTTP responses when the subdomain resolves, via CNAME, to a domain different from yours. Since 2022 the same applies when the responding IP address is third-party.
The threshold is documented: the cookie survives if the subdomain’s address matches the site’s at least halfway, that is the first 16 bits on IPv4 and the first 64 on IPv6. Below that, seven days.
This means the tagging subdomain does two different jobs, and almost everyone buys one of them believing they got both.
| What you want | Is the CNAME subdomain enough | What you actually need |
|---|---|---|
| Not being blocked by domain-list ad blockers | Yes | Nothing else |
| Making the cookie last beyond seven days on Safari | No | A path on the same domain, or routing traffic through your own address |
Recommendation. Compare the address your tagging subdomain resolves to with your site’s. If the first two blocks don’t match, the cookie you are writing from the server on Safari lives seven days as before, and no dashboard will tell you.
How much ad blockers weigh, which is less than you’re told
The number that circulates is that 29.5% of internet users worldwide use an ad blocker. It is a real measurement, and it is the wrong thing to use for estimating your loss.
Two reasons. The first is that it measures global internet users, not the visitors of a store selling a specific product in a specific market. The second, more important, is that having an ad blocker installed is not the same as losing the event: it depends on which lists are active and which request you are making.
A useful figure comes from the vendor with the most interest in making it look big. In its event-recovery analysis, the share attributed explicitly to ad blockers is 3.29%, against a total recovery of around 20%. The rest is tracking prevention, which mostly means Safari.
Recommendation. Treat ad blockers as a minor and verifiable cause, not as half the problem. The real weight, on the stores we have measured, is in traffic composition, which is the thing to look at first.
Measured by us. On a Shopify store, in the 8 July / 4 August 2026 window, traffic was 64% Safari and 27% Instagram in-app browser on Android, over 90% together. Those are the two environments where the browser channel loses most, and they look like no published average.
The global Safari shares you find around range between 19% and 26% depending on the source and on what is being counted. That is exactly why they should be ignored: the percentage that concerns you is in your own tech report, and you can read it in two minutes.
The pixel Shopify paused on 13 January 2026
This is the least known of the three causes, and the only one that is fixed with a click.
Documentation. On 13 January 2026 Shopify changed the default setting for App Pixels from “Always on” to “Optimized”. In that mode Shopify observes incoming traffic, sales, store settings and campaign settings over time, and pauses data sharing to a pixel when it detects no signals for days or weeks, resuming when signals return.
Two clarifications that change what you should be looking for.
It only concerns App Pixels. Custom Pixels are untouched and keep working as before, with no optimisation algorithm on top.
It is not a per-visitor mechanism and it has nothing to do with consent. Shopify is not reducing data when a visitor arrives without parameters or from a private session. It is a decision taken on the pixel as a whole, based on how much that pixel appears to deliver results, and the stated reason is avoiding sharing data with inactive tools.
The difference is practical. If you look for the wrong symptom, you go and check campaign parameters. The right symptom is a pixel that stops receiving data for a period and then starts again, with nobody having touched anything.
Recommendation. Go to Settings, Customer Events, and check what mode your App Pixels are in. If a pixel is on “Optimized” and it is critical for you, you can set it back to “Always on”. Do it knowing the default existed for a reason, and that consent remains an upstream constraint in any case.
How much is recovered, according to the seller and according to us
The vendor’s number. The most cited analysis on this subject reports a recovery of 20.71% of events and 30.67% on purchases alone, across roughly seven million requests over ten days. It is real data, and it is published by the company selling the service that data justifies. The success stories accompanying it are selected by the same source.
Our independent measurement. On the same kind of comparison, on a Shopify store in the 8 July / 4 August 2026 window, we counted the events that exist only on the server channel and not on the browser one. The net contribution is 1,774 events, 23.9% of the overall signal and 31.7% on product views alone. In detail, page views 4,025 against 3,327, plus 21%. Product views 3,389 against 2,316, plus 46%.
That one measurement of ours and one of the vendor’s land three points apart does not confirm the figure. It establishes the order of magnitude, and that is already a lot: you recover something around a quarter of the signal, not half.
How much it varies store to store. The most honest account of this we heard from a technical partner on a call: there are stores where, with consent handled correctly, you lose around 20%, others where you reach 35%, others worse still, and the exact number cannot be given in advance. On two of our own stores without consent management the loss on purchases came out around 8% and 19%, well below the averages in circulation.
Recommendation. Don’t use a published number to decide. Use it to know whether yours, once measured, is in or out of scale.
The limit nobody writes down
The server channel protects the event from the browser. It does not protect it from what is missing before the browser.
Measured by us. On a Shopify store both channels were active, browser and server, and the server channel delivered almost 24% more signal. In the same window, purchase events recorded were zero.
The cause was not tracking. Comparing the order ledger with the platforms, 62% of the period’s revenue was attributed to no source at all, and over twelve months only 55% of real orders had the user journey populated. It was Shopify failing to associate the order with a browsing session.
With that link missing upstream, the server channel has no raw material to protect. It recovers views beautifully and does not save the purchase, because it too depends on the session the platform recognises.
On the same store, across 92 orders in twelve months, a single order carried campaign tracking parameters. No server channel fixes that.
Recommendation. Before buying infrastructure, compare the order ledger with the platforms over 90 days. If the distance is wide, the problem sits upstream and the infrastructure doesn’t touch it.
The checklist
Before spending
- Safari and in-app browser share read in your own tech report, not estimated from an average
- Order ledger compared with the platforms over 90 days
- Tracking parameters verified on the links of active campaigns
- App Pixel mode checked in Customer Events
After putting in the server channel
- Tagging subdomain IP address compared with the site’s
- Cookie expiry checked on a real iPhone, beyond seven days
- Deduplication measured, with the shared identifier present on all events
- Ad click identifier coverage, which below 30 or 40% is an alarm
- Server channel net contribution calculated on the events that exist only there
- Comparison with the order ledger redone after release, on the same window as before
In short
The three causes weigh differently. Safari is the largest, ad blockers much less than they are made out to be, and pixel mode on Shopify is the cheapest to fix.
The server channel recovers a real share, around a quarter of the signal on stores with heavy Safari and in-app traffic. What it does not recover is the order the platform never linked to a visit, and that check comes before all the others.
Sources
- WebKit, Intelligent Tracking Prevention 2.1, 21 February 2019, retrieved 18 August 2026
- WebKit, CNAME Cloaking and Web Privacy, 12 November 2020, retrieved 18 August 2026
- Shopify Changelog, New default setting for pixel data sharing, 13 January 2026, retrieved 18 August 2026
- Shopify Help Center, App pixels, retrieved 18 August 2026
- Google Developers, Introduction to server-side tagging, retrieved 18 August 2026
- Stape, Safari ITP guide, retrieved 18 August 2026, vendor of hosting for tagging containers
- Stape, analysis of server-side event recovery, July 2025, interested vendor
- Backlinko, Ad blocker users statistics, on DataReportal data, retrieved 18 August 2026
- Internal measurements from audits of Shopify stores, windows stated in the text
The first step
Open your store admin, go to Settings and then Customer Events, and look at what mode your App Pixels are in. If you find “Optimized” on a pixel that matters to you, you have just found the cheapest of the three causes.
It is a one-minute check. The other two require measuring, and we’re happy to talk.
Content verified against official documentation on 18 August 2026. Safari’s rules and Shopify’s settings change often; if you are reading this much later, re-check the links.