First-party cookie tracking
Safari's Intelligent Tracking Prevention caps cookies set through JavaScript at seven days, which is why attribution disappears on any consideration window longer than a week. A cookie set in an HTTP response from your own subdomain isn't subject to that cap — it's a different mechanism, not a workaround — and can persist up to the 400-day maximum browsers now apply under RFC 6265bis. That single difference is the main technical reason server-side setups keep attribution that browser-side ones lose.
Free30 minutesNo obligation
First-party cookies · what breaks
Where teams get this wrong — First-party cookies
- 01
Assuming cookie expiry is what you set
You request a lifetime. The browser decides, and Safari overrides JavaScript-set cookies to seven days.
- 02
Treating first-party as a tracking-prevention bypass
It isn't. It's a different storage mechanism with different rules, and consent still applies fully.
- 03
Testing in Chrome only
Chrome doesn't apply the same cap. A cookie that looks fine in Chrome can be capped at seven days in Safari.
First-party cookies · the fix
What a correct implementation looks like — First-party cookies
Cookies set in an HTTP response
From your own subdomain, not from JavaScript.
A tagging subdomain on your own certificate
So the cookie is genuinely first-party.
Lifetimes inside the 400-day maximum
Requesting longer gets silently truncated.
Verified on a real Safari device
Not in a desktop emulator.
First-party cookies · architecture
What caps what, and where — First-party cookies
The rules that decide cookie lifetime in practice. Browser behaviour changes; verify against current vendor documentation before relying on any of it for a build.
- 1
JavaScript-set cookies in Safari
Capped at 7 days by ITP. This is the constraint that breaks most attribution.
- 2
Link-decorated cross-site navigation in Safari
Can be capped more aggressively still. Cross-domain journeys are hit hardest.
- 3
Server-set first-party cookies
Set in an HTTP response from your own subdomain. Not subject to the JavaScript cap.
- 4
The 400-day maximum
Browsers cap cookie lifetime at 400 days under RFC 6265bis regardless of what you request.
- 5
Third-party cookies
Blocked by default in Safari and Firefox, and increasingly constrained elsewhere. Not something to build on.
First-party cookies · diagnose
Common mistakes and how to validate each — First-party cookies
Ordered by how often we find them. Each one has a specific check rather than a general instruction to be careful.
- 01
Testing only in Chrome
Repeat the test in Safari on a real device. The behaviour is genuinely different.
- 02
A CNAME without your own certificate
Check what certificate the tagging subdomain presents. If it isn't yours, it may not be treated as first-party.
- 03
Requesting a lifetime over 400 days
Read the cookie's actual expiry in the browser rather than the value you set.
- 04
Assuming the cookie survived
Wait eight days and check. This is the only test that proves anything, and almost nobody runs it.
- 05
Setting cookies before consent
Check what's set on first load with consent denied. First-party is not an exemption.
First-party cookies · prove
How to prove your implementation is right — First-party cookies
Against your own records and a live payload, not against a preview screen.
Source of truth
the actual cookie expiry read in the browser, on a real device
- Tagging subdomain resolving on your own certificate.
- Cookie confirmed set via Set-Cookie rather than document.cookie.
- Persistence confirmed in Safari more than seven days after being set, on a real device.
- Nothing set when consent is denied, verified by capture.
- Checked on a live conversion, not in preview mode.
- Reconciled over a fully closed window, matched per record.
- Re-checked 30 days later.
First-party cookies · free audit
What we check in the free audit
- Testing only in Chrome
- A CNAME without your own certificate
- Requesting a lifetime over 400 days
- Assuming the cookie survived
- Setting cookies before consent
Checked against
the actual cookie expiry read in the browser, on a real device
Free30 minutesNo obligation
First-party cookies · when not to buy
What this reference deliberately leaves out — First-party cookies
Stated openly, because a reference that's silent about its own gaps is the dangerous kind.
- Browser tracking-prevention behaviour changes without much notice. Everything here is accurate as last verified and should be re-checked before a build.
- Firefox and Brave apply their own rules that differ from Safari's and aren't covered in detail here.
- The exact conditions under which Safari applies its more aggressive caps aren't fully documented publicly, so we've described the general behaviour rather than guessing at thresholds.
- Vendor documentation is the authority, not this page. Where the two disagree, the vendor is right and we'd like to know so we can correct it.
- Parameter names and behaviour change. Anything here is accurate as we last verified it; verify against the current documentation before you rely on it for a build.
First-party cookies · what we deliver
The checklist — First-party cookies
Cookies are set via Set-Cookie, not document.cookie
The whole difference lives here.
The tagging subdomain resolves on your own certificate
A CNAME to a third party without your certificate isn't the same thing.
Requested lifetime is 400 days or less
Anything longer is truncated by the browser.
Persistence verified in Safari after seven days
On a real device, with a real gap in between.
Consent gates cookie setting
First-party doesn't exempt you from anything.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
Repairs and verifies your existing browser-side setup against this reference, on a live conversion.
- Implementation checked against the spec
- Verified on a live conversion
- Reconciled against your own records
- Written handover
1st-party server-side
Recommended$800One-time fee · most popular
Money events sent from your own records through a first-party container on your subdomain, built to this specification.
- First-party server container on your own subdomain
- Events from your records, not the browser
- Deduplicated on a shared event ID at every destination
- First-party cookies beyond Safari's 7-day cap
- 95%+ accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid channel server-side plus the offline loop, documented to this standard.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop
- Refunds and cancellations corrected wherever each platform allows it
- Monitoring so the next break surfaces in days
FAQ
First-party cookies questions, answered
Safari's ITP caps cookies set through JavaScript at seven days regardless of the expiry you requested. It's the single biggest cause of lost attribution on longer consideration windows.
It avoids the JavaScript cap because it's set differently. It doesn't exempt you from consent, and it isn't a bypass — it's a different mechanism.
Up to 400 days, under the limit browsers apply per RFC 6265bis. Requesting longer gets silently truncated.
Set the cookie, wait more than seven days, and check it in Safari on a real device. Chrome won't show you the problem.
Free · 30 min
Get cookies that outlive your consideration window
WhatsAppFree30 minutesNo obligation
