Affiliate Tracking: How It Works, What Breaks, and How to Fix It

Affiliate tracking is the mechanism that tells you which acquisition channel actually pays your MRR — and cookie-based tracking loses 15–30% of conversions before they reach a commission row, quietly corrupting that answer.

For a program paying $2,000/month in commissions, that's up to $600 in monthly attribution errors — half going to the wrong affiliate, half going nowhere at all. The losses are not random.

They cluster around five well-known failure points: Safari ITP, ad blockers, cross-device journeys, cookie expiry against long sales cycles, and redirect chains.

This guide walks the full attribution chain from click to commission, names each failure point with the specific percentage it costs, and shows the server-side pattern that closes the gap to under 2%.

The complete attribution chain, end to end

Affiliate tracking is the chain of events that connects an affiliate's link click to a paid charge and creates a commission row for the right partner. When any one link in that chain breaks, the conversion either vanishes or lands on the wrong affiliate.

Most programs only test the chain end to end when a partner complains — by then the data is months old.

Every working program runs the same six-step sequence. Naming them out loud is the first step to diagnosing where yours is leaking.

• 1. Link click. An affiliate shares a link like https://yourdomain.com/r/jane. A visitor clicks it. The HTTP request hits your redirect endpoint.
• 2. Cookie placement. Your redirect endpoint reads the affiliate ID from the URL and writes a vid (visitor ID) cookie scoped to your apex domain. Server-set, HttpOnly, 90-day expiry.
• 3. Session persistence. The visitor browses your site, opens new tabs, comes back days later. The cookie persists across pages and sessions, binding every subsequent pageview to the original click.
• 4. Signup event. The visitor signs up or starts checkout. Your app reads the vid cookie and binds it to the user record (or passes it to Stripe via client_reference_id).
• 5. Stripe payment. Stripe processes the payment and fires checkout.session.completed or invoice.paid. Your webhook handler receives the event with the embedded visitor ID.
• 6. Commission creation. Your attribution engine looks up the affiliate that owned vid at click time, applies the commission rate, and writes a row to the affiliate's ledger.

Attribution models, compared

Before you can diagnose what's broken, you have to pick which click should get the credit.

Most affiliate programs default to last-click — it matches how Stripe charges happen and is the easiest to reconcile — but programs with long, multi-touch journeys often need something more nuanced.

The same click log answers all three models; you flip the model at reporting time, never re-instrument.

Five failure points that lose real conversions

Each failure below has a measured impact on attribution accuracy. The numbers come from cross-referencing TrackRev's own program data with Apple WebKit's published ITP behavior and the most recent ad-blocker share research.

If your program is losing 15–30% of conversions, the leak is almost certainly some combination of these five.

If your attribution is already broken and you need to isolate which link is leaking, our guide on why affiliate attribution isn't working and how to fix each failure point walks through the diagnosis step by step.

Safari ITP — caps client-set cookies at 7 days

Apple's Intelligent Tracking Prevention (ITP 2.3+) caps any cookie set via JavaScript (document.cookie) at seven days, and shorter under cross-site context. Safari is roughly 25% of global desktop traffic and 55%+ of mobile traffic in Western markets per StatCounter.

If your affiliate program uses a JavaScript pixel to write the vid cookie — which most older platforms still do — every Safari click silently expires within a week.

WebKit went further in 2020, blocking all cross-site cookies by default in Safari 13.1.

For B2B SaaS with a 30-day evaluation cycle, that means every Safari visitor who takes more than seven days to convert is attributed to "direct." The fix is to set the cookie server-side via an HTTP Set-Cookie response header from your redirect endpoint, not via JavaScript.

As MDN's cookie documentation notes, a server-set first-party cookie carries its own Max-Age and is not subject to the JavaScript-cookie cap, so it persists for the full window you specify.

HTTP/1.1 302 Found
Location: https://yourdomain.com/?utm_source=jane
Set-Cookie: vid=v_8f3a2b1c; Domain=.yourdomain.com; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=7776000

Ad blockers — block third-party scripts and known affiliate domains

uBlock Origin, AdBlock Plus, Brave Shields, and the built-in blockers in Firefox and Edge collectively block third-party tracking scripts on 30–40% of US/European desktop traffic.

The number climbs to 50%+ for developer-heavy audiences and SaaS buyers — exactly the audiences most affiliate programs target. If your affiliate redirect lives on tracking.affiliateplatform.com, the blocker either kills the redirect or strips the cookie.

The fix is to host the redirect endpoint on your own apex domain (or a subdomain of it). A request to yourdomain.com/r/jane looks like first-party navigation, not third-party tracking, and slips past every blocker.

This is why platforms that force you onto a shared refer.app/x domain underperform on every metric that matters.

Cross-device journeys — clicks on mobile, converts on desktop

Roughly 35% of SaaS buyer journeys start on mobile and finish on desktop, especially for higher-priced B2B products where the buyer wants a real keyboard before committing a credit card.

Cookies are device-scoped: a cookie set on the buyer's phone is invisible to their laptop. Without a deterministic bridge, the desktop conversion is attributed to "direct."

The fix is identity-based stitching. When the buyer signs up, you bind the current vid to the user's email. When the same email later signs in on desktop, you re-attach the user's earlier visitor history.

TrackRev does this automatically; if you are rolling your own, the join key has to be something the user explicitly enters on both devices (email at sign-up is the only reliable choice).

Cookie expiry vs long sales cycles

The default cookie window across affiliate platforms is 30 days. The default B2B SaaS evaluation cycle is 45–60 days, longer for products over $500/month.

The math does not work: a buyer who clicked an affiliate link on day 1 and converted on day 47 has already lost the attribution, even if every other part of the chain is intact.

The fix is to set the cookie Max-Age to match your actual buying cycle. Pull your last 100 paid customers and compute the 90th percentile of click-to-charge time. If 90% of conversions happen within 62 days, set Max-Age=7776000 (90 days).

For a long-cycle B2B product, 120 days is reasonable. The cookie costs you nothing to keep alive; the conversions you lose to a too-short window cost you real commission rows.

Redirect chains — each hop loses context

Many affiliate platforms route clicks through multiple servers: affiliate platform → link shortener → tracking domain → your site.

Each hop loses 10–15% of attribution context — either to a 3xx redirect dropping the referrer header, a UTM-stripping cleaner in the middle, or a corporate proxy that follows the chain in a way browsers don't.

The fix is one redirect, on your own domain, ever. The browser hits yourdomain.com/r/jane, your server reads the affiliate ID, writes the cookie, and 302s straight to the landing page. No middlemen.

This is the single highest-leverage change most programs can make: dropping from a three-hop chain to one hop typically recovers 8–12% of conversions on its own.

Conversion loss, summed up

The table below quantifies each leak and names the specific fix. Use it as a checklist when diagnosing a program that suspects it's losing attribution — not all five will apply, but the ones that do almost always stack.

Why server-side tracking closes the gap

Server-side tracking is not a single technique — it's a posture that moves three things from the browser to your own infrastructure.

The redirect runs on your server, on your apex domain, where it can read the affiliate ID and respond with a real HTTP Set-Cookie header.

The cookie is first-party — set by your domain on your domain, not by an analytics vendor — so ITP treats it as legitimate and ad blockers leave it alone.

The conversion event is a server-to-server postback — Stripe fires a webhook to your endpoint, your endpoint reads the vid from the customer's metadata, and the commission row is created without ever touching the buyer's browser at conversion time.

Put together, this is the difference between a tracking chain with five points of browser-side failure and a chain with zero. The browser is now responsible for exactly one job: showing the buyer the page.

Every attribution decision happens on infrastructure you control.

1// On the checkout endpoint — read vid from the request cookie2const vid = req.cookies.vid;3 4const session = await stripe.checkout.sessions.create({5  mode: 'subscription',6  line_items: [{ price: 'price_XXXX', quantity: 1 }],7  client_reference_id: vid,                // exact join key, not email8  metadata: { vid, source: 'organic' },9  success_url: 'https://yourdomain.com/success',10  cancel_url: 'https://yourdomain.com/pricing',11});

10-point diagnostic checklist

Run this checklist against your current program. Any item that fails is a leak — and almost every leak maps to one of the five failure points above.

The whole checklist should take under 30 minutes if you have access to a fresh browser, your affiliate platform, and your Stripe dashboard.

• 1. Click your own affiliate link in a fresh Safari window. Open DevTools → Application → Cookies. Is the vid cookie set on .yourdomain.com with Max-Age longer than 7 days? If not — ITP is silently expiring it.
• 2. Repeat the test with uBlock Origin enabled. Does the cookie still appear? If not — your redirect is on a domain ad blockers know.
• 3. Click your affiliate link on your phone, then switch to your laptop and sign up with the same email. Does the conversion attribute back to the affiliate? If not — there is no cross-device stitching.
• 4. Check the redirect chain: curl -I https://yourdomain.com/r/test. How many 3xx hops before you reach the landing page? More than one — every extra hop is bleeding attribution.
• 5. Inspect your Stripe Checkout creation code. Is client_reference_id or metadata.vid being passed? If not — you're falling back to email join, which fails on every multi-email buyer.
• 6. Make a real test purchase. Within 60 seconds, does the commission row appear in your affiliate's dashboard? If not — the webhook isn't firing or isn't matching.
• 7. Refund the test purchase. Does the commission flip to a reversed state within the next sync? If not — you're paying out on refunded charges.
• 8. Open your affiliate platform and run a click for an affiliate you don't pay. Does the click still log even without a payout rate? It should — click logs are diagnostic data.
• 9. Pull your last 100 paid customers and compute the 90th-percentile click-to-charge time. Is your cookie Max-Age at least that long? If not — long-cycle buyers are silently dropping.
• 10. Spot-check one Safari conversion from the last 30 days. Is the affiliate ID present on the user record? If not — that conversion was probably attributed to direct.

What to do if tracking is broken

If three or more items on the checklist fail, your program is losing 15%+ of attribution. The remediation order matters — fix the cheapest, highest-impact issues first, then escalate.

Step 1 — move the redirect to your own domain

Stand up a redirect endpoint on yourdomain.com/r/:affiliateId. It reads the ID, writes the cookie, and 302s to the landing page. This single change typically recovers 5–12% of conversions because it kills the ad-blocker and redirect-chain failure modes at once.

Most affiliate platforms — including TrackRev — set this up via a CNAME and a one-line config; it takes under an hour.

Step 2 — switch to server-set cookies

If your platform still writes cookies via JavaScript, push it to write them server-side instead. The Set-Cookie response header from your redirect endpoint should look like the snippet above: HttpOnly, Secure, SameSite=Lax, and a Max-Age matching your sales cycle.

This step alone recovers 8–15% of Safari conversions.

Step 3 — pass the visitor ID to Stripe

Update your Checkout creation code to pass client_reference_id: vid and/or metadata: { vid }. The webhook handler reads this back from checkout.session.completed and does an exact ID join rather than an email join.

The change is roughly 5 lines of code on your checkout endpoint and 10 on your webhook handler; see our guide to connecting Stripe revenue to channels for the full pattern.

Step 4 — add identity stitching at signup

When a user signs up, bind vid to the user record. When the same user signs in from another device, re-attach all earlier visitor history under their account.

This kills the cross-device failure mode and is the only fix that addresses mobile-to-desktop journeys. TrackRev handles this automatically; rolling your own requires a join on the signup email and a small migration script.

Tracking reliability as a program health metric

Most programs treat tracking as a one-time setup task — wire it once, never look at it again.

The programs that grow treat tracking reliability as a metric they monitor monthly: what percentage of paid charges in the last 30 days have a vid on them?

In a healthy program, that number is 95%+ and climbing as you fix leaks; in a leaking program, it's 70–80% and getting worse as Safari share grows and ad blockers tighten.

If you want a starting point, run the 10-point checklist above quarterly and treat any backslide as a P1 issue.

Affiliate trust compounds — and so does the loss of trust from one missed payout that the affiliate has receipts for and you don't. The cheapest way to keep paying affiliates fairly is to track them correctly in the first place.

How TrackRev handles this

TrackRev was built server-side from the first commit. Affiliate redirects run on your own apex domain via a single CNAME — go.yourdomain.com or the bare apex with a subpath.

The vid cookie is server-set with a 90-day default, configurable to your sales cycle. Identity stitching on signup email is automatic. Stripe events are matched via client_reference_id when available, with an email-join fallback.

Refunded charges flip commissions to reversed state without manual intervention.

If you want to see the difference on your own program before committing, the free tier covers up to 1,000 events a month — enough to side-by-side a leaking pixel-based platform against the server-side default for a full month.

Related reading: our server-side vs client-side comparison, the iOS 17/18 link-protection guide, and the deeper dive on Stripe revenue attribution. Once tracking is reliable, the next problem is paying affiliates correctly — see how to pay affiliates for the payout side.

External references: Apple WebKit ITP 2.3 specification; Stripe Checkout client_reference_id documentation; Google Privacy Sandbox on the phase-out of third-party cookies; MDN Web Docs: Using HTTP cookies; Impact.com 2025 partnership benchmarks on tracking accuracy by methodology.