How Affiliate Link Tracking Actually Works (Cookies, Parameters, and What Breaks)
From click to credited sale: the referral parameter, the first-party cookie, attribution windows, and the five places tracking silently breaks — explained without vendor fog.
Affiliate tracking has a reputation for being mysterious, mostly because vendors explain it in marketing language and partners experience it as a black box. Under the hood it's a short, understandable pipeline: a parameter, a cookie, and a lookup at checkout. Once you can picture the pipeline, every "why didn't this sale track?" question becomes a diagnosis instead of an argument.
Step 1: the parameter arrives
A referral link is your normal URL carrying an identifier — something like yourstore.com/?ref=maya. When the visitor lands, the plugin reads the parameter, records a visit against that partner, and immediately gets the ugly token out of the address bar. The parameter's whole job is done in that first second: it named the referrer.
Step 2: the cookie remembers
The site then sets a cookie in the visitor's browser containing the referrer (signed, so it can't be forged by editing cookie values). This is a first-party cookie — set by your own domain, not an ad network's — which matters enormously in the modern browser landscape: Safari and Firefox throttle third-party cookies aggressively, but first-party cookies set by the site you're actually visiting remain the normal, supported case. Self-hosted tracking gets this property for free, because your store is the first party.
The cookie carries an expiry — the attribution window. A 30-day window means a visitor who clicks today and buys in three weeks still credits the partner; day 31, the trail has expired. Windows are a fairness dial, not a technical constant: set them to match how your customers actually decide.
Step 3: the lookup at checkout
When an order completes, the plugin checks the cookie, finds the partner, and writes a referral: order, partner, base amount, computed commission. If your model is last-click, a newer click overwrote the older cookie; first-click keeps the original. (The attribution-model choice is policy, not plumbing.) A held-for-review state and fraud checks sit between "recorded" and "payable" — but the attribution itself happened in that lookup.
Coupon attribution runs beside all of this as a cookieless second channel: the code typed at checkout names the partner directly, no click required. That redundancy is why programs with creators lean on per-partner codes — spoken codes survive everything cookies can't.
The five places it breaks
Page caching. The most common failure by far: a full-page cache serves HTML before the plugin runs, so the visit never records. Every serious plugin handles the common cache layers, but aggressive host-level caching or an exotic CDN rule can still swallow the landing request. The tell: clicks recorded as visits are missing entirely. The fix: exclude the tracking parameter from caching (your plugin's docs will name the rule — ours does).
Cookie clearing and private windows. A visitor who clears cookies, switches from incognito, or lets the window expire arrives at checkout anonymous. Nothing recovers this except the coupon channel — which is exactly why it exists.
Cross-device journeys. Click on a phone, buy on a laptop: the cookie lives on the phone. Again the honest mitigations are longer windows and coupon codes, not vendor magic. Any product promising perfect cross-device attribution without accounts is describing fingerprinting — with the privacy problems that implies.
Redirect strippers. Link shorteners, some email-client link wrappers, and a few social apps mangle query parameters. Partners should test their own links once after placing them; a link that lands without its parameter is a partner working for free.
Consent gates. If your store gates non-essential cookies behind consent (as EU-facing stores often must), tracking honors the gate — a visitor who declines simply isn't tracked. That's not breakage; that's the system working as designed. Configurable consent integration is the difference between compliant tracking and hopeful tracking.
What "server-side tracking" really means
You'll see the phrase used as a premium feature. Demystified: the meaningful parts are that the decision (which partner, what commission) happens in your server code rather than in browser JavaScript, and that order attribution runs on the order event, not a pixel. Self-hosted plugins are structurally server-side already — the cookie is set and read by your own PHP, the referral is written at checkout by your own database. There is no external pixel to block.
That, ultimately, is the argument for keeping tracking on your own infrastructure: fewer moving parts owned by other people. The pipeline is short. Own all of it, and the black box turns into three inspectable steps — parameter, cookie, lookup — plus a held-referral queue that explains itself.