Answer First
Definition: “Cookies lost after redirect” is what happens when a browser drops, resets, or hides cookies — session IDs, A/B-test visitor IDs, conversion-pixel cookies — because a visitor reached a page through a forwarding-link redirect chain instead of a direct visit. The page loads, but tracking sees a stranger: new sessions per click, reassigned A/B visitors, under-reporting pixels.
Why: Modern browsers decide cookie access by site (scheme plus registrable domain), and every major protection — Chrome’s SameSite=Lax default, Safari’s Intelligent Tracking Prevention (ITP), Firefox’s Enhanced Tracking Protection (ETP) — treats a cross-site redirect differently from a same-site one. When your entry forwards to a third-party destination, the final hop is cross-site, and cookies that would survive a same-site chain get blocked, partitioned, or purged. Nobody “loses” them on purpose — the browser is doing its job.
Example: A campaign entry at go.yourbrand.com/sale forwards to vendor.com/landing. A Safari user clicks. vendor.com’s tag manager tries to set a session cookie on its own analytics domain — third-party in this context, so ITP drops it. vendor.com reports a new session and zero conversions, while your Console’s access statistics show the click arrived. The entry is healthy; the cookie never had a legal place to live.
Key Facts
- Chrome 80+ (February 2020): cookies without a SameSite attribute default to SameSite=Lax — sent on top-level cross-site GET navigations, but not on cross-site subresource loads or POSTs.
- Safari: third-party cookies blocked by default; ITP latch mode blocks cookies on all redirects of a blocked request; bounce-tracking classification purges or rewrites cookies.
- Firefox 86+ (February 2021): Total Cookie Protection confines every cookie to the site that created it (default since Firefox 103); redirect tracking protection purges known-tracker storage.
- Same-site vs cross-site is the deciding variable: a branded subdomain forwarding to your own domain is same-site and cookies survive; forwarding to a third-party destination is cross-site and the protections engage.
- The third-party-cookie deprecation debate keeps shifting, but defaults keep tightening: treat cookie persistence through a cross-site chain as the exception.
| Browser | Default since | What it does on a cross-site redirect chain |
|---|---|---|
| Chrome | 80 (Feb 2020) | SameSite=Lax default: no cookies on cross-site subresource loads or POSTs; Lax cookies survive a top-level GET navigation |
| Safari | ITP, on by default (Safari 14+) | Blocks third-party cookies; latch mode blocks cookies on all redirects of a blocked request; bounce-tracking classification purges or rewrites cookies |
| Firefox | 86 / 103 | Total Cookie Protection partitions cookies per top-level site; redirect tracking protection purges tracker storage; bounce-tracking mitigations delete state of unused bounce sites |
Expert Explanation
How a forwarding chain works. A redirect is an HTTP response (301, 302, 307, and friends) whose Location header tells the browser to load another URL immediately. Every hop is a fresh top-level navigation, and every Set-Cookie is scoped to the domain that sent it — a cookie set by go.yourbrand.com is invisible to vendor.com. The 301-vs-302 choice affects caching and method handling, not cookie visibility; our guide on 301 vs 302 for campaign entries covers which status code fits which entry.
Chrome and SameSite=Lax. Since Chrome 80, cookies with no SameSite attribute default to Lax: sent on same-site requests, plus cross-site requests that are top-level navigations using safe methods. The practical consequence: the destination’s own first-party cookies usually DO survive the final redirect hop in Chrome. So when “sessions reset in Chrome,” the dying cookie is almost always on a third-party vendor domain — tag manager, A/B tool, pixel host — since those cookies are not sent on cross-site subresource loads, and a pixel from the landing page arrives cookieless.
Safari and ITP. ITP blocks all third-party cookies by default. Two redirect behaviors matter most. First, cookie-blocking latch mode: once a request is blocked from using cookies, all redirects of that request are blocked too. Second, bounce-tracking classification: top-frame redirects count as potential bounces, and “tracker collusion” recursively classifies every domain in the redirect graph. Classified domains lose all website data after 30 days without user interaction; bounce-tracking domains may have their cookies rewritten to SameSite=Strict. ITP also downgrades cross-site referrers to their origin — breaking session-source attribution even when the cookies survive.
Firefox and ETP. Firefox 86’s Total Cookie Protection gives each site its own cookie jar: third-party cookies are still “accepted,” but partitioned, so a vendor cookie read under your landing page carries a different value than under any other site — a new session every time. Separately, since Firefox 79 it has purged cookies and site data of known trackers after redirecting users through them, and its bounce-tracking mitigations delete state of redirect “bounce” sites the user never interacted with.
Why same-site vs cross-site decides it. A site is the scheme plus registrable domain. A chain like go.yourbrand.com → www.yourbrand.com/landing is same-site: your cookies are first-party at both ends, and all three protections stand down. A chain ending at vendor.com is cross-site at the final hop: vendor’s own first-party cookies are fine, but every vendor-owned analytics, A/B, or pixel cookie is third-party — and the intermediate link domain’s cookies never arrive at all. Extra third-party hops (ad-platform tracking hops, shortener bounces) add more domains that can be classified and purged. That is why the acquisition consolidation playbook — keeping branded subdomains on your own domain — changes behavior: same-site chains sit outside most of these protections.
Practical limits of this walkthrough. You cannot see ITP’s internal classification list, so “the browser deleted it” is often as specific as a diagnosis gets. Behavior varies by browser version, platform, and user settings (ETP Strict vs Standard, private vs normal windows); your test browser is not your users’ browsers. The checks identify the mechanism and which cookies are exposed — they cannot force a browser to keep a cookie it has decided not to keep.
Decision Framework
Run these checks on the actual entry, in order, before changing ads or analytics.
- Map the chain. Run
curl -sIL https://go.yourbrand.com/sale(or open DevTools → Network → Documents) and list every hop’s host. Classify each hop as same-site or cross-site relative to the final page. - Read the Set-Cookie headers per hop. Which domains set cookies, with what Domain, SameSite, Secure, and Max-Age — and whose cookie is it?
- Reproduce per browser in a private window. Click through, then inspect Application → Cookies (Chrome/Safari) or the partitioned Storage → Cookies view (Firefox). Note which cookies survived for the final origin.
- Compare redirected vs direct. Visit the same landing page directly and compare session ID, A/B visitor ID, and pixel state. Direct works, redirected doesn’t ⇒ the chain is the mechanism.
- Check the entry’s change history. Was the destination or an intermediate hop changed recently — the classic ad approved, landing page changed scenario? Correlate the date with when sessions or conversions started dropping, using the entry’s logs and traceable changes.
- Check the referrer. What Referer does the landing page see? Cross-site hops reduce it to the origin in Safari and Firefox, breaking attribution even when cookies survive.
- Isolate with a same-site control. Point a temporary entry at your own domain; if cookies survive there but not on the cross-site entry, the boundary is confirmed.
Then read the results: a dying cookie on the destination’s own domain points at hop headers or referrer behavior; on a vendor domain, at third-party blocking or partitioning; on the link domain, it is invisible by design — the destination never receives it. For next steps, the 301 vs 302 guide and the ads-get-clicks-but-no-conversions walkthrough cover chain hygiene and entry review.
Key Takeaways
- Cookies are scoped per site: an intermediate link domain’s cookies can never reach a third-party destination, and the same-site or cross-site nature of the chain — not the redirect status code — decides which protections engage.
- Chrome’s Lax default, Safari’s ITP latch and bounce logic, and Firefox’s partitioning and purge fail differently — diagnose per browser, not in aggregate.
- Run the checklist before changing ads or entries; your entry’s status, access statistics, logs, and traceable change history — the same evidence trail compliance audits rely on — help you date the symptom.
- Expect third-party-dependent session and conversion tracking through cross-site chains to keep degrading; that is a privacy default, not a bug in your links.
- When clicks look healthy but conversions don’t, check the campaign entry before rewriting the ads.
FAQ
Q: My sessions reset on every click in Safari but not in Chrome. Is my entry broken?
A: Probably not. Safari’s ITP blocks third-party cookies by default and, in latch mode, blocks cookies on all redirects of a blocked request. If your analytics session cookie lives on a vendor domain (tag manager, pixel host), Safari drops it on arrival — while Chrome’s SameSite=Lax default still lets the destination’s own cookies through a top-level GET navigation, so Chrome looks healthy.
Q: Do SameSite=Lax cookies survive a redirect?
A: Partly. Lax cookies are sent on top-level cross-site GET navigations, so the destination’s own first-party Lax cookies usually survive the final hop. They are not sent on cross-site subresource loads or cross-site POSTs — and cookies set by the intermediate link domain are never visible to the destination.
Q: Why does Firefox start a new session per click even though the cookie still exists?
A: Total Cookie Protection partitions third-party cookies per top-level site (default for all users since Firefox 103), so a vendor cookie read under your landing page holds a different value than under other sites — a new session each time. Firefox also purges known-tracker cookies after redirecting users through them, and its bounce-tracking mitigations delete the state of redirect sites you never interacted with.
Q: Is my conversion pixel under-reporting because of the redirect, or something else?
A: Run the checklist: compare redirected versus direct visits to the same page in a private window in each browser. If the pixel’s cookies sit on a third-party domain, expect under-reporting on cross-site chains in Safari and partitioned values in Firefox. If direct visits under-report too, the pixel, consent flow, or page itself is the problem — not the entry.
Sources
- MDN — Redirections in HTTP
- RFC 9110 — HTTP Semantics: redirection status codes
- MDN — Set-Cookie: SameSite
- WebKit — Tracking Prevention
- Mozilla Security Blog — Firefox 86 Introduces Total Cookie Protection
- MDN — State Partitioning
- MDN — Redirect tracking protection and Bounce tracking mitigations