Your 30-day attribution window is really 7 days
Safari deletes any cookie written by JavaScript after seven days. Half your mobile traffic is Safari. Put your numbers in and see what that costs you every month — no signup, nothing sent anywhere.
Uncreditable ≈ Safari share × P(converts after day 7) × (1 − identified share)
Safari's Intelligent Tracking Prevention caps JavaScript-set cookies and localStorage at 7 days. Any conversion after that arrives as a brand-new anonymous visitor, so the ad that paid for it gets no credit.
A cookie set by your own server in an HTTP response is not capped. That one detail is the entire fix.
—
Effective attribution window on Safari traffic: 7 days, whatever your report says.
— / year
—
Not new revenue — revenue you already earned, attributed to the campaign that actually caused it. That is the difference between scaling the right ad and cutting it.
| Input | Value | What it means |
|---|
Why 7 days, and why only Safari
Safari's Intelligent Tracking Prevention rewrites the expiry of any cookie created through document.cookie down to seven days, and evicts localStorage and IndexedDB on the same clock. It applies to first-party cookies on your own domain — owning the domain does not exempt you. What matters is who wrote the cookie: a cookie set by your server in a Set-Cookie response header is not capped, which is why your login session survives for months while your analytics id does not.
Every mainstream client-side tag — GA4, the Meta pixel, most CDPs, most "first-party" tag managers — writes its id from JavaScript. All of them are on the seven-day clock. Read the full ITP breakdown.
Frequently asked questions
How is the estimate calculated?
Uncreditable share ≈ Safari/iOS traffic share × the share of buyers who convert after day 7 × the share you have not already identified by email. Safari caps JavaScript-set cookies and localStorage at 7 days, so a conversion after that point arrives with no memory of the ad that started it — unless you captured an email first, or set the id from your own server.
Where do I find my Safari share?
Any analytics tool will break sessions down by browser. Use the paid-traffic segment specifically — it skews far more mobile, and therefore far more Safari, than your site average.
How do I find my share converting after 7 days?
In your payment data, measure days from first touch to purchase. If you cannot measure first touch — which is exactly the problem this tool describes — use time from account creation or first email, and treat the result as a floor.
Does identifying by email really fix it?
It fixes the part of the journey after the identification. Once an email is bound to the anonymous sessions that came before it, the person survives even when the cookie does not. It does not help visitors who never identify, which is why the durable server-set id is the complete answer.
Is this an exact figure?
No — it is a structural estimate, and it is deliberately conservative. It counts only the conversions your setup cannot credit by construction. Real-world losses are usually larger, because ad blockers and cross-device journeys sit on top of this.
What is the actual fix?
Set the visitor id from your own server, in a first-party cookie, in an HTTP response. Safari's 7-day cap applies to cookies written by JavaScript, not to cookies written by a server. That is what Flowsk's proxy mode does.
Make the window in your report the window you actually have.
Flowsk sets the visitor id from your own server, so Safari's 7-day cap never applies — and confirms conversions server-side so ad blockers cannot hide them. $29/mo.
More free tools
Same deal — instant, no signup.