Safari ITP Cookie Restrictions: Keeping Attribution With Server-Side Tracking
The Three ITP Rules That Shrink Browser Cookies
Safari ITP cookie restrictions are documented in a series of WebKit posts, and three rules matter for conversion tracking. First, Safari became the first mainstream browser to block third-party cookies by default completely - a tracking domain's cookies from inside someone else's page simply do not exist. Second, ITP caps script-writable storage - cookies set through document.cookie and JavaScript storage APIs - to seven days, and WebKit's wording is precise: deletion happens after seven days of Safari use without user interaction on the site. Third, and harshest for paid traffic, ITP 2.2 caps persistent cookies set through document.cookie to one day of storage when both conditions hold: a domain classified with cross-site tracking capabilities navigated the user to the page, and the final URL carries a query string or fragment.
That third rule is a direct description of a paid click. An ad platform is exactly the kind of classified domain that navigates users elsewhere, and ad landing URLs are exactly the kind of decorated links - fbclid, ttclid, rdt_cid, gclid - that the rule names. The click ID itself survives fine in the URL, which is why link tracking and click ID loss is a separate problem; the cookie that was supposed to remember the user afterwards is what dies.
Why the Ad Pixel Bleeds Attribution on iOS
A browser pixel identifies the visitor with a first-party cookie written by JavaScript - precisely the storage class ITP caps. On a landing reached from a paid click, that cookie starts with a one-day ceiling. A user who converts on day three has no recognizable cookie: the pixel fires a new event about a stranger. Frequency capping, retargeting pools, and view-through attribution all degrade the same way, and the tracking background is in pixel warming.
Nothing about this is a bug in your setup - it is the documented behavior of the browser on a large share of mobile traffic. The practical consequence is a systematic gap between tracker-reported conversions and platform-reported ones on iOS Safari, on top of the delay effects described in Meta CAPI event delay. Treating the gap with more pixel tweaks does not work, because the storage the pixel depends on is the thing being capped.
The Server-Side Answer: Your Own Domain Sets the Cookie
The caps in ITP 2.1 through 2.3 target script-writable storage. A cookie delivered in an HTTP response header - Set-Cookie issued by the server your tracker runs on, for a domain you actually own - is not written by JavaScript, and WebKit's own compatibility table in the CNAME defense post distinguishes exactly this case: a first-party subdomain without cloaking gets no capped cookie expiry. That is the structural fix for the funnel: capture the click ID into your tracker on the first request, and let the tracker's server response set the identification cookie going forward.
The practical setup for a tracker-based funnel follows from it. Host the tracker on your own subdomain so the identification cookie is genuinely first-party. Keep the click ID in the URL query string and store the mapping server-side, tied to that cookie - not in a JavaScript-visible field. Store conversion state on the server, where the seven-day deletion never reaches. Treat the browser-side session marker as disposable: worst case, Safari deletes it and the click ID in your logs still links the visit to the ad. For the broader context of running attribution without relying on browser storage at all, see cookieless attribution for affiliate tracking.
CNAME Cloaking Is Not a Loophole Anymore
When ITP started capping JavaScript cookies, a workaround appeared: point a subdomain of your site at an external tracker through a DNS CNAME record, so the tracker's cookies are written under your domain's name. The WebKit answer is direct - ITP detects third-party CNAME cloaking, defined as a first-party subresource whose CNAME differs from the first-party domain, and caps the expiry of any cookies set in such responses to seven days. Their own table makes the line clear: your own subdomain resolving to your own tracker takes no cap; a subdomain resolving to an external tracker takes the 7-day cap.
The takeaway for a funnel buying iOS traffic is not to hunt for a smarter cloaking trick - it is that honest first-party deployment is the only variant the browser treats as first-party. Put the tracker on infrastructure you control, on a domain you own, and the server-side storage follows naturally; the server-side versus browser pixel comparison is the architectural frame for that choice.
What Survives and What Does Not
A compact map for planning:
- Survives: click IDs in landing URLs (
fbclid,ttclid,rdt_cid) - query parameters, not storage. Session and conversion records on your own server. And server-delivered conversion events - the conversions API channel does not depend on the browser remembering anything. - Degrades to 1 day: pixel-set cookies on landings reached from classified ad clicks with decorated links.
- Degrades to 7 days elsewhere: script-writable cookies generally (after seven days of Safari use without interaction), plus cookies set in third-party CNAME-cloaked responses.
- Never existed: third-party cookies from embedded trackers, fully blocked by default.
The funnel consequence: measure and optimize through channels that do not lean on the degrading rows. Server-side delivery to the ad platform keeps working at full strength - deduplication between pixel and API absorbs the pixel's weakening copy - and the tracker's own records keep the numbers honest. MOST runs that server-side delivery for Meta, TikTok, Reddit, Pinterest, Snapchat, and OpenAI from tracker postbacks, and the free Pixel Activator covers the same delivery for a single landing.