Why does Safari count my returning visitors as new?

What Safari does

Safari’s Intelligent Tracking Prevention has capped cookies created from a script (document.cookie) to a seven-day expiry since 2019, whatever expiry the site asked for (WebKit: ITP 2.1). Since 2020 it also deletes a site’s other script-written storage (local storage, IndexedDB and the like) after seven days of Safari use without the person interacting with the site (WebKit: Full Third-Party Cookie Blocking and More). Safari is the browser on every iPhone, so on a consumer product this can be a large share of your visitors.

What it does to your numbers

• Returning visitors look new. Someone who visits on Monday and again the following Tuesday has two visitor ids in Safari, one in Chrome.
• New visitor counts run high, and the share of Safari (or iPhone) visitors among “new” looks larger than it is.
• First touch is forgotten. If you store the source of the first visit in a cookie, it goes with it. A person who found you on Reddit and signed up ten days later looks like a direct visitor.
• Retention looks worse for Safari users than for everyone else, for no reason to do with your product.

How to tell if it’s affecting you

Split new visitors by browser. If Safari’s share of new visitors is clearly higher than its share of all visits, and it grows with the gap between visits, the cap is doing it.

What helps

1. Let people tell you who they are. When a visitor signs in or leaves their email, link that visit to the person. Every later sign-in links that day’s new id to the same person, so their visits join up even when the cookie didn’t survive. Make it happen on every signed-in page load, not only at login.
2. Store the source on the user, not only in a cookie. Save where someone came from on their account when they sign up, so a lost cookie can’t change it later.
3. Read retention from signed-in users. For people with an account, your own database knows they came back; trust it over cookie-based visitor counts.
4. Don’t track around it without permission. Identifying a browser by its settings is what these limits exist to stop when nobody agreed to it, and in the EU it needs the same consent as a cookie.

Serving a cookie from your own server instead of a script avoids this particular cap, but it needs a server in the same site as your pages and doesn’t help against the other limits.

With Nordva Launch

Launch’s visitor id is set by its script, so Safari caps it like every other script-set cookie. Launch writes it again on every visit, so the seven days count from the last visit. On a Mac, where visitor ids are allowed, somebody who stayed away longer than a week is usually recognised anyway, by a keyed one-way code from their network address, browser and language, for up to 30 days. What Launch adds beyond that is the joining up: identify() or data-nordva-identify on a form links each new id to the person, their contact page shows every visit, and their source stays the one from their first identified visit.