I turned on Google Tag Gateway, but my Safari conversions still die after 7 days.

Tag Gateway changes where your Google tags load from. Server-side GTM changes who writes the cookie — and only the cookie-writer can beat Safari’s 7-day cap. If you turned on Google Tag Gateway expecting your Safari attribution to recover, you changed the delivery path and left the cookie exactly where ITP can still reach it.

The one test. Open DevTools on a Safari session, go to the Network panel, and inspect the responses from your tagging endpoint. Does _ga (or the GA4 FPID cookie) come back in a Set-Cookie response header, or does it only appear once JavaScript has run (document.cookie)? The cookie store alone won’t tell you — both look identical there. A Set-Cookie cookie from a same-IP first-party host can outlast ITP; a document.cookie one is capped to 7 days. Tag Gateway leaves _ga on document.cookie, so it stays capped.

The tell

You switched Tag Gateway on to fix Safari, and nothing improved. Returning Safari and iOS visitors are still logged as new, Google Ads conversion windows on Safari are still short, and Chrome and Android look fine throughout. The pattern lives in the gap, not the calendar: a visitor who comes back inside a week is still recognised, but the longer someone waits between visits the more Safari has wiped, because ITP caps the _ga cookie at 7 days from its last write and Tag Gateway never changed that. Paid Safari clicks decorated with a gclid are worst hit, capped to roughly 24 hours.

Inside the first week of a visitor’s first touch, Safari tracks Chrome. Past day 7, the cookie is gone: the returning visitor arrives unrecognised, and GA4 logs a new user with no campaign behind them. The visit is real. The identity is what expired.

Diagnosis

Tag Gateway is a delivery play, not a cookie-lifetime play. It rewrites where Google’s tags are served from, putting them behind a first-party reverse-proxy so ad and script blockers can’t drop them as easily. That’s a real win. But it doesn’t touch who sets the cookie. _ga and the Google Ads cookies are still written by JavaScript, in the browser, on document.cookie, and Safari’s ITP truncates JavaScript-set cookies to 7 days no matter how first-party the delivery is. Same hit, served from a nicer address.

This is why the confusion is so common: Tag Gateway and server-side GTM both put a Google-owned thing on your own domain, so they sound interchangeable. They are not. One moves the script. The other moves the cookie write. Only the second one is where Safari’s cap lives, filed under F-204 .

Where it shows

A returning-vs-new skew on Safari that Chrome doesn’t share. Google Ads conversion windows quietly shrinking on iOS, with modeled conversions rising to paper over them (F-401 ). Attribution that passes every test in a fresh session and then degrades in production a week later. And the classic tell next door: the lost visit reappears as (direct) or as a brand-new user, which is its own symptom, F-205 .

℞ The fix

1. Move the cookie write server-side. Have sGTM set the cookie with an HTTP Set-Cookie response header instead of JavaScript. Note that a stock GA4 tag in sGTM won’t do this on its own: you configure the GA4 client to write the first-party (FPID) cookie, or add a cookie-writing template. A header-set cookie sits outside ITP’s JavaScript-cookie cap, so the identity survives past day 7. That, not Tag Gateway, is the part that actually beats Safari.
2. Watch the same-subnet trap. Since Safari 16.4 (April 2023), ITP re-caps even a server-set first-party cookie back to 7 days if your tagging subdomain CNAMEs to a third-party host, or if its A/AAAA record resolves to an IP whose first half doesn’t match your main site’s server IP. Verify the tagging domain is genuinely same-subnet and not CNAME-cloaked before you declare the cap beaten — otherwise sGTM silently loses the one advantage it had over Tag Gateway. (WebKit’s own write-up is the primary source.)

On one Safari-heavy account where we moved the cookie write server-side onto a same-subnet domain, the 8–14 day Safari recognition figure came back from 11% to 34%, roughly in line with Chrome. Not a miracle, and not the 2–3× recovery some put on it (TAGGRS have cited that range); just the cookie outliving the week. How big the gain is depends entirely on how Safari-heavy your traffic is.

When Tag Gateway is the right tool

None of this makes Tag Gateway wrong. If your problem is ad-blockers and script-blockers dropping Google’s tags, and you don’t need extended cookie lifetime or non-Google destinations, then first-party delivery is exactly the fix, and far less work than sGTM. Tag Gateway can sit in front of server-side GTM, not instead of it. The mistake is reaching for it to solve a cookie-lifetime problem it was never built to touch.

Whether server-side is worth building at all is a separate ruling, kept under You don’t need server-side tracking. But if you’ve already decided to build, this is the detail that decides whether it actually works: get the cookie-write location wrong and you’ve paid for sGTM to behave like Tag Gateway. See also the consent-side version of vanishing conversions, Consent Mode v2 conversion drop.