Cookieless Affiliate Tracking: What Breaks and How to Fix It

Cookieless affiliate tracking credits conversions to affiliates without relying on browser cookies. The network's click ID arrives in the landing page URL, the advertiser captures it on its own domain, stores it server-side against the user or order, and returns it in a server-to-server postback when the conversion happens. After the first page view, browser rules can no longer break the link between the click and the sale.

This guide is for brands and affiliate managers whose numbers stopped matching their backend: what each browser restriction breaks, the server-side fix, a migration plan and how to measure what you recovered. If you want the platform side first, see how S2S postback tracking works in MassPartner.

What breaks in cookie-based affiliate tracking#

Classic affiliate tracking had two cookie dependencies. The network set a cookie on its own domain during the redirect, and a pixel on the brand's thank-you page read it back. Later, many networks added a JavaScript snippet that stores the click ID in a first-party cookie on the brand's site. Both now fail in predictable ways.

Third-party cookies are blocked or partitioned#

Safari's Intelligent Tracking Prevention (ITP) blocks all third-party cookies by default, with no exceptions (WebKit). Firefox gives every website its own separate "cookie jar" through Total Cookie Protection, which became the default for all desktop users in June 2022 (Mozilla). Either way, a network cookie set during the redirect can't be read by a pixel loaded on the brand's site.

Chrome is the exception. In April 2025 Google said it would keep its current approach of letting users choose in Chrome's settings and would not roll out a standalone third-party cookie prompt; Incognito mode already blocks third-party cookies by default (Privacy Sandbox). So "cookieless" is not a future Chrome deadline. It is already the reality for Safari, Firefox, Incognito and anyone who changed their settings.

Safari limits first-party cookies written by JavaScript#

Moving the cookie to the brand's own domain helps, but only if your server sets it. WebKit's tracking prevention rules (WebKit) cover first-party storage too:

• Cookies created in JavaScript and all other script-writable storage, such as localStorage, are deleted after seven days without user interaction with the site.
• Link decoration. When the visitor arrives from a domain ITP has classified as having cross-site tracking capabilities and the landing URL carries a query string or fragment, cookies created in JavaScript on that landing page are capped at 24 hours.
• Cloaked servers. Cookies set in HTTP responses from third-party servers hidden behind your domain through CNAME or IP address cloaking are capped at seven days.

Example: a program advertises a 30-day cookie. A Safari visitor clicks an affiliate link on day 0, a tracking script writes the click ID to a cookie, and the visitor buys on day 10. The cookie is gone, the pixel fires with no click ID, and the affiliate isn't paid, even though the sale is well inside the advertised cookie duration.

Click IDs are stripped from URLs#

Apple's Link Tracking Protection removes tracking information from links shared in Messages and Mail and from links opened in Safari Private Browsing (Apple Newsroom). WebKit says Safari removes "a subset of query parameters" used for cross-site tracking before the navigation happens, while letting campaign attribution parameters through (WebKit). Apple doesn't publish the list, and users can extend these protections to all browsing in Safari's advanced settings.

The same WebKit post describes a second effect in Private Browsing: after a cross-site navigation, third-party scripts that read the page URL get a version with no query parameters or fragment. A click-capture script loaded from a vendor's domain can therefore miss the click ID even when it is still in the address bar.

Firefox strips known tracking query parameters during navigation when Enhanced Tracking Protection is set to Strict, in normal and private windows; Standard mode doesn't (Firefox source docs).

Ad blockers and tracker blocking#

Content blockers stop requests to known tracking domains, so tracking scripts never load and pixels never fire. Safari ships one built in: in Private Browsing it blocks network loads to known trackers, using a list compiled from DuckDuckGo data and the EasyPrivacy filter list (WebKit). Browser extensions rely on similar lists. A postback sent from your server is outside the visitor's browser, so blockers never see it.

The fix: first-party capture and server-side attribution#

The principle is simple: the browser should only have to carry the click ID for one hop, from the tracking link to your landing page. After that, keep it where browser rules don't apply.

1. Receive the click ID in the landing URL#

The network appends its click ID to your landing page URL. Confirm the parameter survives your own redirects, language or geo routing, consent tools and single-page-app routers. Then test it in a Safari Private window and in Firefox set to Strict. If it is stripped, ask the network whether it can use a different parameter name, and check that the replacement survives too.

2. Capture it on your server, not in a vendor script#

Read the parameter in your backend on the first request and set the cookie in the HTTP response. Cookies your own server sets aren't covered by Safari's cap on JavaScript cookies; the seven-day cap applies to third-party servers cloaked behind your domain. That means your own application or edge, not a vendor's CNAME. A minimal Express example:

// Capture the network click ID on the first request and store it first-party
app.use((req, res, next) => {
  const id = req.query.click_id;
  if (typeof id === 'string' && /^[A-Za-z0-9_-]{8,64}$/.test(id)) {
    res.cookie('aff_click', id, {
      maxAge: 30 * 24 * 60 * 60 * 1000, // match the program's cookie duration
      httpOnly: true,
      secure: true,
      sameSite: 'lax'
    });
  }
  next();
});

Any JavaScript tracking script, ours included, writes a script-set cookie, so treat it as a convenience for short sessions and not as the record of attribution.

3. Persist it on the user or order record#

At registration or checkout, copy the click ID and its timestamp from the cookie or session into your database: a nullable column on the user or order table is enough. From then on, conversions that happen without a browser session, such as a deposit confirmed by a payment provider's webhook or a subscription renewal, can still be attributed.

4. Report conversions with an S2S postback#

When the conversion is committed, your server calls the network's postback URL with the stored click ID, the event, the amount and an order ID for deduplication. Our guide to postback URLs covers parameters, retries and security. In MassPartner, the brand endpoint requires only click_id and event, resolves the campaign and affiliate from the click ID, and comes with an installation tester in the brand dashboard.

5. Keep the attribution window on the server#

Store the click timestamp alongside the click ID. The network can then enforce the window from data it controls, instead of hoping a cookie lasted as long as the program terms promised. How windows and overrides work is covered in our guide to affiliate cookie duration.

Affiliates who run their own trackers face the same problem in reverse. Passing the tracker's click ID in a sub ID and receiving conversions by postback avoids depending on a pixel on someone else's site.

Migration steps: from pixel to server-side#

1. Inventory every conversion signal. List each pixel, script and postback, and which events they report: lead, registration, sale, first deposit, renewal.
2. Map the click ID's path. Follow a real affiliate click through every redirect, domain and app handoff to the confirmation step. Note where the query string or cookie is lost, especially on checkout subdomains, hosted payment pages and app installs.
3. Add server-side capture and storage. Ship the capture and database steps from the previous section before touching reporting, so click IDs start accumulating on real users.
4. Build the postback. Fire it after the event is committed, include an order ID and log every request with its HTTP status.
5. Run in parallel. Keep the pixel live for at least one full conversion cycle and deduplicate by order ID, so you can compare the two methods on the same traffic.
6. Test across browsers. Cover Safari in normal and Private mode, Firefox Strict, Chrome Incognito, a browser with an ad blocker, and a link opened from Mail on iOS.
7. Cut over and tell your affiliates. Remove or demote the pixel, and explain to partners why their reported conversions may rise.

Measuring the lift#

The goal is to see how many conversions you were failing to attribute. Two numbers make that visible:

• Capture rate: the share of the network's logged clicks that reached your server with a click ID you stored. Because capture now happens on your server, you can count it directly and compare it with the network's click report.
• Match rate: the share of orders with a stored click ID that the network credited, by reporting method.

Example: during a two-week parallel run, your backend records 1,000 orders with a stored click ID; postbacks credit all 1,000, while the pixel credited 820. In the Safari segment, the pixel credited 205 of 310 orders. The server-side method recovered 180 conversions overall, a 22% increase over the pixel, and most of the gap sits in Safari.

Segment the comparison by browser family and by days from click to conversion. A typical sign of success is a longer tail of conversions that arrive after day 7, which a script-set cookie could not carry in Safari.

Treat the lift as recovered attribution, not new sales. Commissions will rise with it, so update your budget and tell affiliates before their dashboards change.

Move your program to server-side tracking#

MassPartner gives brands tracking links, a JavaScript tracking script and S2S postbacks with an installation tester, plus fraud checks on every click. Store the click ID on your side and report conversions from your server. See how S2S postback tracking is set up.