Your First-Party Cookies Still Die in 7 Days and Only a True Server Survives
Safari ITP caps first-party cookies set via JavaScript to 7 days maximum, dropping to 24 hours when tracking parameters like gclid are present. Since Safari 16.4, even server-set cookies are capped when Safari detects CNAME or IP mismatch with the primary domain. Only cookies set via HTTP Set-Cookie headers from a genuine same-domain server persist for their full TTL of up to 400 days. Most basic sGTM implementations still fail this test, while WordPress-native solutions bypass ITP entirely because cookies originate from the store’s own server.
The 7-Day Ceiling You Probably Think You’ve Solved
Most WooCommerce store owners who moved to server-side tracking believe they’ve fixed their Safari attribution problem. Most haven’t.
Safari’s ITP caps any first-party cookie written via JavaScript’s document.cookie to a maximum 7-day lifetime. It doesn’t matter what Max-Age or Expires value your script requests. If the cookie was set by JavaScript running in the browser, Safari enforces a hard 7-day ceiling and then silently deletes it.
This isn’t new. ITP 2.1 introduced the 7-day cap back in 2019. What’s changed is the sophistication of Safari’s detection. Safari 26 introduced Advanced Fingerprinting Protection as a default-on feature. iOS 26 expanded Link Tracking Protection across Safari, Messages, and Mail. And Safari now reaches over 1 billion users worldwide with approximately 18% of global browser market share.
For WooCommerce stores, the 7-day cap means any customer who clicks an ad, browses your products, and returns 8 days later to purchase is a brand new visitor in your analytics. The attribution cookie linking their purchase to the original ad click no longer exists. That conversion registers as direct traffic, and your ad platform never learns that the campaign worked.
Safari ITP caps any first-party cookie written via JavaScript document.cookie to a maximum 7-day lifetime regardless of the Max-Age value the script requests according to WebKit’s tracking prevention specification.
The data shows the scale of distortion. Safari segments in GA4 routinely report new user rates of 70-80% while the equivalent Chrome rate sits at 35-45%. That’s not a genuine difference in customer acquisition. That’s ITP deleting cookies every 7 days and forcing analytics to treat returning customers as perpetual first-time visitors.
You may be interested in: Tech-Savvy Audiences Block GA4 at 58% — Why Your Best Customers Are Invisible
Three Tiers of Cookie Death on Safari
Safari doesn’t apply a single cookie rule. It runs three different caps depending on how the cookie was set and what was in the URL.
Understanding which cookies survive on Safari requires understanding that ITP applies three distinct tiers of restriction, each targeting a different cookie-setting mechanism.
| Cookie Type | How Set | Safari ITP Cap | Full TTL Possible |
|---|---|---|---|
| JavaScript cookie | document.cookie in browser | 7 days maximum | No |
| JS cookie with tracking params | document.cookie + gclid/fbclid | 24 hours maximum | No |
| Server cookie (CNAME/proxy) | Set-Cookie from CNAME subdomain | 7 days (since Safari 16.4) | No |
| Server cookie (genuine first-party) | Set-Cookie from same-domain server | No ITP cap | Yes (up to 400 days) |
Tier 1: JavaScript cookies — 7 days. Any cookie set via document.cookie gets the hard 7-day cap. This includes GA4’s _ga cookie, Facebook’s _fbp cookie, and virtually every client-side tracking identifier.
Tier 2: Link-decorated JavaScript cookies — 24 hours. When a user arrives via a URL containing known tracking parameters like gclid (Google Ads), fbclid (Facebook), or dclid (Display and Video 360), Safari’s link-decoration heuristic shortens the cookie cap from 7 days to just 24 hours. This means any WooCommerce customer who clicks a paid ad and waits more than one day before purchasing will have their attribution cookie expired before the sale completes.
Tier 3: CNAME-cloaked server cookies — 7 days. This is the tier that catches most “server-side” implementations off guard. Since Safari 16.4, released in April 2023, server-set cookies are also capped to 7 days when Safari detects the setting server is disconnected from the primary domain. Safari checks whether the CNAME resolves to an IP associated with a known tracking service, and if it does, the 7-day cap applies even though the cookie came via a proper Set-Cookie HTTP header.
When a known tracking parameter such as gclid or fbclid is present in the landing URL, Safari’s link-decoration heuristic drops the cookie cap further to just 24 hours.
Tier 4: Genuine first-party server cookies — no cap. Cookies set via Set-Cookie headers from a server that Safari considers genuinely same-domain bypass ITP entirely. These cookies can persist for their full configured lifetime of up to 400 days. This is the only tier where attribution data survives intact.
Why Basic sGTM Still Fails the ITP Test
Setting up a server-side GTM container on a subdomain doesn’t automatically make your cookies ITP-proof — Safari looks deeper than the domain name.
The standard sGTM setup involves provisioning a Google Cloud instance, pointing a CNAME subdomain (like analytics.yourstore.com) to it, and routing tags through that server container. On the surface, this looks like a first-party server. The cookie comes from your subdomain. The Set-Cookie header comes from an HTTP response. It should bypass ITP.
It doesn’t. Safari 16.4’s CNAME cloaking detection examines whether the CNAME target resolves to an IP address range associated with known tracking infrastructure. If your sGTM container runs on Google Cloud’s standard IP ranges, Safari recognises the pattern and applies the 7-day cap to cookies set by that subdomain.
This is the nuance that most server-side tracking guides miss entirely. They describe the transition from client-side to server-side as if the binary distinction is what matters. In reality, Safari’s ITP doesn’t care whether the tag fires on the client or the server. It cares whether the server that set the cookie is genuinely part of your infrastructure or a tracking service masquerading as first-party through DNS tricks.
In key markets like Germany, France, and US tech audiences, the combination of ad blockers and Safari ITP blocks client-side tags from firing on more than 40% of sessions. A basic sGTM setup recovers the ad-blocker portion of that loss — because the server-side request bypasses the browser — but still loses the ITP attribution portion if the cookies fall into Tier 3.
You may be interested in: In-App Browsers Strip Your Tracking Parameters Before the Page Even Loads
What Genuine First-Party Actually Means to Safari
Safari’s definition of “first-party” goes beyond the domain name on the cookie — it examines the entire DNS resolution chain and IP association.
For a cookie to survive ITP without any cap, Safari needs to see that the server setting the cookie meets specific criteria. The cookie must be delivered via a Set-Cookie HTTP response header, not via JavaScript. The server’s domain must resolve to an IP address that Safari associates with the same entity as the primary website domain. And the CNAME chain must not terminate at a known tracking infrastructure provider.
In practical terms, this means the cookie must come from the same server (or at minimum the same hosting infrastructure) that serves your actual website. If your WooCommerce store runs on a VPS at 123.45.67.89 and the cookie comes from a Set-Cookie header from that same server, Safari treats it as genuinely first-party. Full TTL. No cap.
The distinction matters enormously for attribution. Shifting from JavaScript-set cookies to genuine HTTP-header server cookies typically restores up to 20% of previously disassociated cross-channel attribution paths. That’s not a marginal improvement. That’s one in five conversion paths that were previously invisible becoming visible in your analytics and ad platform optimisation loops.
Only cookies set via a Set-Cookie HTTP response header from a genuine same-domain first-party server bypass ITP caps entirely and can persist for their full configured TTL of up to 400 days.
The WordPress-Native Advantage
WordPress-native tracking doesn’t need to prove it’s first-party to Safari — it IS first-party by architecture.
WordPress-native server-side tracking has an inherent structural advantage over external sGTM containers: the tracking code runs on the same server that hosts the WooCommerce store. There’s no CNAME to cloak. No external IP range for Safari to flag. No DNS chain that terminates at a known tracking provider.
When a WooCommerce customer completes a purchase, the WordPress server processes the order and simultaneously fires conversion events to Google Ads, Meta CAPI, GA4, TikTok, and BigQuery. If the solution also sets a first-party cookie via the server’s Set-Cookie header, that cookie comes from the same Apache or Nginx process that served the product page. Safari has no basis to apply ITP restrictions because the cookie genuinely originates from the site’s own infrastructure.
Transmute Engine™ takes this approach for WooCommerce. It captures events at the server level during the actual transaction and routes them to advertising and analytics platforms. Because it runs as a WordPress plugin on the store’s own server, any cookies it sets are architecturally first-party in the way Safari requires.
The difference isn’t theoretical. Stores running genuine first-party server cookies see Safari attribution data that matches Chrome’s patterns — consistent returning visitor rates, accurate campaign attribution across multi-day purchase cycles, and conversion counts that align with actual WooCommerce order records.
95% of US iOS users already opt out of app tracking when given the choice. Safari’s ITP restrictions are tightening with every release. The question isn’t whether browser-side tracking will keep degrading — it’s whether your tracking architecture is built to survive the degradation or be consumed by it.
Key Takeaways
- Three caps, not one: Safari applies 7-day limits to JavaScript cookies, 24-hour limits when tracking parameters are present, and 7-day limits to CNAME-cloaked server cookies. Only genuine first-party server cookies bypass all ITP caps.
- Basic sGTM still fails: Server-side GTM on a CNAME subdomain gets its cookies capped to 7 days when Safari detects the CNAME resolves to known tracking infrastructure IP ranges.
- Genuine first-party means same server: Safari defines first-party by examining the DNS resolution chain and IP association, not just the domain name on the cookie.
- 20% attribution recovery: Switching from JavaScript cookies to genuine server-set cookies typically restores up to 20% of previously lost cross-channel attribution paths.
- WordPress-native is architecturally first-party: Tracking that runs on the same server hosting the WooCommerce store is genuinely first-party by construction, requiring no CNAME tricks or external infrastructure.
Safari’s ITP caps cookies based on how and from where they are set, not just whether they are first-party. If your server-side GTM container runs on a CNAME subdomain or an IP address that Safari identifies as disconnected from your primary domain, those cookies are still capped to 7 days. Only cookies set via HTTP Set-Cookie headers from a server that Safari considers genuinely same-domain bypass the cap entirely.
A JavaScript cookie is written via document.cookie in the browser and is capped by ITP to 7 days or 24 hours with tracking parameters. A server-set cookie is delivered via the Set-Cookie HTTP response header from the web server itself. When the server shares the same domain and IP range as the website, Safari treats these cookies as genuinely first-party and allows their full configured lifetime of up to 400 days.
Not automatically. A basic sGTM setup running on a subdomain proxied through a CNAME record will still have its cookies capped to 7 days by Safari’s CNAME cloaking detection. WordPress-native server-side solutions avoid this entirely because the cookie comes from the same server that serves the website.
When a user clicks a link containing known tracking parameters like gclid from Google Ads or fbclid from Facebook, Safari recognises the URL decoration and shortens the cookie lifetime from 7 days to 24 hours. This means any WooCommerce customer who clicks a paid ad on Safari and waits more than 24 hours before purchasing will have their attribution cookie expired, making the conversion appear as direct traffic in analytics.
WordPress-native server-side tracking fires events and sets cookies from the same Apache or Nginx server that hosts the WooCommerce store. Because the cookie originates from the genuine first-party server with matching domain and IP, Safari has no basis to apply ITP restrictions. The result is attribution data that survives the full cookie lifetime regardless of which browser the visitor uses.
References
WebKit. “Intelligent Tracking Prevention.” webkit.org/blog/category/privacy. 2026. Adobe Experience League. “Apple Intelligent Tracking Prevention (ITP) 2.x.” experienceleague.adobe.com. 2026. Snowplow. “Tracking Cookies Length: What You Need to Know.” snowplow.io. 2026. LinkUTM. “How Safari Blocks Google Analytics (And What Actually Works).” linkutm.com. May 2026. Z2A Digital. “A Timeline of Apple’s Privacy Changes in Safari and iOS.” z2adigital.com. May 2026. TAGGRS. “Safari 26 Tracking Changes Explained.” taggrs.io. January 2026. McGaw. “Apple ITP Explained: How It Changed Marketing Analytics (2026).” mcgaw.io. 2026.If your Safari attribution data looks nothing like your Chrome data, talk to us about WordPress-native server-side tracking that sets genuine first-party cookies from your own server.