Engineering

Affiliate Attribution Without Third-Party Cookies

How to track referrals reliably after third-party cookies: first-party links, server-side conversion events, and durable attribution for SaaS.

$

Affiliate tracking used to lean on third-party cookies. Those are gone or going in every major browser, and privacy tooling blocks the rest. The good news: reliable affiliate attribution never actually needed them. This is how we think about durable, first-party attribution for SaaS at Qanary.

Why third-party cookies were the wrong foundation

A third-party cookie is set by a domain other than the one in the address bar. Browsers now partition or block them, so any attribution model that depends on reading a cookie across domains is fragile by design. If your affiliate tool still relies on that, expect silent under-attribution.

The first-party approach

The durable pattern has three parts:

An affiliate link points at your domain with a parameter — yoursaas.com/?via=jane. When the visitor lands, your own site (first party) records the referrer in a first-party cookie or local storage. Because the domain in the bar is yours, the browser treats it as first-party and keeps it.

2. Server-side conversion events

Attribution is only trustworthy if the conversion is captured server-side. When a customer converts, your billing provider fires a webhook (checkout.session.completed on Stripe, and the equivalents on Paddle, Lemon Squeezy, and Polar). The server matches that event to the stored referrer and writes the attribution — no client-side pixel required, nothing an ad blocker can intercept.

3. A durable identifier

Between click and conversion you need a stable key. A first-party visitor token, carried into checkout and echoed back on the webhook (via client reference ID or metadata), lets the server join “who clicked” to “who paid” without cross-domain tracking.

Handling the edge cases

  • Multiple touches — decide a model (last-touch is simplest and most common for affiliates) and apply it consistently server-side.
  • Refunds and chargebacks — subscribe to refund events and reverse attribution so you don’t pay commission on money you gave back.
  • Cross-device — a click on mobile and a purchase on desktop can’t be joined by cookies alone; account linking at signup closes the gap.

Why this is more accurate, not just more private

Server-side, first-party attribution isn’t a privacy compromise — it’s a correctness upgrade. You attribute against the source of truth (the billing event) instead of a client-side signal that blockers, incognito windows, and cookie expiry quietly erode. This is the spine Qanary runs across all four billing providers.

If you want the practical setup rather than the theory, see how to add an affiliate program to a Stripe SaaS, and the related MCP for AI agents post on making this configurable from a terminal.

FAQ

Do affiliate programs still work without third-party cookies?

Yes. First-party referral links plus server-side conversion events attribute reliably without any third-party cookie.

Is server-side attribution more accurate than pixel tracking?

Generally yes — it reads the billing event directly, so it isn’t degraded by ad blockers, cookie expiry, or private browsing the way client-side pixels are.

How are refunds handled in attribution?

By subscribing to refund/chargeback webhooks and reversing the matching attribution, so commissions reflect revenue you actually keep.

More engineering posts are in the Building Qanary hub.

attributionengineeringprivacy
Share