Blog · Bounce tracking
Chrome bounce tracking still wipes redirect pixels. Third-party cookies staying did not save the bounce hop.
Chrome still wipes redirect pixels. Third-party cookies remaining in Chrome did not save the bounce hop. Bounce tracking mitigations stay on the supported list after the Privacy Sandbox ads APIs were retired.
The first fix most stacks will ship is to wait. Chrome kept third-party cookies. Topics, Attribution Reporting, and Protected Audience are on the deprecate-and-remove list. The bounce heuristic is not. Privacy Sandbox status, last updated 14 August 2026, lists bounce tracking mitigations under Continue to support, next to CHIPS and FedCM. A click tracker that 302s through a tracker domain to set a first-party cookie is still the pattern the heuristic is built to notice.
The wipe is not global. Chrome deletes state when the user blocks third-party cookies, including Incognito, and the bounce site has no recorded interaction in 45 days. If third-party cookies are allowed, Google says the mitigations largely add no value, because a third-party cookie already does what the bounce was simulating. The news is the population that still blocks: Incognito, settings, WebView policies, and every Chromium fork that ships 3PC off. The hop did not get a reprieve.
The hop is first-party on purpose
Google's key term is blunt. Bounce tracking is a method of circumventing anti-tracking browser settings. It lets a third-party vendor set and read first-party cookies. MDN splits the pattern into bounce back and bounce through. The user starts on site1.example, hits tracker.example long enough to write a cookie, then returns to site1.example or continues to site2.example. The redirect can be so fast the user never notices tracker.example in the chrome.
That is the click tracker a lot of pixels still sit on. Publisher 302 to an ad server. Ad server 302 to a stamper host that writes clickid= as a host-only cookie, then 302 to the landing page. When third-party cookies are blocked, this hop is how the id was supposed to survive. Chrome's mitigation is to flag the bounce site and later delete its storage.
The heuristic does not use a tracker list. Chrome monitors navigations and flags sites that are part of a bounce: server 3xx and client-side redirects where JavaScript triggers a navigation. Periodically it checks whether the user actively used that site in the last 45 days: a click, a form, a scroll. Interaction can happen before, during, or after the bounce was detected. No interaction, third-party cookies blocked: storage is deleted shortly after the next redirection flow through that site. MDN notes the heuristic operates on sites, so foo.tracker.example and bar.tracker.example are the same registrable domain.
What gets deleted, and who still runs this
The wipe is not cookies only. MDN lists localStorage, IndexedDB, Cache API, and network state. A pixel that moved the click id from a cookie into localStorage on the stamper host is still in the bag. Stateless mode is the current implementation: earlier builds flagged only bounces that set state. Firefox 145 moved bounce tracking protection to stateless mode. Chromium shipped the mitigations in 116.
Chrome enables them when user settings block third-party cookies. Chromium disables third-party cookies by default only in Incognito (Edge InPrivate is the equivalent). Firefox supports bounce tracking protection in Enhanced Tracking Protection strict mode. Safari does not implement the bounce tracking mitigations spec; it has list-based protection from ITP 2.0. A chain that looks fine in a logged-in Chrome window is a different chain in Incognito and in Safari.
Google launched the Chrome behavior by default in October 2023 for users who had opted into blocking third-party cookies. The proposal page still says it. Status in 2026 is Continue to support, not deprecate and remove. That is the opposite of Attribution Reporting, Topics, Protected Audience, Shared Storage, Fenced Frames, and Related Website Sets. Keeping 3PC in Chrome was not a pardon for bounce hops. It narrowed the population. It did not retire the wipe.
SSO is out of scope. Your stamper is not.
Redirect flows that involve direct user interaction are out of scope: federated authentication, SSO, payments. Login with an identity provider, a checkout that sends the user to a PSP and back, those are supposed to keep working because the user actually used the site. A silent 302 through click.vendor.example with no button, no form, and no scroll is not that class. If nobody has used the stamper as a first-party site in 45 days, the next bounce is when Chrome deletes it.
The click id on the query string can still survive the hop if every Location forwards it. The cookie written on the stamper host is what the mitigation targets. A pixel that reads only the stamper cookie on a later page, after the landing URL lost the query, is the outage. First-party cookies on the advertiser host, written after the user lands, are a different jar. Copy gclid, fbclid, ttclid, vmcid out of the landing URL on first hit and persist them on your host. Do not rely on the bounce domain to remember the user for you.
The hop that still looks like a pixel
A bounce through a tracker host that writes first-party state, then 302s to the landing page.
HTTP/1.1 302 Found
Location: https://click.vendor.example/b?then=https://shop.example/lp?gclid=Cj0TEST
Set-Cookie: clickid=abc; Path=/; SameSite=Lax
HTTP/1.1 302 Found
Location: https://shop.example/lp?gclid=Cj0TESTThat chain can look healthy in curl -sIL. Both hops are 302. The landing URL still has gclid. The failure is later: Chrome flags click.vendor.example as a bounce site. If the user never interacted with that site in 45 days and third-party cookies are blocked, Chrome deletes its cookies and the rest of its storage after the next bounce. The next click writes clickid= again, then loses it the same way. Events Manager shows a click. The stamper cookie is gone before the conversion pixel reads it.
If hop two drops the query, you have both bugs: no gclid on the landing URL, and a stamper cookie that Incognito will not keep. Fix the Location first. Then stop using the stamper cookie as the only join. The landing page should write a first-party cookie on shop.example from the query, and the conversion API should receive that value from your server.
Names that do not translate
- A first-party cookie on the stamper host is not a first-party cookie on the advertiser host.
- SameSite=Lax on the bounce domain does not exempt it from the heuristic.
- localStorage on the stamper is in the wipe with cookies, IndexedDB, and Cache API.
- Incognito is 3PC blocked. A logged-in Chrome window with 3PC allowed is not the test.
- Safari ITP bounce protection is a list. Chrome bounce tracking mitigations are a heuristic.
- SSO and payments are out of scope because the user interacts. A silent 302 is not SSO.
- Keeping third-party cookies in Chrome is not Continue to support for Topics or ARA.
Status is continue to support, not a Sandbox leftover
On 17 October 2025 Chrome said it would retire Attribution Reporting, Topics, Protected Audience, Related Website Sets, and the rest of the low-adoption ads APIs, and continue to support CHIPS, FedCM, and Private State Tokens. Bounce tracking mitigations were never in that retirement list. The status table still groups them with CHIPS under Continue to support.
Google's own bounce page says the proposal largely only adds value when third-party cookies are disabled. That sentence is why people declared the hop safe when 3PC stayed. It is also why Incognito and user settings still wipe it. Test the chain where 3PC are blocked.
Do not migrate a bounce cookie into Shared Storage as a workaround. Those ads APIs are being deprecated. The remaining path is a first-party cookie on a site the user actually used, plus a server event with the click id.
If the site does not have any user interaction recorded within the last 45 days and third-party cookies are blocked, then the site storage will be deleted shortly after the next redirection flow is triggered through this site.
Chrome: bounce tracking mitigations
What to do
Walk the click chain with curl -sIL. Every hop before the landing document should be 3xx. Every Location should still carry the click id. Then assume the stamper cookie is gone for anyone who blocks third-party cookies.
Capture the click id on first landing hit on your host. Persist it first-party. Pass it on the conversion API. Do not add a second bounce domain to compensate for the first. Do not require the user to interact with the tracker site. That interaction exemption exists for SSO and payments, not for a click stamper.
The contract for hop-by-hop failures is the redirect pixel chains page. This post is the market fact: Chrome kept third-party cookies and kept wiping bounce state when those cookies are blocked. Pixellint is not affiliated with Google or Mozilla. Passing a linter means the artifact matches the published URL and cookie shape. It does not mean Chrome kept the stamper cookie, and it does not detect fraud.
Checklist
- Treat bounce tracking mitigations as Continue to support, not as a retired Sandbox API.
- Test click chains in Incognito and in a profile that blocks third-party cookies, not only in a 3PC-allowed window.
- Forward the click id on every Location. Do not let the stamper cookie be the only copy.
- Write a first-party cookie on the advertiser host after landing. Send that value on CAPI.
- Expect cookies, localStorage, IndexedDB, and Cache API on the bounce site to vanish after 45 days with no interaction.
- Do not use a silent 302 as SSO. SSO is out of scope because the user actually uses the identity provider.
Sources
Contract pages
The dated argument is above. These pages are the field lists.