400-day first-party cookies that survive Safari ITP

What Safari ITP actually does to your cookies

Apple's Intelligent Tracking Prevention has been progressively tightening cookie controls since 2017. The current state of play affects every measurement and attribution surface you care about.

The actual Set-Cookie header

No magic, no workaround, no probabilistic linking. The 400-day cookie is a single HTTP response header from your own domain. Below is what the gateway sends.

# How a 400-day first-party cookie is set
# 1. Datafly.js sends an event to https://collect.yourbrand.com/v1/p
# 2. Datafly Ingestion Gateway responds with a Set-Cookie header
# 3. Cookie is treated as first-party (server-set, your own domain)
# 4. No 7-day limit from ITP, ETP, or other browser controls

# Response header from collect.yourbrand.com:

Set-Cookie: _dfid=a3f9...; Path=/; Domain=yourbrand.com;
            Max-Age=34560000; Secure; SameSite=Lax

# Max-Age = 34,560,000 seconds = 400 days, refreshed on every event
# Domain scoped to your brand, not a vendor's
# Not HttpOnly: the Datafly.js collector reads the same cookie
# SameSite=Lax allows cross-tab measurement

# The cookie holds only the anonymous ID. Against that identity,
# Datafly Signal stores server-side:
#   - GA client_id, Meta fbp / fbc, TikTok ttp, Snapchat and Pinterest IDs
#     (no _ga, Meta Pixel or ttq.js needed)
#   - Click IDs: gclid, fbclid, ttclid, msclkid, twclid

Cookie lifetime by setup

How long the customer's identity actually persists across browsers, depending on how cookies are written.

Frequently asked questions

Why does Safari delete cookies after 7 days?

Apple's Intelligent Tracking Prevention treats cookies set by JavaScript as a tracking risk. If the visitor doesn't come back within 7 days, Safari deletes them. Arrive from an ad click with gclid or fbclid in the link and the limit drops to just 24 hours. That is why _ga, _fbp, and other vendor-set cookies are regularly gone for Safari users who return after a week or more.

Does Datafly Signal use any fingerprinting to extend cookies?

No. There is no canvas hashing, no IP-based identity heuristic, no probabilistic stitching. The 400-day cookie is a standards-based first-party Set-Cookie response header from your own domain. Safari's 7-day limit on JavaScript cookies does not apply to it, because server-set first-party cookies are exactly what cookies were designed to be.

How does this work on Firefox and Brave?

Firefox Enhanced Tracking Protection and Brave Shields both preserve server-set first-party cookies on your own domain. The same 400-day cookie that survives Safari ITP also survives Firefox ETP and Brave. Chrome's upcoming controls preserve them too. The recovery story is uniform across every modern browser.

What is the difference between server-set and client-set cookies?

A client-set cookie is created by JavaScript via document.cookie. A server-set cookie is created by the server via a Set-Cookie HTTP response header. Browsers track both, but ITP and similar privacy controls treat them differently: server-set first-party cookies from your own domain keep their full Max-Age, while Safari deletes JavaScript cookies after 7 days if the visitor doesn't come back. The behaviour is documented in the WebKit ITP changelog.

Will I lose data if a customer doesn't visit for 400 days?

The cookie expires after 400 days of no activity. In practice, every visit refreshes the expiry, so as long as the customer returns within 400 days the identity persists indefinitely. For most B2C and B2B businesses 400 days covers more than the full buying cycle. Both Apple and Google formalised 400 days as the maximum first-party cookie lifetime, so you can't set longer than this on any browser.

Does this require a CNAME or DNS change?

A DNS change, but not a CNAME to a vendor. Safari limits cookies from a vendor CNAME to 7 days, so collect.yourbrand.com must run on the same infrastructure as your website, with the Datafly Ingestion Gateway behind it. The browser then sees the cookie as set by your own site, which is what makes it first-party and long-lived. No application changes.