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, as long as you write the referral onto the sale itself. Then the cookie only has to last from the click to the checkout. After that the payment carries the partner's id. No browser rule can touch it.

Two quick definitions, because the rest of this hangs on them. Attribution is working out which partner should get credited for a sale. A referral is the little tag saying which affiliate sent this visitor. It gets picked up from their link. It has to survive until the person buys something.

"Cookieless" is really two questions wearing one word. Will a browser hang on to that tag for the weeks your program allows? And can the sale be tied back to the partner at all? Only the second one pays anybody. The first is a detail, with a table below.

Here is the path a referral takes in AffiliateRail. The script writes the tag into a cookie on your own domain. It also writes a spare copy into the browser's local storage. Either one is enough. At the checkout it copies the tag onto the payment. Stripe hands it back to you with the sale. The browser is out of the picture from then on.

So the tag only needs to live in the browser until checkout. For a SaaS trial that is days, sometimes minutes. Needing it to sit there for a month is a choice you made. Safari has opinions about it.

What does Safari do to an affiliate cookie?

In shortSafari cuts any cookie written by JavaScript down to 7 days. Say the visitor came from a site Safari has flagged as a tracker. And say the link had a question mark in it. Then it becomes 1 day. Anything a script puts in local storage is wiped too. That happens after 7 days without a visit.

These are WebKit's own rules, and each one has a date on it.

Read the second row twice. That one-day cap needs two things to be true at once. The site they came from has to be one Safari already treats as a tracker. And the landing URL has to carry a query string. Every affiliate link has the second. The first is Safari's decision, made on the device. You will never know which visitors it hit.

Now hold your own settings up against that table. Your cookie window is how long after a click you still pay commission. Most founders set it to a month or two. Written into a cookie by a script, on Safari, it is 7 days. It stays 7 days no matter what your settings page says. The browser applies its cap after your script has written the cookie. The table wins.

You can serve the tracker from your own subdomain, something like go.yourdomain.com. Then the cookie is set by the server rather than by a script. That gets you out of the script rule and into a different one. WebKit spots a subdomain of yours that secretly points somewhere else. It treats it as a stranger in your clothes. So those cookies get capped at 7 days too. The thing that beats all of it is putting the tag on the payment.

What do ad blockers do to affiliate tracking?

In shortA blocker works from a list of known addresses. If your tracker's script matches a line on that list, it never loads. The click is never recorded. Your click count suffers. The sale can still be credited.

The list most blockers ship with is EasyPrivacy. It has catch-all lines for filenames like /affiliate-tracker.js. It also names several affiliate platforms outright. FirstPromoter, Tapfiliate, LeadDyno, Affonso and Refersion are each blocked as a third-party host. If yours is one of them, a visitor running a blocker never runs its script at all. No click, no cookie, no tag.

The order things happen in matters more than the list. AffiliateRail's script writes the tag to the cookie and to local storage before it reports anything. It sends that report in a way that survives the visitor closing the tab mid-request. A blocked report costs you one row in your click count. It does not cost you the sale. The sale carries the stored tag whenever it turns up, that afternoon or three weeks later.

That is why your click number is the soft one. Your commission number is not. Your analytics counts page views in the browser. Your click count is only the reports that made it to a server. What sits in the gap? Blockers, privacy add-ons and people who close the tab in the first second.

Serving from your own subdomain closes most of the rest of it. A list that blocks by address then has nothing to match against. The ad-blockers guide has the setup and the honest limits.

Why is putting the tag on the payment better?

In shortBecause Stripe or Paddle keeps it, and the browser does not. Both give you a spare field on a payment where you can write whatever you like. Both hand it back with the sale. Nothing Safari does afterwards can reach it.

Stripe's checkout has a field built for exactly this. client_reference_id holds up to 200 characters and comes back when the sale completes. AffiliateRail's script fills it in by itself on Checkout, Payment Links, Pricing Tables and Buy Buttons. That includes ones that appear on the page after it loads. It never overwrites a value you set yourself. If you build your own checkout, you read the cookie and pass the click id along instead. Three lines of code, on the Stripe integration page.

Paddle's version is custom_data. Put it on the first transaction and Paddle copies it to the subscription. From there it goes onto every renewal. So a commission in month nine needs no cookie, no click and no browser at all. It is on the invoice. The Paddle page walks through it.

This happens once and then holds. The first payment carrying a tag ties that customer to that partner. Later events change nothing. Someone who paid on day three is tied on day three. They stay tied through every renewal, on any browser, with any blocker running.

What does "first touch wins" mean?

In shortThe first partner whose link somebody clicks keeps the credit for the whole window. A second partner's link cannot take it. AffiliateRail enforces that when the tag is written. So a later click has nothing to argue with.

Imagine two partners and one visitor. A reviewer's article brings them in on Monday. A coupon site catches them at the checkout on Friday. Pay on last touch and the coupon site gets the money. It did nothing but sit between a reader who had already decided and the buy button. Pay on first touch and the reviewer gets it.

For a SaaS program that is the fairer rule. The work is in the persuading and the checkout is the easy bit. It also stops coupon sites farming your program. The fraud module covers that.

The rule lives in the moment of writing. If a tag is already stored and still inside its window, the script leaves it alone. The window is stamped onto the click as it happens. It comes from the days you set under Program settings, Attribution.

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

In shortBoth regulators say the storage rules apply to it. The EU's board treats a tracking link as storing something on the device. The UK's ICO says the same about an affiliate pixel. 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. The 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 them. The guidelines call that "a practice known as affiliate marketing". Paragraph 50 says handing that link to the device counts as storing something on it. That is through the browser cache if nothing else. So the rules apply.

The ICO's guidance has a worked example that could be your program. An affiliate platform's pixel sits on the order page. The partner id and click time are kept in the browser and read back at purchase. Its answer is that the storage rules apply. Its page on the exceptions adds a line worth keeping. Necessary for one service does not mean 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 practical question for a founder is this. Can the program run behind a banner and still keep the tag? 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. If they leave without accepting, 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. One is Google Consent Mode's grant of ad_storage or analytics_storage. Another is the IAB TCF's __tcfapi listener. The third is the consent objects two widely used banner tools publish on the page. Most banners can send Google Consent Mode. Switch that on.

Before somebody accepts, the script makes no network request. It writes no cookie and touches no storage. When they accept, it sends the click it was holding and writes the cookie. Every click row records whether it was captured this way. So the consent behind a commission is on the row itself. The attribution guide has the list your data protection officer will ask for.

Consent mode is off by default, because most programs outside the EU run no banner. It is on every plan rather than saved for an expensive one. Compliance is not an upsell.

What can nothing fix?

In shortSome visitors block scripts on your site. Some strip the tracking bits out of URLs. Some refuse storage altogether. They leave nothing to capture. No tracker of any brand changes that. The only thing that claims to is fingerprinting.

Fingerprinting is telling a browser apart by its settings, its fonts and its screen, with no cookie at all. AffiliateRail does no browser fingerprinting. That is a written policy, not an omission. The aim is different. Most visitors track reliably. The privacy-minded few fail cleanly instead of half-counting. Every sale that does get tied to a partner carries an exact number.

When a sale turns up with nothing on it, Attribution health lists it. It shows what was missing too: no click id on the checkout, a click belonging to another program, a window that had already closed. You can credit it by hand from that row. That picks up the customer's other invoices too. A partner whose own test clicks never show is usually running a blocker. Ask them to try it in a private window.

Common questions