Cookieless affiliate tracking for SaaS: why the billing reference beats the cookie

By Jimi Barkway · Published 4 September 2026 · Part of the blog

Does affiliate tracking still work without cookies?

In shortYes, when the referral is written onto the sale itself. The cookie only has to survive from the click to the checkout. After that the billing reference carries the partner's id, and no browser rule can reach it.

"Cookieless" hides two questions. Will a browser keep a referral cookie for the weeks your window runs? And can the sale be tied to the partner at all? Only the second one pays a commission. The first is a detail with a table below.

Here is the path a referral takes in AffiliateRail, from the click on a partner's link to the webhook that hands the sale back with the partner's id on it, and none of it depends on the cookie lasting past the checkout.

The script writes the referral into a first-party cookie on your own domain, and into localStorage as a second copy. Either copy is enough. At checkout the script stamps the referral onto the payment as the billing reference. The webhook brings it back with the sale. The browser is out of the loop.

So the referral has to live in the browser until the checkout. For a SaaS trial that is days. Sometimes minutes. A referral that has to sit in a cookie for a month is a design choice. Safari has rules about it.

What does Safari do to an affiliate cookie?

In shortSafari caps any cookie a script writes at 7 days. If the visitor came from a domain Safari has marked as a cross-site tracker, and the link carried a query string, the cap is 1 day. Storage a script writes is deleted after 7 days without a visit.

The rules are WebKit's own, and each one has a date.

Read the second row twice. The one-day cap needs two things at once. The site the visitor came from must be one Safari has marked as a tracker. And the landing URL must carry a query string or a fragment. Every affiliate link has the second. Whether the first applies is Safari's call, made on the device. So the one-day cap is real, and rare, and you will not know which visitors it hit.

Now put your window next to the table. A window of a month or two, written into a cookie by script, is a window of 7 days on Safari, and it stays 7 days whatever number the settings page shows, because the browser applies its own cap after the script has written yours. The table wins.

The script holds the referral in two places, the cookie and localStorage, and either is enough. With a tracker host of your own, something like go.yourdomain.com, the click response sets the cookie from the server instead of from script. That takes it out of the script cap and into the cloaking rule. WebKit treats a subdomain of yours whose CNAME points outside your own domain, and away from wherever your main site's own CNAME points, as a third party in disguise. Cookies in its response are capped at 7 days as well. The rule that beats all of this is the billing reference.

What do ad blockers do to affiliate tracking?

In shortA blocker works from filter lists. If your tracker's script or its click report matches a line, the script never loads or the click never reports. The click count is what suffers. The sale can still bind.

The list most blockers ship with is EasyPrivacy. It carries generic lines for paths such as /affiliate-tracker.js and /affiliatetracking.js, and it names several affiliate platforms by their script host or their tracking script. If your platform is one of them, a visitor with a blocker never runs its script. Nothing loads. No click, no cookie, no referral.

Order matters more than the list. AffiliateRail's script writes the referral to the cookie and to localStorage before it calls home, and it sends the click report with keepalive, so the report survives the visitor leaving the page mid-request. A blocked report costs you a row in the click count. The attribution stays. The sale carries the stored referral whenever it arrives, that afternoon or three weeks later.

That is why the click column is the soft number. Your analytics counts page views at the browser. The click count is the reports that reached the server. Blockers, privacy add-ons and people who close the tab in the first second all sit between the two, which is why the commission column is the one that has to be exact, and it does not depend on that request at all. Two columns, two jobs.

A tracker host of your own closes most of the rest. Serve the script and the click endpoint from go.yourdomain.com and a list that blocks by host has nothing to match. The page is fetching from its own name. The ad-blockers guide has the setup and the honest limits.

Why does the billing reference beat the cookie?

In shortBecause Stripe or Paddle stores it, and the browser does not. On Stripe the referral rides client_reference_id or the session's metadata into the webhook. On Paddle it rides custom_data, which copies to the subscription and to every renewal. Nothing Safari does after the checkout touches it.

Stripe's checkout session has a field made for this. client_reference_id takes up to 200 characters and comes back on the webhook with the completed session. AffiliateRail's script stamps it onto Checkout, Payment Links, Pricing Tables and Buy Buttons on its own, including ones added to the page after load. It never overwrites a value you set yourself. For Stripe Elements or a server-driven flow you read the cookie and pass the click id as metadata on the customer or the subscription. Three lines of code. The Stripe integration page has them.

Paddle's field is custom_data. Set it on the transaction and Paddle copies it to the subscription, and from there onto every renewal. So a commission in month nine needs no cookie, no click and no browser. The reference is on the invoice. The Paddle page walks through it.

Binding happens once. The first event that carries a referral binds the customer to the partner, and later events change nothing. A customer who paid on day three binds on day three, and stays bound through every renewal, on any browser, with any blocker.

What does "first touch wins" mean?

In shortThe first partner whose link a visitor clicks keeps the referral for the whole window. A second partner's link does not overwrite it. AffiliateRail enforces that at the moment of writing, so a later click has nothing to argue about.

Two partners, one visitor. A reviewer's article brings the visitor in on Monday. A coupon site's link catches them at the checkout on Friday. Under last touch the coupon site is paid, even though it did nothing except sit between a reader who had already decided and the buy button. Under first touch the reviewer is paid. Fairer. For a SaaS program the work is in the selling and the checkout is the easy part, so first touch is the rule that pays the work, and it is also the rule that stops coupon sites farming your program, which the fraud module covers.

The rule lives in the write. If a referral is already stored and inside its window, the script leaves it alone. The window is written onto the click when it happens, from the days you set under Program settings, Attribution. So a click is a fact with a date on it.

Is a referral cookie a consent question in the EU and the UK?

In shortBoth regulators say the storage rules apply. The EDPB treats a tracking link as storage on the device. The ICO's worked example of an affiliate pixel says regulation 6 applies. Whether an exception covers your program is a call for you and your adviser. The safe build is consent mode.

The European Data Protection Board published Guidelines 2/2023 on Article 5(3) of the ePrivacy Directive. The second version, dated 16 October 2024, describes tracking links in paragraph 49: an id is added to the URL so a site knows which partner brought the sale and can pay a commission, which the guidelines call "a practice known as affiliate marketing". Paragraph 50 says handing that link to the device counts as storage, through the browser's cache if nothing else. So Article 5(3) applies.

The ICO's guidance carries a worked example that could be your program. An affiliate platform's pixel sits on the order page. The partner id and the click time are stored in the browser and read back at purchase. The ICO's answer: regulation 6 applies. Its page on the exceptions adds a line worth keeping. Strictly necessary for one service does not mean strictly necessary for another. A cashback site's cookie may be needed for the cashback the user asked for. That does not make your affiliate cookie needed for your checkout.

None of this is legal advice. Neither body sets a blanket rule. They say the storage rules apply and the exceptions are narrow. So the question for a founder is practical. Can the program run behind a banner and keep the referral? It can.

How do you keep the referral behind a consent banner?

In shortTurn on consent mode with one attribute on the tag. The referral is then held in memory until the visitor accepts. Nothing is written or sent before that. Leave without accepting and it is gone.

<script async src="https://app.affiliaterail.com/rail/v1/rail.js"
        data-rail="prg_xxxx" data-consent="auto"></script>

window.rail.consent();

The script listens for the signals banners already send: Google Consent Mode's grant of ad_storage or analytics_storage, the IAB TCF's __tcfapi listener, which every TCF banner exposes, and the consent objects two widely used banner tools publish on the page. Most banners can emit Google Consent Mode. Switch that on.

Before the accept, the script makes no network request, writes no cookie and touches no storage. On the accept it sends the held click and writes the cookie. If a referral is already stored, it reuses that one rather than counting a second click. Every click row records whether it was captured under consent mode, so the consent state behind a commission is on the row. The attribution guide has the list your data protection officer will want.

Consent mode is off by default, because most programs outside the EU run no banner, and it is on every plan rather than held for a higher tier. Compliance is not an upsell.

What can nothing fix?

In shortA visitor who blocks scripts for your site, strips referral parameters from URLs, or refuses first-party storage leaves nothing to capture. No tracker of any brand changes that. The only tool that claims to is fingerprinting.

AffiliateRail does no browser fingerprinting. That is a policy, written down. The aim is different: most visitors track reliably, the privacy-minded few fail cleanly rather than half-counting, and every sale that does bind carries an exact commission.

When a sale arrives with nothing on it, Attribution health lists it with what was missing: no click id on the checkout, a click from another program, a window that had closed. Attribute it by hand from the row, which picks up that customer's other invoices too. A partner whose own clicks do not show is usually running a blocker, so ask them to test in a private window.

Common questions