First-party cookies and affiliate tracking in 2026

In 2026, affiliate tracking that depends on third-party cookies is unreliable in Safari and Firefox and only works in Chrome because Google decided in April 2025 to keep its existing third-party cookie choice rather than phase them out. Safari blocks all third-party cookies by default and deletes cookies written by JavaScript after 7 days without user interaction with the site; Firefox gives every site its own separate cookie jar by default. The approach that holds up across browsers is first-party cookies affiliate tracking: store the referral on the brand's own domain, carry it into checkout as Stripe's client_reference_id, and let the payment record hold the attribution from then on. This post explains each browser's rules as of October 2026, what they break, and the four techniques that still work.

Third-party vs first-party cookies: the difference that matters

A cookie is first-party when it belongs to the site in the address bar. If a visitor is on yourbrand.com and a cookie is stored for yourbrand.com, it is first-party. A cookie is third-party when it belongs to a different site that is embedded in or called from the page, such as a tracking pixel from an affiliate network's domain. The browser decides which is which by comparing the cookie's site with the top-level site, not by who wrote the code.

Classic affiliate tracking was built on third-party cookies. The partner link pointed at the network's domain, the network set a cookie on its own domain during the redirect, and later a pixel on the merchant's thank-you page, also served from the network's domain, read that cookie back. Both reads and writes happen on the network's domain while the visitor is on someone else's site. That is exactly the pattern browser privacy features were designed to stop, because the same mechanism lets an ad network follow a person across every site that embeds it.

First-party tracking changes where the referral is stored. The partner link still carries an identifier, but the brand's own site reads it and stores it in a cookie on the brand's domain. Nothing needs to be read across sites. The network learns about the referral when the brand's site or server tells it, not by reading its own cookie on someone else's page.

Where each browser stands in October 2026

The three engines that matter for most traffic have taken different positions. The table summarises the parts that affect affiliate tracking; the sections below give the detail and sources.

Safari: Intelligent Tracking Prevention

WebKit's tracking prevention page states that it blocks all third-party cookies by default, with access only through the Storage Access API or a temporary compatibility fix [1]. For first-party cookies the important rule is the 7-day cap: cookies created in JavaScript, and other script-writeable storage, are deleted after 7 days without user interaction with the website [1]. There is a stricter rule for link decoration: when a domain classified as having cross-site tracking capabilities navigates the user to a page and the final URL has a query string or fragment, cookies created by JavaScript on that landing page are capped at 24 hours [2]. And when ITP detects third-party CNAME cloaking or third-party IP address cloaking, it caps cookies set in the HTTP response to 7 days [1].

What this means in practice: a referral cookie written by your own site's tracking script survives a week in Safari, not 60 days, unless the visitor comes back and interacts with your site within that week. If the partner's own site has been classified as a tracker, a decorated link from it can reduce that to a day. None of this is a bug in your setup; it is the browser doing what it says it does.

Firefox: Total Cookie Protection

Mozilla made Total Cookie Protection the default for all Firefox desktop users worldwide in June 2022, and its post was updated in August 2024 [5]. It works by creating a separate cookie jar for each website the person visits. A third-party cookie set by an affiliate network while the visitor is on a partner's blog is stored in that blog's jar and is not visible when the same network is called from the merchant's site. Classic cross-site pixel tracking therefore fails in Firefox, while first-party cookies on the merchant's domain behave normally.

Chrome: third-party cookies stay, the replacement APIs go

On April 22, 2025, Google said it would maintain its current approach to offering users third-party cookie choice in Chrome and would not launch a new standalone prompt; users keep the setting in Chrome's privacy and security settings [3]. On October 17, 2025, Google announced it would retire most Privacy Sandbox technologies because of low adoption, including the Attribution Reporting API, Topics, Protected Audience, IP Protection and Related Website Sets, while continuing to support CHIPS, FedCM and Private State Tokens [4]. For affiliate tracking this means third-party cookies still work for Chrome users who have not blocked them, and the browser-native attribution API that some vendors were preparing for will not arrive in its current form.

It would be a mistake to read Chrome's decision as a reason to keep relying on third-party cookies. Safari and Firefox still block or partition them, and some Chrome users block them by choice. A tracking method that works in one engine and fails in two is not a method you can promise partners a commission on.

What breaks in classic affiliate tracking

Walk through one referral the old way and mark where it fails. A visitor reads a partner's review on a blog, clicks a link to network.example/click?aff=123, gets a cookie on network.example during the redirect, lands on yourbrand.com, and signs up three days later. Your thank-you page loads a pixel from network.example that should read the cookie.

• Safari: the pixel request is a third-party request on yourbrand.com, so its cookie is blocked. The conversion is lost.
• Firefox: the cookie was stored in a jar keyed to network.example as a top-level site during the redirect; the pixel on yourbrand.com sees the jar for yourbrand.com. The conversion is lost.
• Chrome with default settings: the pixel can read the cookie. The conversion is recorded.
• Chrome with third-party cookies blocked by the user: the conversion is lost.

If, purely for illustration, 30% of your partner traffic used Safari, 5% Firefox and 65% Chrome, and one in ten Chrome users blocked third-party cookies, then a pixel-based setup would record 0.65 × 0.9 ≈ 58.5% of conversions. The remaining 41.5% would be invisible regardless of how long the cookie window is. Use your own browser mix from analytics to compute your number; the point is that the loss is structural, not a tuning problem.

The four techniques that still work

Robust affiliate tracking in 2026 combines four techniques. None of them is new and none relies on a cross-site cookie.

1. Link decoration with a plain parameter

The partner link points directly at the brand's page with an identifier in the query string, for example yourbrand.com/?via=anna. The identifier is visible, readable by the brand's own code and needs no redirect through a third-party domain. Keep the parameter short and human-readable, such as a partner slug, rather than a long opaque click ID; a readable slug is easier for partners and customers to trust and to check. Test your links in Safari Private Browsing anyway, because that is where parameter handling is strictest.

2. A first-party cookie on the brand domain

A small script on the brand's site reads the parameter and writes a cookie on the brand's own domain. Because the cookie is first-party, it is readable on every page of the site, including checkout. In Safari it is subject to the 7-day cap described above, which is why it should be treated as the bridge between the click and checkout, not as long-term storage.

3. Server-side attribution through checkout

This is the step that makes the rest durable. When the customer starts checkout, the brand's server reads the referral id from the cookie and passes it to Stripe when creating the Checkout Session, in the client_reference_id field. Stripe documents that field as a unique string to reconcile the session with your internal systems, up to 200 characters [6]. From that moment the referral is part of the payment record. Every later renewal invoice belongs to the same customer and subscription, so commission on renewals is matched from the invoice, not from anything the browser remembers.

In other words, the browser only needs to remember the referral from the click to the checkout. For the many customers who check out within a week, Safari's 7-day cap never comes into play. For those who take longer, the next technique matters.

4. Personal coupon codes

A code typed at checkout attributes the customer without any cookie, on any device, at any time. In Stripe this is a promotion code, a customer-facing string that maps to a coupon. Coupons fill the gap that browsers create, and they are the only technique that works for audiences who hear about a product in a podcast or video and type the address by hand days later.

Do branded tracking domains help?

A branded tracking domain is a subdomain such as go.yourbrand.com that points at the tracking provider with a CNAME record. It helps in two concrete ways. First, short links look like the brand's own links, which matters to people deciding whether to click. Second, when a short link on go.yourbrand.com redirects to yourbrand.com, the tracking server can set the referral cookie on the brand's root domain in the redirect response itself, so the referral is stored even on pages where the tracking script is not installed.

It is not a way around browser privacy, and providers that present it that way are overselling. WebKit says that when it detects third-party CNAME cloaking it caps cookies set in HTTP responses to 7 days, the same as JavaScript cookies [1]. So in Safari, a cookie set through a branded domain should be expected to last about a week, like the script cookie. The value of a branded domain is trust and coverage, not a longer cookie. The durable parts are still checkout attribution and coupon codes.

How RelayWonder handles this

RelayWonder was built on the first-party pattern. The tracking script reads the ?via= parameter and writes a first-party rw_ref cookie on the brand's own domain. The brand's checkout passes the referral id to Stripe as client_reference_id, and commission is then calculated per Stripe invoice through Stripe Connect, so renewals, refunds and disputes are attributed from the payment data. Personal partner codes are Stripe promotion codes and attribute without a click. Brands can also add a custom tracking domain such as go.yourbrand.com; when it is active, short links, campaign links and the script use it, and the referral cookie is written on the brand's root domain.

A checklist for first-party affiliate tracking

1. Make sure partner links land on your own domain with a readable parameter, not on a third-party click domain.
2. Install the tracking script on every page a partner might link to, not only the home page.
3. On your server, read the referral id from the first-party cookie and pass it to Stripe Checkout as client_reference_id.
4. Give every partner a personal promotion code and say on your terms page that code purchases are credited without a click.
5. Remove any thank-you-page pixel that depends on a third-party cookie, or keep it only as a secondary signal.
6. Test the full path in Safari, Firefox and Chrome, including Safari Private Browsing, and record which step carries the referral in each.
7. Tell partners honestly how attribution works, including that browsers may shorten how long a click is remembered.