Documentation / Tracking / Cookie lifetime
How long a cookie lives
Rows: who answers the request that sets the cookie. Columns: whether the cookie is written by JavaScript in the page or set by that server in its HTTP response (Set-Cookie). Values are for Safari, where the limits bite; Chrome and Firefox are noted underneath. “7 days” always means 7 days after the cookie was last written, so a visitor who returns within a week keeps it.
| Who sets it | JavaScript cookiedocument.cookie (or localStorage) in the page | Server-side cookieSet-Cookie header in the HTTP response |
|---|---|---|
| The page’s own serverThis storeThe same server that delivers the page sets the cookie in that response.e.g. dc_vid on datacop.shop (Oxygen) | 7 daysWritten by a script, so capped whatever the server.Chrome up to 400 days · Firefox as set | As setPasses both Safari checks: not written by a script, same server as the page.Chrome up to 400 days, renewed each visit · Firefox as set |
| A path on the shop’s own domain, proxied to a vendorThe shop’s server forwards /collect to the vendor and sets the cookie itself.e.g. a reverse proxy or edge worker on the same host | 7 daysWritten by a script, so capped whatever the server.Chrome up to 400 days · Firefox as set | As setThe response comes from the shop’s own server, so Safari sees the page’s own IP.Chrome up to 400 days · Firefox as set |
| A subdomain on the shop’s own infrastructurecollect.yourshop.com runs in the same IP range as the website.e.g. self-hosted server-side GTM or walkerOS collector next to the shop | 7 daysWritten by a script, so capped whatever the server.Chrome up to 400 days · Firefox as set | As setNo alias to a vendor, and the IP matches the website’s (roughly the first half of the address).Chrome up to 400 days · Firefox as set |
| A subdomain pointing to a vendor with an NS or A recordNo alias, but the vendor’s servers answer, on the vendor’s IP addresses.e.g. Bloomreach custom tracking domain via NS (their recommended setup), hosted server-side tagging | 7 daysWritten by a script, so capped whatever the server.Chrome up to 400 days · Firefox as set | 7 days (likely)Safari 16.4+ caps HTTP cookies when the responding IP differs from the website’s. As set on older Safari.Chrome up to 400 days · Firefox as set |
| A subdomain pointing to a vendor with a CNAMEThe subdomain is an alias for the vendor’s hostname.e.g. Bloomreach custom tracking domain via CNAME, many vendors’ “first-party domain” setups | 7 daysWritten by a script, so capped whatever the server.Chrome up to 400 days · Firefox as set | 7 daysSafari 14+ detects the alias to another company (“CNAME cloaking”) and caps it.Chrome up to 400 days · Firefox may treat known trackers as third-party |
| The vendor’s own domainThe cookie belongs to the vendor’s domain, not the shop’s: a third-party cookie.e.g. a tracking pixel or SDK calling the vendor’s API directly | Shop’s domain onlyA script in the page can only write cookies for the shop’s own domain, which puts it in the rows above (7 days).Only a vendor iframe could write one for the vendor’s domain, which Safari blocks. | BlockedSafari blocks third-party cookies entirely.Firefox blocks known trackers · Chrome depends on the user’s settings |
dc_vid does, turns “expires after N days” into “expires after N days without a visit”.Safari rules as published by WebKit for Intelligent Tracking Prevention: script-written cookies capped at 7 days (2019), CNAME-cloaked HTTP responses capped at 7 days (Safari 14), HTTP cookies from a server whose IP address does not match the website’s capped at 7 days (Safari 16.4). Chrome stores no cookie for longer than 400 days. Bloomreach setup details from its docs “Custom tracking domain” and “Custom domain management”. Whether a given vendor’s IP matches is the one thing to verify in Safari: Web Inspector → Storage → Cookies → expiry.