First-party data

First-party cookies and the 400-day difference

First-party cookies and the 400-day difference

Rhobin

July 19, 2026

5 min read

A cookie set by JavaScript in the browser survives 1 to 7 days under Safari's tracking prevention, while the same first-party cookie set server-side on your own domain persists up to 400 days. That difference decides whether a returning visitor is recognised or counted as new, and whether a conversion still ties back to the campaign that earned it.

The symptom

You pull a client's report for a longer campaign, a considered purchase with a sales cycle of a few weeks, and the numbers look softer than the campaign felt. Returning visitors show up as new. Conversions that landed two or three weeks after the first click are not tied to the campaign that earned them. The channel that did the patient work of warming the lead gets none of the credit, and the last-click channel gets all of it.

At Archon Labs we see this pattern constantly, and the agency's first instinct is usually to question the creative or the bidding. Neither is the problem. The problem is that the cookie holding the visitor's history quietly expired long before the visitor came back. By the time they converted, the browser had already forgotten who they were.

This is not a rare edge case on one client. It is happening on every account with Safari and iOS traffic, which is most of them, and it gets worse the longer the buying cycle. The irony is that your most considered clients, the ones whose customers deliberate before they buy, are the ones losing the most measurement.

Why does the same cookie live for a week in one place and a year in another?

Because "first-party cookie" describes who owns the cookie, not how long it survives. Two cookies on your own domain can have very different lifetimes depending on how they are written, and this is the distinction most explanations skip.

A cookie set in the browser by JavaScript, which is how a lot of analytics and tag manager cookies are set, is treated as script-writable storage. Under Safari's Intelligent Tracking Prevention, script-writable first-party cookies are capped at 7 days, and at just 24 hours when someone arrives on a link carrying click parameters like a Google or Meta click ID. WebKit documents this directly in its write-up of full third-party cookie blocking. So the cookie that is meant to remember a visitor for the length of the campaign is often gone within a week.

A cookie set the other way, sent from your own server in the HTTP response rather than written by a script, is not caught by that cap. It persists for the lifetime you give it, right up to the browser's own ceiling. Chrome sets that ceiling at 400 days, clamping anything longer down to 400 rather than rejecting it, as Chrome for Developers explains. Same first-party cookie, same domain, one lasts up to a week and the other lasts over a year. That is the 400-day difference, and it is decided entirely by how the cookie is set.

The mechanism that lets you set cookies server-side from your own domain is a first-party tag gateway, which we cover in more depth in our piece on the first-party tag gateway. Without it, you are relying on browser-written cookies that the browser has already decided to forget.

What good looks like

The fix is to stop letting the browser decide how long your measurement survives, and to set the identifying cookie server-side, from your own domain, so it lives its full term instead of a week. Once the cookie persists, a returning visitor stays the same visitor, and a conversion three weeks later still connects to the click that started it.

This is the job Archon Pixel does. It is the first-party data foundation that sets and maintains long-lived first-party cookies on your own domain, so the visitor history the browser keeps trimming actually stays intact. On a typical account it captures around 25% more than a standard GA4 setup, because the sessions and conversions the short-lived cookies were dropping are now held onto.

At a business level it is three moves, and none of them touch the campaigns themselves.

  1. Set cookies server-side. The identifying cookie is issued from your own domain in the server response, not written by a browser script, so Safari's 7-day cap no longer applies.

  2. Give it a real lifetime. The cookie is set to persist up to the 400-day browser ceiling, so returning visitors across a long sales cycle stay recognised.

  3. Validate against the old numbers. The first-party setup runs alongside the existing one and every metric is checked before anything is relied on, so the new baseline is one you trust.

The result is not a vanity bump on one dashboard. It is a data foundation where the visitor history stops silently expiring, so every report built on it after that reflects a fuller, more honest picture of what the campaigns actually did.

Frequently asked

Does this only affect Safari?

Safari and iOS enforce the 7-day cap most aggressively, so they are where the loss is largest. But the underlying issue, browser-written cookies with short lifetimes, thins your data everywhere, and Chrome's own 400-day ceiling shows the whole industry moving toward shorter, stricter cookie lifetimes. Setting cookies server-side is the durable answer across browsers, not a Safari-only patch.

We already run server-side tagging. Are our cookies already lasting 400 days?

Not automatically. Having a server-side container is not the same as having your first-party cookies actually set server-side with a proper lifetime. Plenty of setups we review send events server-side but still let the browser write the identifying cookie, which means it still expires in 7 days. The lifetime depends on the configuration, not on owning the tool.

Is a longer-lived cookie still compliant?

Yes, when it is set on a lawful basis and respects consent. Cookie lifetime and consent are separate questions. A first-party cookie set server-side still only fires for visitors who have given consent, and it simply carries the lifetime you are permitted to set. Doing it right means longer measurement and compliance, not one at the expense of the other.

Will fixing this change our campaigns?

No. Nothing here touches bidding, budgets or creative. It changes how long the data underneath the campaigns survives, which is usually where the quiet losses in a client report are actually coming from.

If you are not sure how long your clients' cookies are really lasting, the quickest way to find out is to have someone look. Request a free tracking audit and we will show you where the measurement is expiring early.

© 2026 Archon LabsPrivacyTermsBuilt on unsampled data.