Safari runs around half of UK mobile browsing and blocks third-party tracking by default, and many of the server-side setups sold to recover what it blocks do not beat it. If your server-side container still relies on an identifier written by JavaScript in the browser, you have moved the tag, not fixed the measurement.
Because Safari undercounts conversions across roughly half your mobile audience, moving tags to a server, with server-side Google Tag Manager or Meta's Conversions API, only recovers that measurement if a genuine first-party server on your own infrastructure sets the identifier in the HTTP response. Keep a browser-written cookie and Safari throttles it exactly as it throttled the pixel you replaced.
Safari has tightened what trackers see across successive releases since 2017
Apple launched Intelligent Tracking Prevention in Safari in 2017 and has narrowed browser-based tracking ever since. ITP 2.1 in 2019 capped script-written cookies at seven days. Safari 13.1 in 2020 blocked third-party cookies by default. Later that year Apple extended ITP to CNAME-cloaked requests, closing a workaround many measurement vendors had leaned on. Not every release changes tracking behaviour, but the ones that do all pull in one direction: the browser carries fewer of the firms that ride inside it to measure and target.
The tags your platforms drop into a Safari session, such as the GA4 tag and the Meta Pixel, now see less of what a visitor does. Not because the visitor did less, but because Apple decided the browser should carry less of them.
Safari runs around half of UK mobile browsing, so the blind spot is close to half your mobile audience
On StatCounter's mobile browser market share for the United Kingdom, Safari sits at around 52% and has held in the low fifties across the past twelve months, well above its share in many markets because the iPhone is so common here. The figure moves month to month, so treat it as a point-in-time reading. Either way, the slice of your audience where browser-based measurement is weakest is close to half the people you are trying to count on mobile.
A fall in Safari conversions is usually lost measurement, not lost demand
When Safari blocks the cookie or pixel behind a sale, the platform either credits it to direct traffic or drops it from the report. The sale still happened; what vanished is your record of it. In the subset of UK accounts we reconcile for the Crane Index, Safari consistently reports fewer conversions than the matched sales sitting in the CRM, and the gap runs wider on mobile than on desktop. We have not counted this as a rate across every account, so read it as a recurring observation in the accounts we check, not a published universal figure.
So if your Safari mobile conversions have drifted down while actual revenue held firm, that gap is far more likely to be measurement than market. Cut a working campaign on the strength of a thinning report and you lose twice: first the visibility, then the budget pulled off something that was earning.
Server-side only beats ITP when a first-party server sets the cookie, not the browser
Server-side collection does not bypass Safari on its own. It still needs an identifier the browser hands over, and the seven-day cap applies to any first-party cookie written by JavaScript, including the standard _ga cookie, whether a browser tag or a sloppy server-side container creates it. The win is narrow and specific: an identifier your server sets in the HTTP response, which the script cap does not touch, tied back to your CRM.
Here is the line most implementations miss:
- Cookie written in the browser (via
document.cookie, including_ga): Safari caps it at seven days. Relocating the tag changes nothing. - Cookie set by your server in a
Set-Cookieresponse header, from a genuine first-party server on your own infrastructure: not subject to the seven-day script cap, and it survives long enough to join sessions to sales.
Two cautions, because competent engineers will raise them.
First, the exemption hinges on the cookie arriving in a Set-Cookie response header, not on the HttpOnly flag. HttpOnly only stops JavaScript from reading the cookie; it is sound security hygiene but it is not what earns the ITP exemption. Setting a cookie HttpOnly while still writing it in the browser buys you nothing against Safari.
Second, and this is the one that quietly breaks most deployments: if your sGTM runs on a subdomain that CNAME-points to Google's infrastructure, which is how many setups are wired, Safari treats that cookie as CNAME-cloaked and caps it at seven days too. So the honest answer to "doesn't ITP cap my server-set cookie at seven days anyway?" is: yes, if you are on a cloaked subdomain. The fix is where the server actually lives, not that you bought a server-side container.
Consent Mode modelling is fine for bid trends and useless for a board report
Server-side collection still requires consent, and here the platforms' reassurance deserves scrutiny. Under Google's Consent Mode v2 in basic mode, a declined user sends nothing. In advanced mode, the browser still fires cookieless pings that feed Google's modelling, which fills the hole with statistical estimates rather than observed sales. Either way, the conversions you did not observe are inferred, not recorded.
Be fair about where that is acceptable. For trend-level bid decisions, modelled conversions are genuinely good enough: the ad platform is optimising at the level of directional movement, and a reasonable estimate steers spend well enough day to day. What modelling cannot do is carry the weight people put on it afterwards. You cannot join a modelled conversion to a named customer, reconcile it against your ledger, or build a reliable customer lifetime value on it. Google's Enhanced Conversions and Meta's Conversions API help by sending hashed first-party data from your server to recover matches the browser lost, but they recover observed data only where you hold consent and a durable identifier. Everything else is modelled, and modelled numbers belong in a forecast, not in a board report.
Reconcile Safari against your CRM before you cut a penny
Before you act on any Safari figure, reconcile it. Pull reported conversions split by browser, then match them against dated sales in your CRM for the same period. The difference on Safari is your real blind spot: it tells you how much of the browser's weakness is costing you visibility, and it separates a drop in the report from a drop in demand. Run that reconciliation quarterly and the Safari shortfall becomes a known, trended quantity rather than a mystery that spooks the next budget review.
Then ask whoever owns your tracking one question: are your core identifiers set via a Set-Cookie response header from a first-party server on your own infrastructure, not a CNAME-cloaked subdomain, or are they still written in the browser? If it is the latter, you are reading your mobile performance off a number Safari will keep shrinking, and no amount of server-side spend has changed that.
