Safari Has Been Capping Subdomain sGTM Cookies at 7 Days Since 2023

Safari caps server-set first-party cookies at 7 days when a tracking subdomain like sst.yourdomain.com resolves to an IP address unrelated to the main site, and it has done so since Safari 16.4 in March 2023. The test is narrow: if the two IPv4 addresses share fewer than 16 leading bits, the cookie gets capped. The fix is serving your tagging endpoint from a path on the main host.

PPC Land wrote this up today, working from a September 30 analysis by Mariusz Brucki at TAGGRS. The headline makes it sound new. It isn't. What's new-ish is that three and a half years later, a lot of teams that paid for server-side tagging specifically to get around Safari's cookie limits are still running the exact setup Safari was built to catch. And nobody told them, because nothing visibly broke.

That's the part I keep coming back to. A tracking setup that fails loudly gets fixed in a week. One that quietly turns returning Safari visitors into new ones every eighth day can run for years.

The sGTM pitch that Safari already priced in

Quick recap for anyone who bought server-side tagging on the strength of a sales deck. The original promise went like this: JavaScript-set cookies in Safari get capped at 7 days (24 hours in some link-decoration cases), but cookies set by your own server via a Set-Cookie header are "real" first-party cookies and can live for a year or more. So you spin up a tagging server on a subdomain, point a DNS record at it, and Safari treats your _ga or FPID cookie like it belongs to you.

Apple saw that coming. Simo Ahava flagged the feature while it was still being tested in Safari Technology Preview 157, noting that it would reduce how effective server-side GTM is at creating durable first-party cookies. Stape's write-up describes the logic: if the server setting the cookie sits on a different IP than the website, Safari treats that cookie as third-party in spirit, whatever the domain says.

The rules, per TAGGRS, are mechanical. WebKit considers the two addresses unrelated when:

• one is IPv4 and the other is IPv6,
• two IPv4 addresses share fewer than 16 leading bits (so basically, the first two octets differ), or
• two IPv6 addresses share fewer than 64 leading bits.

The classic trigger is your site behind Cloudflare while your tagging server lives on Google Cloud Run, App Engine, or a vendor's own infrastructure. Different networks, different leading bits, 7-day cookie. Your expensive "first-party" setup ends up with about the same Safari cookie lifetime as the free JavaScript tag you replaced.

On paper, sGTM still does other useful things (data control, enrichment, fewer client-side scripts). Sure. But if durable Safari identity was the line item that justified the budget, it's worth checking whether you ever actually got it.

Who this probably does not affect

Before anyone panics: Elevar's documentation puts it plainly. Unless you've been using a server to extend cookie expiration, Safari 16.4 doesn't change much for you. The cap is targeted. Ordinary cookies set by your own origin are not affected, and TAGGRS is careful to say this is not a 7-day limit on every server-set first-party cookie.

There's also a quirk worth knowing. According to Addingwell's explainer, the IP check doesn't apply to users with Safari's "Hide IP Address" option enabled, which they say is on by default for iCloud+ subscribers. So the damage is uneven across your Safari audience, which honestly makes it even harder to spot in aggregate reports.

The people who should care:

• Anyone running sGTM, Stape, or a similar tagging server on a subdomain that resolves to a different network than the main site.
• Paid teams whose bidding depends on clean conversion linkage from Safari users. Weaker identity flows straight into Smart Bidding and Meta's optimization.
• Brands with consideration cycles longer than a week. If your typical customer buys 10 days after first visit, every Safari buyer in that window gets split into two people.

The 10-minute check (it's less painful than it sounds)

You can confirm whether you're affected without a vendor call. Roughly:

1. Compare the IPs. Run nslookup or dig on both yourdomain.com and your tagging subdomain. If the first two octets of the IPv4 addresses differ, or one host returns only IPv6 while the other returns IPv4, you're in cap territory.
2. Look at the cookie in Safari directly. Open your site in desktop Safari with Hide IP Address off, open Web Inspector, go to Storage, then Cookies, and check the expiry on _ga, FPID, or whatever your server sets. If it says about a week out when your server is configured for a year or more, that settles it.
3. Sanity-check in GA4. Pull new vs returning users split by browser for the last 90 days. If Safari's returning-user share runs well below Chrome's on the same device category, that's consistent with cookies expiring early (it's not proof, Safari users can just behave differently, but it's a decent smell test).

My rough benchmark: if Safari's returning-user share is more than 10 points under Chrome's on mobile and your purchase cycle is longer than 7 days, I'd assume the cap is hitting you until proven otherwise. That number is a heuristic, not a law. Adjust for your audience.

If you already did a GA4 cleanup recently, this belongs on the same list as the settings in our guide to the GA4 settings worth fixing before you trust any report.

Same-origin is the fix, with some fine print

The fix everyone points to is the same: stop serving tracking from a subdomain and serve it from a path on the main host, like yourdomain.com/metrics, using a reverse proxy, a Cloudflare Worker, or a load balancer rule. Stape calls this the same-origin domain approach in its domain setup guide, and says both Stape and Google recommend it. Google's own version of this idea, tag gateway, hit general availability on Google Cloud in June.

The fine print matters, though:

• The proxy has to pass Set-Cookie headers through intact, with Domain, Path, Secure, HttpOnly, and SameSite preserved. A sloppy proxy config can quietly break the thing you were trying to fix.
• It won't lengthen attribution windows or remarketing windows. Those are set by the ad platforms, not your cookie.
• It doesn't override consent or private browsing. Users who decline still decline.
• It doesn't beat every ad blocker. Obvious paths like /analytics or /gtm get pattern-matched too, so pick something boring.

And to be fair about incentives: TAGGRS sells a same-origin product, Stape sells one, Addingwell sells one. PPC Land points this out about TAGGRS, which I appreciated. The underlying WebKit behavior is real and documented across years of independent coverage (Louder wrote about it in July 2023), so I don't think the vendor angle undermines the diagnosis. It just means you should price the fix against doing it yourself in Cloudflare, which for a lot of teams is maybe a day of engineering.

Apple is still tightening, not loosening

The bigger reason I wouldn't sit on this: the direction of travel. Safari 27 has been blocking ad tech by IP and hostname, and we've covered how iOS 27 quietly cut The Trade Desk off Safari and how Apple maintains a private blocklist for ad tech. WebKit itself calls the IP comparison a heuristic that may change in future releases. Heuristics tend to get stricter. I can't remember one that got more permissive.

Here's a prediction with some stakes: within the next 12 months I think a meaningful chunk of subdomain-based sGTM setups, something like a third of the ones currently running, will migrate to same-origin paths, mostly because Google keeps pushing tag gateway as the default. The teams that move early get cleaner Safari data going into Q1 planning. Everyone else gets another year of Safari users who look suspiciously new.

Think of it like a gym membership card that expires every week but still scans at the door. Attendance looks great. Retention looks terrible. Nobody notices the card is the problem.

One honest caveat before you file the ticket

Anyway, I don't want to overstate this. For brands where most purchases happen inside a single session, or within a few days of first touch, a 7-day cookie barely matters, and the migration might not be worth the engineering time this quarter. The cap mostly hurts longer consideration cycles, returning-visitor reporting, and audience building.

But if you bought server-side tagging in 2022 or 2023 because someone promised you year-long Safari cookies, it's probably worth the ten minutes to check whether you ever got them. I'd guess a fair number of teams will open Web Inspector, see an expiry date next Thursday, and quietly add a line to the sprint.