First-party, ITP-proof tracking — the durable visitor id
Safari caps JavaScript-set cookies at 7 days. Flowsk sets the visitor id from your own server, in an HTTP response, where the cap does not apply. That one decision makes your attribution window real.
durable identity = first-party AND server-set
First-party alone is not enough. A first-party cookie written by JavaScript is still capped at 7 days in Safari. A first-party cookie written by your server in a Set-Cookie header is not capped at all — which is why your login session lasts months and your analytics id does not.
This is not a workaround. It is the standards-compliant path, and it is what flowsk.com runs on itself.
Everyone in marketing now knows the phrase “first-party data.” Almost nobody knows that first-party is only half the requirement.
The rule nobody told you
Safari’s Intelligent Tracking Prevention rewrites the expiry of any cookie created through document.cookie down to seven days. It also evicts localStorage, IndexedDB and the Cache API on the same clock.
It applies to cookies on your own domain. Owning the domain does not exempt you. What matters is which side of the wire wrote the cookie:
| Cookie | Written by | Safari treatment |
|---|---|---|
_ga, _fbp, most analytics ids |
JavaScript (document.cookie) |
Capped at 7 days |
| Third-party cookie on another domain | Third-party script | Blocked entirely |
| Your Rails / Django / Express session | Your server (Set-Cookie) |
Not capped |
Your login session survives for months in Safari. Your analytics id does not. Same browser, same domain, same day — different writer.
Every mainstream client-side analytics tag writes its id from JavaScript. GA4 does. The Meta pixel does. Most CDPs do. Most “first-party” tag managers do. All of them are on the seven-day clock, and none of them mention it in the setup guide.
What Flowsk does instead
In proxy mode, the identity never touches JavaScript:
- Your server mints the id — a UUID — on the first request, and sets it in a first-party
Set-Cookieresponse header with a long expiry. - It is
HttpOnly, so JavaScript cannot read it and no client-side heuristic applies to it. - Events post to your own origin, not to a third-party domain, so nothing on any tracker blocklist is involved.
- Your backend forwards them to the Flowsk API server-to-server, where the id travels in the request payload — never as a cookie a browser could block.
That last detail matters more than it sounds. Because the anonymous id is carried in the body of the request rather than in a cookie header, no third-party cookie policy in any browser has a say in whether attribution works. The only variable across install modes is who owns the id, and therefore how long it lives.
What it changes in practice
- A 30-day attribution window is 30 days for Safari traffic too, not 7.
- Returning visitors are recognised as returning, rather than arriving as brand-new anonymous people every week.
- The share of conversions that show up as “direct” stops tracking your ad spend.
- Long consideration cycles — B2B trials, high-ticket services, considered DTC — become measurable at all.
Run the ITP loss estimator with your own numbers to see what that is worth per month before you build anything.
The honest caveat
If you install the snippet only, you get the same seven-day limit as every other JavaScript tracker. We will not pretend otherwise — the snippet is the fast path, not the durable one.
What the snippet-only mode does give you that a normal tag does not is server-side conversion confirmation and identity binding. If a visitor gives you an email inside the seven days, the journey survives on the person rather than on the cookie. That recovers a large share of what would otherwise be lost, which is why we ship both modes rather than gatekeeping the easy one.
We run it on ourselves
flowsk.com sets _fsk_id server-side, on every request, through a small Rails concern. Our own acquisition funnel is measured this way, through the same public interface a customer’s API calls use — same cookie, same API, same code path.
Frequently asked questions
Is this CNAME cloaking?
No. CNAME cloaking points a subdomain at a third-party host to disguise a third-party request as first-party — browsers detect it and it degrades every year. Flowsk's proxy mode is your own backend, running your own code, forwarding events server-to-server. Nothing is disguised.
Does the visitor id contain personal data?
No. It is a random UUID with no meaning outside your own dataset. The email, when you have one, is stored separately and joined to it.
Do I need a developer for this?
For the snippet, no. For the durable server-set id, about an hour of a developer's time — a middleware, a before_action, or a small function depending on your stack. The framework guides cover the common ones.
What about Chrome and Firefox?
Chrome caps first-party cookies at 400 days and has retired third-party cookies; Firefox partitions third-party storage. Neither applies the aggressive 7-day cap to first-party JavaScript cookies that Safari does. A server-set cookie is well-behaved in all three.
Does this break consent management?
No, and it should not. Set the id after consent where consent is required. First-party measurement is compatible with consent; what it is not compatible with is silently exporting behaviour to third parties.
Check whether your site has one
The cookie inspector reads the Set-Cookie headers on any URL and tells you whether a durable, server-set first-party id exists. Most sites find out it does not.
Stop guessing which ad made the sale.
Flowsk Signals stitches the anonymous click to the email to the purchase — first-party, server-side, de-duplicated. One snippet, $29/mo, and every conversion comes with a receipt you can inspect.