Safari 7-day cookie cap
Apple's Intelligent Tracking Prevention caps the lifetime of cookies set via document.cookie in JavaScript to seven days, and to one day for visits classified as coming from a tracker-laden link with query parameters. First-party analytics cookies set this way expire early, so returning visitors look new and attribution windows shorten. This page explains the cap and its effect on data quality.
What the cap does
ITP limits the expiry of cookies created through document.cookie in JavaScript to a maximum of seven days. When the visit arrives via a link that ITP associates with cross-site tracking and carries query parameters, the cap tightens to one day. Cookies set by the server in an HTTP response header are treated differently, which is why the set mechanism matters.
Many analytics libraries set their client identifier via JavaScript, so on Safari that identifier resets after the cap, breaking the link between visits.
- Script-set cookies (document.cookie): capped at 7 days
- Some tracker-link + query-param visits: capped at 1 day
- Server-set HTTP cookies follow different rules
How it distorts reports
When the identifier resets, a person returning after the cap is counted as a brand-new visitor, inflating new-user metrics and depressing returning-user and retention figures on Safari. Attribution paths longer than the cap lose their early touchpoints. Because the effect is browser-specific, it skews any segment heavy in Safari or iOS without a single visible error.
Distinguish this from cookie deletion or consent loss: here the cookie is set successfully but simply expires sooner than configured.
How it appears in analytics and logs
A high share of Safari users appearing as new on every visit, or attribution that never reaches past a week, often reflects the 7-day script-cookie cap, not real churn.
Diagnostic use case
Explain inflated new-visitor counts and shortened attribution on Safari by attributing them to ITP's cap on script-set first-party cookies.
What WebmasterID can help detect
WebmasterID favors privacy-respecting first-party measurement, so it reasons about visit patterns without depending on long-lived script-set identifiers.
Common mistakes
- Reading inflated Safari new-user counts as real acquisition.
- Assuming a configured cookie lifetime survives ITP.
- Confusing the cap with consent-driven cookie loss.
Privacy and accuracy notes
ITP is a privacy control; this page describes its measurement effects, not ways to defeat it, and is educational rather than legal advice.
Related pages
- ITP and browser tracking prevention
Intelligent Tracking Prevention (ITP) in Safari/WebKit, and equivalent protections in other browsers, limit how long cookies set by scripts survive and restrict cross-site tracking. The result: returning visitors look new, attribution windows shorten, and cohort retention is understated. This page explains the mechanisms and their effect on analytics.
- First-party cookie expiry
A first-party analytics cookie carries a client identifier whose lifetime depends on its configured expiry, the browser's caps, and the user clearing storage. When it expires, the same person starts as a new visitor and prior-visit linkage is lost. Configured lifetimes are upper bounds browsers can shorten. This page explains the forces that govern first-party cookie expiry and their effect on counts.
- New vs returning misclassification
New-vs-returning depends on recognising the same visitor across visits, which relies on a stored identifier. When that identifier is missing — cleared cookies, tracking prevention, a different device or browser, or declined consent — a returning visitor is recorded as new. The result over-states 'new' visitors and understates loyalty. This page explains the failure modes.
- Privacy-first analytics
Measure return visits without long-lived script cookies.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.