{"id":1314,"date":"2026-08-19T00:52:30","date_gmt":"2026-08-18T22:52:30","guid":{"rendered":"https:\/\/www.sabatka.net\/cs\/?p=1314"},"modified":"2026-09-05T07:27:25","modified_gmt":"2026-09-05T05:27:25","slug":"cookie-lifetime","status":"publish","type":"post","link":"https:\/\/www.sabatka.net\/en\/cookie-lifetime\/","title":{"rendered":"Cookie Lifetime: Why GA4 Shows More Users Than You Actually Have"},"content":{"rendered":"\n

Everyone has heard of cookies \u2014 we click through the consent banner on every website. Few people can actually explain what a cookie is, let alone the difference between a first-party and a third-party cookie. Yet this exact mechanic is what attribution, remarketing, and GA4’s ability to recognize a returning customer all depend on. And in some browsers, cookie lifetime is far shorter than most marketers assume.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n
Contact me<\/a><\/div>\n\n\n\n
Share on LinkedIN<\/a><\/div>\n<\/div>\n\n\n\n
<\/div>\n\n\n\n

How many visitors does this actually affect? Across the projects I manage, I track browser share in traffic over time.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Across the (mostly Czech) sites I manage, the median Safari share is around 16 percent \u2014 roughly every sixth visitor. On some sites (with an Apple-leaning audience), it climbs to 24 percent, close to one in four. Firefox accounts for about 4 percent.
Why track Safari and Firefox specifically? Because these two browsers are the toughest on cookies \u2014 I’ll get into exactly how in a moment.<\/p>\n\n\n\n

One scope note upfront: this article focuses specifically on cookie lifetime. I know visitor identity also fragments for other reasons \u2014 typically access from multiple devices or multiple browsers. I’m deliberately leaving those aside to keep the topic manageable. So assume the real fragmentation in your data is somewhat worse than what I describe below.<\/p>\n\n\n\n

<\/div>\n\n\n\n

How Cookies and Storage Actually Work<\/h2>\n\n\n\n

Before we get into why cookies disappear, a quick primer: who actually sets them, and who they belong to.<\/p>\n\n\n\n

A cookie can be set by the JavaScript in your tracking code, or by an HTTP header in the server’s response. And it can belong to the domain the visitor sees in the address bar (first-party), or to a completely different domain (third-party). A concrete example: you’re browsing shop.com<\/a> \u2014 a cookie belonging to shop.com<\/a> is first-party. If the same page also sets a cookie via the Facebook pixel’s HTTP header, that cookie belongs to facebook.com<\/a> \u2014 and that’s third-party.<\/p>\n\n\n\n

The combination of these two axes determines how vulnerable a cookie is to browser intervention:<\/p>\n\n\n\n

<\/th>First-party (your domain)<\/th>Third-party (someone else’s domain)<\/th><\/tr><\/thead>
JS-set<\/strong> (set by JavaScript)<\/td>The _ga<\/code> cookie, where GA4 stores the visitor identifier \u2014 the most common case on the web<\/td>Classic third-party ad pixels \u2014 blocked in Safari and Brave; Firefox isolates them into a separate “cookie jar” per site (partitioning \u2014 the effect on cross-site tracking is the same); still work in Chrome<\/td><\/tr>
HTTP-set<\/strong> (set by the server)<\/td>A cookie from server-side tracking, set by the server via the Set-Cookie<\/code> header \u2014 typically with the HttpOnly<\/code> attribute, so JavaScript can’t access it at all<\/td>Third-party trackers via HTTP header \u2014 practically non-functional today<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Google Analytics’ tracking cookie is a JS-set first-party cookie \u2014 JavaScript sets it. That’s exactly why most of what follows in this article applies to it.<\/p>\n\n\n\n

If you already know this mechanic, feel free to skip ahead \u2014 it won’t affect the rest of the article. Let’s get into why cookies vanish sooner than their coded expiration date, no matter what you set.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Cookie Lifetime in Safari, Firefox, and Chrome<\/h2>\n\n\n\n

The cookie expiration date you set in code is only a ceiling. How long a cookie actually survives is decided by each browser on its own terms \u2014 and the differences are significant.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Safari: JS Cookies Survive a Maximum of 7 Days<\/h3>\n\n\n\n

Safari’s ITP (Intelligent Tracking Prevention<\/a>) has a hard limit: it purges JS-set cookies after 7 days. No debate, full stop. And when a visitor arrives via a link carrying a known tracker’s parameters in the URL \u2014 typically a click from an ad with gclid<\/code> or fbclid<\/code> in the address (a technique called link decoration) \u2014 the limit gets even tighter: 24 hours.<\/p>\n\n\n\n

On top of that, since version 14 (2020) Safari inspects DNS records to detect CNAME cloaking (when a cookie hides behind your own subdomain, typically in server-side tracking setups), and since version 16.4 (2023) it also compares IP addresses: if the server setting the cookie in the HTTP response doesn’t match even the first half of the main domain’s IP address (this rule only kicks in without CNAME detection, i.e. with an empty CNAME chain), the cookie gets hit with the same 7-day limit.<\/p>\n\n\n\n

Apple turned on Advanced Fingerprinting Protection<\/a> by default for all browsing in Safari 26 (September 2025). Fingerprinting is a technique for identifying a visitor without cookies at all: a script reads a combination of browser and device properties \u2014 screen resolution, fonts, how graphics get rendered \u2014 and assembles them into a practically unique “fingerprint.” Safari now restricts known fingerprinting scripts (typically off-the-shelf libraries websites deploy for this purpose) from accessing that data, and it also won’t let them store a long-lived cookie or localStorage entry \u2014 so there’s nowhere to persist the fingerprint. In private browsing, it additionally strips tracking parameters from URLs. This is documented behavior from WebKit’s own blog; the precise impact on specific measurement tools isn’t clear yet.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Firefox: Doesn’t Delete Cookies, Isolates Them<\/h3>\n\n\n\n

Firefox takes a different approach \u2014 as part of Enhanced Tracking Protection<\/a>, it uses a mechanism called Total Cookie Protection. It doesn’t block third-party cookies; instead, it isolates each site into its own “cookie jar” (partitioning) \u2014 which amounts to the same outcome for cross-site tracking. But it leaves first-party tracking cookies alone; there’s no 7-day limit here like in Safari.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Chrome: You Can Set Cookies for Up to 400 Days<\/h3>\n\n\n\n

Chrome behaves differently than you’d expect if you’ve heard that “cookies are dying.” You can set a cookie to expire up to 400 days<\/a> out, and despite years of announcements, Chrome still doesn’t block third-party cookies \u2014 Google officially killed Privacy Sandbox, the project meant to change that, in October 2025, and there’s currently no timeline for third-party cookies going away in Chrome. So the phrase “cookies are dying” applies in full force mainly to Safari and Brave.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Brave: The Strictest of All<\/h3>\n\n\n\n

Brave typically makes up a small share of traffic \u2014 and in GA4 you usually won’t even see it listed separately, since it identifies itself as Chrome. But when it comes to cookies, it’s the strictest of the bunch: it caps JS-set cookies at 7 days just like Safari, limits HTTP-header cookies to 6 months, and blocks third-party storage entirely \u2014 a third-party site gets only temporary ephemeral storage<\/a> that disappears the moment the visitor leaves.<\/p>\n\n\n\n

<\/div>\n\n\n\n

People Delete Cookies Too<\/h3>\n\n\n\n

On top of browser behavior, add device switching and manual cookie deletion \u2014 according to older studies, a third of users deleted cookies at least once a month (comScore 2007<\/a>), and nearly two-thirds of tracking cookies ended up blocked or deleted (Flashtalking 2018<\/a>). I haven’t found more recent research.<\/p>\n\n\n\n

Treat those numbers as an illustration of the trend, not a current fact.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Your Own Consent Banner Can Delete Cookies Too<\/h3>\n\n\n\n

One more thing worth noting: your own consent banner can delete cookies too, if that’s enabled in its settings \u2014 before you start hunting for a browser bug, it’s worth checking so you don’t blame Safari for something you’re doing to yourself (consent banner misconfigurations can skew your data in other ways too<\/a>).<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n
\n
\"V\u011bd\u011bli<\/figure>\n<\/div>\n\n\n\n
\n

Lab note<\/strong><\/strong><\/h3>\n\n\n\n

It’s like the half-life<\/a> of a radioactive sample \u2014 a cookie’s lifetime isn’t set by the date you code into it, but by whatever the browser allows. Your audience decays the same way, day by day. In Safari, though, it’s decay with an ultimatum: whoever doesn’t return within 7 days doesn’t decay partially \u2014 they decay completely.<\/p>\n<\/div>\n<\/div>\n\n\n\n

<\/div>\n\n\n\n

The Real-World Impact of Cookie Lifetime<\/h2>\n\n\n\n

The result: the actual cookie lifetime is dictated by whichever rule is strictest for that particular visitor. On sites with a higher share of Safari or Firefox traffic, that lifetime shrinks significantly.<\/p>\n\n\n\n

And watch out for localStorage: it won’t save you in Safari \u2014 ITP wipes any script-writable storage (including localStorage) after 7 days of browser use without interacting with the site. Chrome and Firefox don’t clean it out this way, but you’re dealing with this problem because of Safari in the first place \u2014 so don’t expect more persistence from it.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Numbers From Practice<\/h2>\n\n\n\n

How much does one real person actually multiply in your data? A few years ago, I analyzed traffic on an intranet where I knew the user ID behind every single visit \u2014 and where people logged in repeatedly from the same devices. You couldn’t ask for better conditions for cookies to survive. Even there, the number came out at roughly 2.1 GA4 users per one real person<\/strong> (one real person = one unique user ID).<\/p>\n\n\n\n

For public websites \u2014 without logins, with a higher share of Safari and mobile traffic \u2014 I’d expect a noticeably higher number, easily three or more GA4 users per real visitor. I haven’t measured that one; it’s an estimate based on the mechanisms described above.<\/p>\n\n\n\n

That’s why GA4 shows more users than you actually have: nobody vanished from your data. Everyone’s just being counted more than once.<\/p>\n\n\n\n

<\/div>\n\n\n\n

The Impact on Measurement and Marketing<\/h2>\n\n\n\n

All of this stays academic until you run it against your own purchase cycle. What actually happens when a cookie dies before the customer’s path to purchase is complete?<\/p>\n\n\n\n

Multi-visit attribution breaks.<\/strong> GA4 links visits from the same visitor via the _ga<\/code> cookie (client_id). If the cookie dies between a visit from a campaign and the visit where the conversion happens, GA4 won’t connect the two. The conversion gets attributed to the last source \u2014 often direct \u2014 and the customer looks brand new in your data, even though they’ve known your brand for weeks. (Direct traffic has other, far more common causes too \u2014 poorly tagged UTM parameters or redirects that don’t preserve them. Cookie decay is one contributing factor, not the whole explanation.)<\/p>\n\n\n\n

Affiliate commissions disappear.<\/strong> Affiliate systems commonly set a 30-day cookie window. If it’s a JS-set first-party cookie (the common setup today), that window is effectively 7 days in Safari \u2014 the remaining 23 days exist on paper only. A third-party affiliate cookie doesn’t work in Safari at all.<\/p>\n\n\n\n

The conversion window for ad platforms shrinks.<\/strong> gclid<\/code> and fbclid<\/code>, which Google Ads and Meta Ads use to measure conversions, get stored in _gcl_aw<\/code> \/ _fbc<\/code> \u2014 JS-set first-party cookies that typically get hit with an even stricter 24-hour limit in Safari: they’re created right after a click from a domain ITP classifies as a tracker (google.com<\/a>, facebook.com<\/a>), with a click ID in the URL \u2014 exactly the conditions of the link decoration rule. Platforms compensate for some of this loss through modeling via enhanced conversions \u2014 more on that in the section on moving beyond cookies.<\/p>\n\n\n\n

Remarketing splits into two layers with different impact.<\/strong> Classic remarketing via third-party cookies doesn’t work in Safari at all \u2014 and hasn’t since 2020, not “after 7 days.” Audiences built from first-party data (GA4 audiences, lists built from gclid<\/code>) do work, but they lose anyone who doesn’t return within 7 days.<\/p>\n\n\n\n

A\/B tests get noisier.<\/strong> A visitor whose cookie has expired might get a different test variant on their next visit than the one they saw the first time. That doesn’t break the test \u2014 but the added noise extends how long it takes to reach statistical significance.<\/p>\n\n\n\n

None of these impacts is a catastrophe on its own. Added together, they hurt.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Evaluating Measurement Setups<\/h2>\n\n\n\n

If you want a cookie that actually survives, it needs to be:<\/p>\n\n\n\n