Why your GA cookies reset every 7 days for Safari users

The problem

Google Analytics recognizes returning visitors with the _ga cookie. When that cookie disappears, the next visit starts a brand-new user: new user count up, returning-user count down, attribution gone.

In Safari, this happens on a schedule. Safari’s Intelligent Tracking Prevention (ITP) caps the lifetime of any cookie set by JavaScript at 7 days, and at 24 hours when the visitor arrives from a URL with tracking parameters such as gclid or fbclid. The standard GA4 snippet sets its cookies with JavaScript, so every Safari visitor who stays away for more than a week comes back as a stranger.

This is not a niche problem. Safari is roughly a quarter of web traffic in most European markets, and more on mobile. In practice it means:

• Inflated “new users” and deflated returning-user metrics.
• Conversion journeys longer than 7 days lose their original attribution: the ad click that started the journey gets no credit.
• Remarketing audiences built on GA4 data leak Safari users continuously.

Firefox applies similar restrictions (Total Cookie Protection), and other browsers are moving the same way. Safari is simply where the 7-day cap bites hardest today.

Why the cap only hits JavaScript cookies

ITP distinguishes how a cookie is set:

• Set by JavaScript (document.cookie, which gtag.js uses): capped at 7 days / 24 hours.
• Set by an HTTP response header (Set-Cookie) from a first-party server: not capped by lifetime rules; the cookie keeps the expiry the server gives it, typically 365+ days or more depending on browser policy.

That asymmetry is the entire fix: get the cookie set by an HTTP response from your own domain instead of by JavaScript in the browser.

The fix: set analytics cookies server-side

With a server-side Google Tag Manager (sGTM) container running on your own subdomain (for example sgtm.yourshop.com), the GA4 client can set an FPID cookie via an HTTP header. Because it is a first-party, HTTP-set cookie, it survives ITP with its full lifetime, and GA4 uses it as the user identifier instead of the JavaScript _ga cookie.

On WordPress, GTM Kit supports server-side tagging end to end: point the container loader at your sGTM domain and route GA4 traffic through it. See Server-side tracking with sGTM for the setup guide.

How to check whether you are affected

1. Run a Tracking Health Check on your site. The cookie table shows each tracking cookie’s lifetime and whether it was set by JavaScript or by an HTTP header.
2. Or check manually: in Safari’s Web Inspector (Storage → Cookies), look at the expiry of _ga after loading your site. If it is 7 days out rather than ~13 months, ITP has capped it.
3. If an FPID cookie is present alongside _ga_*, a server container is already setting your identifier HTTP-side.

Related

• Server-side tracking with sGTM
• GTM Kit Premium: server-side purchase webhooks that don’t depend on browser cookies at all