An affiliate program pays a partner for a sale the partner is not present to witness. The creator posts a link. Three days later, on a different device, in a different browser session, someone buys. A commission is owed. Nobody at the merchant watched it happen, and the creator has no way to prove it did.
The entire channel runs on solving that one problem: building a chain of evidence that connects a click to a purchase reliably enough that real money changes hands on the strength of it. For most of affiliate marketing's history that chain was a single cookie, and for the last few years that cookie has been quietly snapping. What replaced it is not a patch but a different way of recording the sale, and understanding it explains almost every argument in the channel right now, from disputed commissions to the Honey scandal to why brands keep talking about server-side.
Origin: the cookie was never built for this
The cookie was invented in June 1994 by Lou Montulli, an engineer at Netscape, to solve a narrow problem: the web had no memory. Every page request arrived as if the visitor had never been there before, which made a shopping cart impossible. Montulli's fix was a small text file the browser would store and hand back to the site on the next visit, so the site could recognise a returning session. He was explicit later that it was meant to help a single site remember its own visitors, not to follow people around the web.
Affiliate marketing borrowed the cookie because the timing lined up. When Amazon opened its Associates program in July 1996 and the model went mainstream, every merchant faced the same evidence problem, and the cookie was the only browser feature that could hold information across a gap in time. So that is what it carried. Click an affiliate link, and the merchant's system would drop a cookie holding the affiliate's ID, a timestamp, and an expiry date. Buy something before the cookie expired, and the merchant read the ID off the cookie and credited the sale.
That worked, with one structural weakness almost nobody questioned for two decades. The cookie that did the heavy lifting was usually a third-party cookie: the affiliate network's tracking domain differed from the merchant's, so the cookie belonged to the network, not the shop the visitor was looking at. The whole channel's accounting sat on a file the browser was under no obligation to keep, set by a domain the visitor never chose to deal with. For a long time that was fine, because browsers kept those cookies by default. The day they stopped, affiliate measurement broke, and it broke before most marketers noticed.
Present: the chain of evidence, one link at a time
To see why server-side tracking became the reliable method, you have to see the chain it replaced. Modern affiliate tracking has four parts.
The tracked click and the click ID. When someone clicks an affiliate link, they do not go straight to the product. They pass through the network's tracking server first. That server does one important thing in the few milliseconds it holds the visitor: it generates a click ID, a unique alphanumeric string that stands for this specific click by this specific affiliate. The ID is the spine of the whole system. Everything that follows is an attempt to carry that ID forward to the moment of purchase and read it back. The server logs the click, attaches the ID, and forwards the visitor to the merchant, often with the ID written into the destination URL as a parameter, something like ?click_id=a1b2c3. Google's version of this idea, the gclid, and Facebook's fbclid work on the same principle. The ID is the receipt number for a transaction that has not happened yet.
The cookie. Once the visitor lands on the merchant's site, the click ID needs somewhere to wait, because the purchase might be minutes or days away. Historically it waited in a cookie. The merchant's page, or a network script on it, read the ID from the URL and stored it. This is the link in the chain that decayed, so be precise about which cookie does what. A first-party cookie is set by the domain the visitor is actually on, the merchant's own site. A third-party cookie is set by some other domain, classically the affiliate network's. Affiliate tracking has leaned on both, and both are now unreliable, for different reasons covered below.
The conversion pixel. When the visitor finally buys, the merchant's confirmation page carries a piece of tracking code called a conversion pixel. Classically this was a 1x1 transparent image. By trying to load that invisible image from the network's server, the browser sends a request, and that request is the conversion signal. It carries the order value and, crucially, the click ID that was waiting in the cookie. The network receives the pixel fire, matches the click ID against its log of clicks, finds the affiliate who owns it, and records a commission. That is the full classic loop: tracked click writes the ID, cookie holds the ID, pixel returns the ID, network matches and pays.
Every link in that chain runs inside the visitor's browser. That is the flaw. The browser is not a neutral courier any more. It can refuse to carry the message, and three forces turned it hostile.
The first is browser tracking prevention. From 2019, Apple's Intelligent Tracking Prevention capped cookies set by JavaScript at a seven-day life. For affiliate programs this is a direct hit, because the cookie holding the click ID is typically set by JavaScript, so a conversion on day eight has nothing to read and the affiliate goes unpaid. A later version, ITP 2.2, cut that window to 24 hours when the visitor arrived from a link carrying tracking parameters, which is exactly what an affiliate link is. Safari also blocks third-party cookies outright, so the network-owned cookie was already dead there. impact.com warned partners that ITP 2.2 would shrink the conversion window for a large slice of traffic.
The second is ad blockers and privacy extensions. These do not shorten the cookie's life, they delete the pixel. A blocker recognises the request to a known affiliate or analytics domain and stops it before it leaves the browser. Independent measurement puts desktop ad blocker use around 37 percent globally, higher among the technical, younger audiences many affiliate programs court. For that slice of buyers, the conversion pixel never fires at all.
The third is network-level blocking: corporate firewalls and privacy-focused DNS resolvers that filter tracking domains for an entire network. The visitor installed nothing. Their office or router made the choice, and the pixel dies in transit.
Stack the three together and cookie-and-pixel tracking is no longer a reliable narrator. It undercounts, it loses conversions that genuinely happened, and the loss is invisible: a missing pixel fire looks exactly like a sale that never occurred. The affiliate is not paid, and rarely knows why.
The postback: moving the evidence off the browser
The fix is to stop asking the browser to carry the receipt. This is what server-to-server tracking, also called S2S or postback tracking, does. The shift is simpler than the jargon suggests.
In the postback model, the click ID is still generated at the tracked click. But instead of being parked in a browser cookie and hoping a pixel fires later, the ID is handed to the merchant, who stores it in their own database against the customer's order or account record. It sits server-side, on infrastructure the merchant controls, where no browser setting can touch it.
Then the purchase happens. Instead of the browser loading a pixel, the merchant's own server makes a direct call to the affiliate network's server, a plain HTTP request to a URL the network provides, called the postback URL. That call carries the stored click ID and the conversion details: order value, timestamp, sometimes the conversion type. The network receives it, matches the click ID to its click log, and credits the affiliate. The browser is never involved in the conversion step. TUNE describes the merchant's server simply calling the postback URL to report the transaction back.
That one change fixes all three failure modes at once. An ad blocker cannot strip a request it never sees, because the call happens between two servers. Safari's cookie cap is irrelevant, because the click ID was never in a browser cookie. Network filters that block tracking domains in the browser do not sit on the path between a merchant's server and a network's server. The evidence has moved to a place the browser cannot reach.
A conversion API is the same principle in a more structured form. Instead of a single postback URL fired once, the merchant and platform connect through a defined API that sends richer, validated event data and, importantly, follow-up events. That matters because real conversions are not always instant. A free trial that becomes a paid subscription, an order that is later refunded, a lead that is later disqualified: an API connection can report the final status when it is known, not just the first click of intent. Meta's Conversions API and Google's server-side equivalents brought this into the mainstream of paid media, and affiliate platforms adopted the same pattern. The line between a postback and a conversion API is one of degree, with the API the more capable and more demanding integration.
The numbers explain why the channel moved. Awin, analysing 150,000 tracking calls, found server-to-server tracking captured 12.6 percent more conversions than browser tracking alone, with 9.3 points of that coming from cookie restrictions and 3.3 from content blockers. One 2026 analysis of affiliate programs reports server-side setups recovering 18 to 24 percent more attributed conversions than third-party-cookie-only programs at comparable traffic, and restoring 31 to 44 percent of pre-ITP attribution on Mobile Safari. The same analysis puts server-side or first-party-only tracking at around 21 percent of affiliate programs, up from 5 percent in 2022, with hybrid setups that run both methods at about 48 percent. Most programs do not throw the pixel away. They run pixel and postback together, deduplicate against the shared click ID, and let the server catch what the browser drops.
Future and impact: why the mechanism is the politics
The plumbing is not just plumbing. Almost every live argument in affiliate marketing is an argument about this chain of evidence.
Cookie stuffing, the channel's oldest fraud, exists only because the cookie is so easy to forge. A fraudster loads affiliate cookies onto a visitor's browser with no real click, often through a hidden iframe or a shrunk-to-one-pixel ad, then collects commissions when some of those visitors buy organically. The scam works because the cookie carries no proof of a genuine click. Server-side click logging makes it harder, because the network has its own record of whether a real click occurred.
The Honey scandal is the same point from a different angle. In December 2024 the YouTuber MegaLag published an investigation, "Exposing the Honey Influencer Scam," that has since passed 17 million views. The core allegation was that the Honey browser extension overwrote a creator's affiliate cookie at checkout, so the last cookie standing was Honey's. Under last-click attribution, last cookie wins, and the creator who actually drove the sale lost the commission. Dozens of creator class action suits followed and were consolidated into a single case, In Re PayPal Honey Browser Extension Litigation. That entire dispute is a dispute about a writable cookie and a rule that pays whoever wrote it last. Tracking that anchors a conversion to a logged, server-side click is harder to hijack at the final step.
The honest limits matter too. Server-side tracking recovers signal in transit. It does not rebuild the deterministic, follow-one-person-everywhere certainty that privacy changes ended. A buyer who clicks on a phone and buys on a laptop with no shared login is still two records to a postback as much as to a pixel. It is also not a consent loophole: an IP address and an email are personal data wherever a server processes them, and GDPR governs the data, not the machine that sends it. The reliable method is more reliable, not omniscient.
This is also why the channel is now talking about coupon-based and card-linked tracking, which sidestep the browser entirely by attributing on a unique code entered at checkout or a registered payment card, and why agentic commerce raises a sharper question still. When an AI assistant researches and buys on a person's behalf, the tracked click, the unit this whole system is built on, may not happen in any browser at all. The chain of evidence will have to be rebuilt again, on rails that do not assume a human clicking a link. Merchants and networks that already understand their tracking as a server-side chain are positioned to rebuild it. The ones still equating affiliate tracking with a cookie are measuring a channel with a tool that started failing years ago.
Council summary
This post argues that affiliate marketing is an evidence problem at its core, paying for a sale nobody witnessed, and that its history is one fragile cookie being replaced by a server-side chain. It walks the classic loop, shows the three forces that turned the browser hostile, and explains why postbacks and conversion APIs move the receipt somewhere browsers cannot reach. The council verified every figure: the Awin study, the 1994 cookie origin, the July 1996 Amazon launch, and the 2026 adoption shift from 5 to 21 percent. It corrected an overstated ad blocker number and reframed the Honey claims, the video now sits above 17 million views and the suits were consolidated into one case. The takeaway: treat tracking as a server-side chain, not a cookie, because agentic commerce will test that chain again.
Comments