The symptom

The account looks survivable. Conversions are down a bit, cost per acquisition is up a bit, and every explanation on the table is plausible enough to get through the client call. Creative fatigue, a softer month, more competition. Nothing in the change history says otherwise.

Then somebody segments the same report by browser and it stops being subtle. Chrome on desktop looks like it always did. Safari sits well under it on conversions per click, returning iPhone buyers keep arriving as brand new users, and revenue that obviously came from paid search is sitting in Direct. Nobody filed a bug, because nothing failed in a way a browser reports.

At Archon Labs we see this most often on accounts where the audience skews to iPhone, so retail, hospitality, anything with heavy mobile traffic. Blended numbers are built to smooth over exactly this. The loss is not spread across your traffic, it is concentrated on one slice, and a total is the one view guaranteed to hide that.

Why do Safari and iOS lose conversions?

Because three separate mechanisms run on the same visit, and each damages a different part of the record. Kept apart they are diagnosable. Collapsed into the word "ITP" they are not.

The identity expires before the customer comes back

Safari's tracking prevention limits how long the browser will remember anything your site writes. Per WebKit, "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry", and only cookies created that way are affected. On top of that, WebKit deletes all of a website's script-writable storage after seven days of Safari use without user interaction on the site, which takes local storage and service worker caches with it.

Most analytics and ad tags write their identifier with JavaScript, so on Safari that identifier has a one week shelf life. Any consideration cycle longer than a week outlives it. The customer who compares for ten days and buys on the eleventh is a returning visitor to your client and a stranger to your measurement, so the sale gets recorded without the click that earned it. The full contrast between a browser-set cookie and a server-set one is in first-party cookies and the 400-day difference.

The click identifier never arrives

The second mechanism is not loss, it is misfiling, which is why it survives longer. Apple describes link tracking protection plainly: "Some websites add extra information to their URLs in order to track users across other websites. Now this information will be removed from the links users share in Messages and Mail, and the links will still work as expected." Apple pairs it with what it calls advanced tracking and fingerprinting protections in private browsing.

When the landing page loads without a click identifier attached, the visit has no campaign to bind to. The conversion still happens and still gets counted, it just lands in Direct or Organic. Paid search looks weaker than it is, brand looks stronger than it is, and the client draws a budget conclusion from a filing error.

Redirect chains get read as tracking

The third one catches teams who never touched a tag. WebKit counts "10 unique navigational, first-party redirects" from a domain and then rewrites all of that domain's cookies to SameSite=strict, a state it calls a SameSite=Strict jail. Link shorteners, affiliate hops and consent or geo redirects all accumulate against that counter without anyone intending to track anybody.

Going server-side does not automatically settle it

This is the part that surprises the agencies who already did the work. A server-side container reached through a subdomain that points at a vendor is still, to Safari, a third party in a costume. WebKit is explicit: it "detects third-party CNAME cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days", where cloaking means a first-party subresource resolving through a CNAME that differs from the first-party domain.

So the container runs, the events flow, the dashboard fills, and the Safari cookie still dies in a week. Having the tool is not the same as having it right. What decides the outcome is whether the cookie is written by a server on infrastructure that genuinely belongs to the site, in an HTTP response rather than by JavaScript. That distinction, in plain language, is what a first-party tag gateway actually does.

What good looks like

Start with a measurement you can run this week, before anyone proposes a project. Pull the last 90 days, segment by browser and device, and compare three things: conversions per click on Safari against Chrome, the share of conversions sitting in Direct, and the ratio of new to returning users on iOS.

Two outcomes, both worth having. If Safari tracks Chrome closely, your problem is somewhere else and you have ruled out a whole category in an afternoon. If Safari runs well below it on the same spend and the same clicks, iPhone buyers are not behaving differently, they are being recorded differently, and every optimisation decision you made on the blended number was made on a partial one. In the setups we audit, 15 to 30% of conversions are never captured at all, and that blended figure usually resolves into one segment doing most of the bleeding.

Closing it is what Archon Signal does. Conversion collection moves onto your client's own domain and runs server-side, so the identifier is written by the server in an HTTP response and can live up to 400 days instead of the one to seven the browser allows, and the click identifier is captured on arrival and held server-side rather than depending on the browser to carry it through the journey. Enhanced conversions and the platform APIs then get fed from a record that is actually complete. On a typical setup that recovers 15 to 40% more conversions than a browser-only one.

Two honest limits belong in the same breath. Nothing recovers an identifier Apple removed before the request ever reached the site, so expect the Safari gap to close rather than disappear. And consent still governs all of it, so a visitor who declined stays uncollected by design.

Frequently asked

How do I show this to a client without starting a tracking project?

One screenshot does most of the work. Put cost per click and conversions per click side by side, segmented by browser, over a period long enough to be boring. Cost per click that holds steady while conversions per click drop on Safari alone is a measurement pattern, not a market one, because purchase intent does not vary that neatly by browser.

We already run server-side through Stape, so why is Safari still thin?

Usually one of two reasons, and both are configuration rather than the tool. Either the endpoint is reached through a CNAME pointing at the vendor, which puts the cookie back under the seven day cap, or the container is real but the cookie is still written by JavaScript, which never had a longer life to begin with. Most of what we repair is a partial setup everyone assumed was finished.

Is any of this about iOS app tracking permission?

No, and the two get mixed up constantly. App tracking transparency governs cross-app tracking for native apps. Everything above happens in the browser and applies whether or not the visitor ever saw an app prompt, which is why an account with no app at all still sees the pattern.

Does fixing this change what we report, or what we earn?

Both, at different speeds. Reported conversions correct quickly, because sales that were already happening finally get recorded against the click that produced them. The commercial effect follows more slowly, since the ad platforms have to relearn from a signal that now includes the iPhone buyers they had written off as non-converting traffic.

If Safari and iOS look thin in your accounts and nobody can say by how much, request a free tracking audit and we will measure the gap on one real account.