How a persistent cookie works
A persistent cookie is set with an expiry date in the future. The browser writes it to disk instead of holding it in memory, so closing the window does not remove it. On the next visit — hours or months later — the same value is handed back to the site, and whatever depended on it picks up where it left off.
The site chooses the lifetime when the cookie is set, but the browser has the final say. Safari in particular shortens the life of cookies written by JavaScript, so a stated expiry far in the future can be trimmed to a matter of days. A cookie sent by the server in the response header is treated more generously. Same cookie, same site, very different survival, purely because of how it was written.
Why persistent cookies matter
Everything that recognises a returning visitor rests on one. “Remember me” on a login, a saved language or currency, a basket that survives overnight, and — most relevant commercially — the analytics identifier that tells you a customer visited three times before enquiring rather than appearing from nowhere.
That last point is why the lifetime question is not academic. If your identifier expires quickly, every visit looks like a first visit, direct traffic swells, and the channel that actually introduced the customer gets no credit. Longer consideration cycles suffer most: property, education consultancies, medical clinics, anything where people research for weeks before making contact.
Where persistent cookies go wrong
The first mistake is setting a long expiry and assuming it holds. It often does not, and nothing warns you — the only symptom is a returning visitor counted as new. Check what your browser reports rather than what your tag configuration claims.
The second is the opposite: keeping personal data in a long-lived cookie because nobody set a retention policy. A persistent cookie is the one most likely to attract a data protection question, so it should hold an identifier, not a name, an email address or an order value.
The third is forgetting they exist during testing. A team that has visited its own site for months carries cookies no real visitor has, which is why a consent banner or a personalised block can look perfect internally and behave differently for everyone else. Always test in a fresh private window.
What to do about it
Open the storage panel in your browser’s developer tools and read the expiry column for your own site. Sort the list into cookies that need a long life to do their job and cookies that were given one by default, then shorten the second group. A shorter lifetime is easier to justify to a regulator and costs you nothing you were actually using.
Where measurement accuracy genuinely matters, look at whether your identifiers are being set by the server rather than by a script, because that is the difference that decides how long they survive. And keep the expiry periods in your privacy policy matched to reality — if the cookie table says one thing and the browser shows another, the policy is the part that is wrong. For anything beyond the basics, treat it as part of a proper analytics and tracking setup rather than a plugin decision, and read it alongside Safari’s tracking prevention rules.