Safari and Firefox quietly cap your analytics cookies to a few days, which silently turns returning visitors into new ones and wrecks retention and attribution. Server-side GTM is the cleanest way to give those cookies a real lifespan again. Here is how to extend first-party cookie lifetime.

Why your cookies die early

Browser tracking prevention, chiefly Safari's ITP, limits the lifetime of cookies set by client-side JavaScript, often to seven days or even one. When the GA4 cookie expires that fast, a visitor who returns after a week looks brand new, so your returning-user counts, retention curves, and attribution windows all understate reality. The cookie, not the user, is the problem.

How server-side fixes it

The limits that bite hardest apply to cookies written by JavaScript in the browser. A cookie set by your server, in an HTTP response from your own domain, is treated as more trustworthy and can be given a much longer lifetime. Because server-side GTM responds to the browser from your own subdomain, it can set the GA4 identifier as a long-lived, server-set first-party cookie instead of a short-lived script one.

Set the cookie from the server

The mechanism is an HTTP Set-Cookie header from your tagging server, carrying a long max-age and the right flags:

// Conceptual: the tagging server sets a durable first-party cookie
// Set-Cookie: FPID=<id>; Max-Age=63072000; Path=/;
//   Domain=.yourdomain.com; Secure; HttpOnly; SameSite=Lax
// Max-Age 63072000 = 2 years, vs ITP's ~7 days for JS cookies

The GA4 client in the server container handles much of this for you once configured, so in practice you enable server-managed cookies rather than writing the header by hand, but knowing what it emits is what lets you verify it worked.

Mind the flags

The cookie's attributes decide whether it survives and stays safe:

  • A long Max-Age is the whole point, so set it to the lifetime you actually want.
  • HttpOnly stops client-side scripts and some tracking prevention from touching it.
  • Secure and an appropriate SameSite keep it safe and working across your pages.
  • The Domain should cover your subdomains if you track across them.

This is not a loophole

Extending cookie life is about measurement accuracy, not evading consent, and the two must not be confused. A durable cookie still only belongs on users who consented to it, so keep it gated behind your consent logic. Done right, this restores honest returning-user and retention data for the people who agreed to be measured, which is exactly what the browsers intended to allow.

Verify the lifetime

Check your work in the browser's application tab, where you can see the cookie, who set it, and its expiry. Confirm the GA4 identifier now shows a long expiration and is marked as server-set rather than script-set. Then watch returning-user and retention numbers over the following weeks, since the payoff shows up as those curves stop collapsing.

Know what it does not fix

A longer cookie solves the expiry problem, not identity itself. It is still a device-and-browser cookie, so the same person on a phone and a laptop remains two identities, and clearing cookies still mints a new one. For true cross-device stitching you need a logged-in user_id, not a longer cookie. Keep the two problems separate in your head: cookie lifetime fixes premature expiry, while cross-device identity is a different project with a different tool.

Safari and Firefox were quietly aging your cookies to death and turning loyal visitors into strangers, and a server-set cookie is what gives them a real life again. Let the server issue a long-lived, properly flagged first-party cookie, keep it behind consent, and verify the expiry in the browser. Do that and retention and attribution stop lying to you, because returning users finally look like the returning users they are.

Want a stronger data analyst role or a raise? Grab the FREE Product Analyst Playbook and get the exact roadmap to your next offer.