If your business has a sales cycle longer than 24 hours (B2B, SaaS, automotive, high-ticket e-commerce), you have a recurring measurement gap: you lose visibility on returning visitors from Apple devices.
A customer clicks your Google Ad on Monday, considers the purchase for three days, returns via bookmark on Thursday, and buys a subscription.
In your analytics, that conversion shows up as a direct visit (Direct / None). Your Monday ad campaign gets zero credit, and the ad algorithm marks that ad set as unprofitable.
This attribution failure stems from browser privacy controls, specifically WebKit ITP (Intelligent Tracking Prevention).
1. How Safari ITP restricts cookies today
For over a decade, analytics scripts stored visitor IDs using JavaScript: document.cookie = "_ga=GA1.2.123456789; max-age=63072000".
Apple methodically restricted that approach:
WebKit ITP Restriction Timeline:
2017: Third-party cookies blocked by default.
2019: Client-side JS cookies (document.cookie) capped at 7 days.
2020: Client-side JS cookies capped at 24 hours when URLs contain ad click IDs (gclid, fbclid).
2023–2026: CNAME Cloaking Defense (cross-referencing IP subnets to block proxy masks).
The current rule:
If a user arrives on your site via a URL with tracking parameters (gclid, fbclid, utm_source), Safari caps the lifespan of all JavaScript-written cookies at exactly 24 hours.
After 24 hours of inactivity, the browser purges the cookie. When the user returns, GA4 sees a new visitor with a new Client ID.
2. `document.cookie` vs. HTTP `Set-Cookie`
Server-Side Tracking remains unaffected by the 24-hour cap due to how the cookie is declared.
CLIENT-SIDE COOKIE (document.cookie) SERVER-SIDE COOKIE (HTTP Set-Cookie)
┌──────────────────────────────────────┐ ┌──────────────────────────────────────┐
│ Written by JavaScript in the browser │ │ Set by the origin server │
│ sandbox on the user's machine │ │ in the HTTP response header │
├──────────────────────────────────────┤ ├──────────────────────────────────────┤
│ ❌ Safari Lifespan: 24 hours │ │ ✅ Safari Lifespan: up to 400 days │
│ ❌ Blocked by browser extensions │ │ ✅ Protected by HttpOnly/Secure flags │
│ ❌ Wiped on browser cache clear │ │ ✅ Immune to client script blockers │
└──────────────────────────────────────┘ └──────────────────────────────────────┘
Why server-set cookies persist:
HTTP response headers (Set-Cookie) are emitted directly by the web server during the network handshake. Because web applications require server cookies to maintain login sessions and cart states, browsers cannot truncate them to 24 hours without breaking standard application functionality.
3. The CNAME cloaking trap
Early server-side tracking setups tried to bypass ITP with a CNAME record: metrics.yoursite.com ➔ third-party-tracker.com.
Apple addressed this in Safari 16.4+ with CNAME Cloaking Defense:
- Safari inspects the IP addresses of both
yoursite.comandmetrics.yoursite.com. - If the A/AAAA records resolve to different hosting subnets (Class C IP mismatch), Safari flags the setup as third-party cloaking.
- It downgrades the server-set cookie to a 7-day cap.
How Sply handles this:
Sply acts as an Edge Reverse Proxy: your tracking gateway and your web routes share the same primary IP infrastructure. To Safari and Chromium, Sply is a genuine 1st-party origin.
4. Tracking data survival matrix
| User environment | Client-Side JS lifespan | Server-Side (Sply) lifespan |
|---|---|---|
| Safari from paid ads | 24 hours | 400 days |
| Safari direct traffic | 7 days | 400 days |
| Brave / Firefox (Shields active) | Blocked immediately | 100% signal delivery |
| Chrome with uBlock Origin | Blocked | 100% signal delivery |
Next steps
- Technical reference: Cheatsheet: Configuring 1st-Party HTTP Set-Cookie Headers for Safari ITP Compliance.
- Next in series: Server-side tracking (SST): architecture principles and migration guide.
Внедрите Server-Side Tracking без сложного кода
Sply восстанавливает до 30% потерянных конверсий, защищает от Safari ITP/AdBlock и ускоряет загрузку ваших лендингов.