Affiliate Tracking: Four Ways a Sale Gets Credited, and What Each One Misses

Four mechanisms can credit a sale to a partner, and only one keeps your customer's browser out of it. See what each one survives, and what it costs.

Freya CollinsCreator Economy StrategistSeptember 16, 2026 · 14 min read
Share
/ On this page9 sections

Your program is running one method to connect a click to a sale, and when that method fails something else has to decide who gets paid. Which one is doing the work decides what you can trust in your own reports.

The four mechanisms below are not a menu to pick from. They sit at different links of the chain, one of them reads another, and only one of them keeps the customer's browser out of the report.

This is what each one catches, what it misses, and what the gap costs you.

The Chain That Has to Hold, From Click to Payment

Affiliate tracking is the chain that ties one click to one sale so the right partner gets paid. It has three links, and each one can break on its own.

A partner shares a link that carries an identifier. Something records that click. Something at the point of sale reads the record back and attaches the order to the partner.

Break the first and nobody is credited. Break the second and the click happened to an anonymous visitor. Break the third and the sale completes with the record sitting there unread.

Almost every argument about affiliate tracking is an argument about that middle link. It is the one the browser gets a vote in, and the one you have least visibility into.

The people building programs know this. The channel's own trade body, writing to the UK's data regulator in 2024, described what a network stores as a sale identifier, an internet protocol (IP) address and a sale amount.

Three fields. The middle one is the only thing tying a click to a person.

The Four Things That Can Record the Sale

Four mechanisms can carry the middle and the end of the chain. The first two run inside the customer's browser, and the second two are the ways around it.

Your program is running one or more of these right now. When the one carrying a sale has nothing to say, the credit does not pass to the next one on this list, it falls to a guess.

The Cookie Set on the Click

A cookie is a small record written into the customer's browser when they click the link. It holds the partner's identifier and the time. When the customer reaches the confirmation page, something reads it back.

This is still the most common primary, and it is the most fragile thing in the chain. It lives on a device you do not own, in software whose rules change without telling you.

It fails in ordinary ways rather than exotic ones. The customer clears their cookies, blocks them, switches from a phone to a laptop, or runs an ad blocker. None of that is unusual behavior.

Which Cookie, and Why the Difference Decides Everything

A third-party cookie is set by a domain other than the one in the address bar. A first-party cookie is set by the site the customer is on.

Browsers have been dismantling the first category for years and have left the second largely alone.

The affiliate channel is on the second one.

The Affiliate & Partner Marketing Association told the UK regulator in 2024 that affiliate marketing relies on first-party tracking cookies, unlike the programmatic display industry, and asked the regulator to confirm whether they should count as measurement cookies rather than advertising ones. That question is still open.

Third-party cookie deprecation is therefore not the risk it is usually sold as, because it is not the mechanism most affiliate programs are running on.

What will is quieter. A first-party record still sits in a browser, and a browser can cap how long it keeps it, clear it early, or never write it because a privacy tool intervened.

And a surprising number of programs cannot say which they are on.

The Interactive Advertising Bureau's affiliate and partnership working group in Australia surveyed advertisers and agencies for its 2023 guide: 20% believed they were reliant on third-party cookies, and 29% said they did not know how their own affiliate program was tracked.

Half the room is either on the wrong mechanism or unable to name the one they have.

The Tag on the Confirmation Page

A tag is a snippet on the order confirmation page that fires when the page loads, reads the stored identifier, and reports the sale back to the platform. It is often called a pixel, because the original version was a one-pixel image request.

This is the sale end of the chain, and it is where most implementations live. It does not replace the cookie. It reads it.

That is the limitation people miss: a tag is only as good as the record it is reading, so it inherits every weakness of the storage method underneath it.

It has one of its own. The tag runs in the browser, so an ad blocker that catches the request means a completed sale that reports nothing, and the customer sees their receipt exactly as normal.

The Call Between Two Servers

A server-to-server call is your server telling the platform's server, directly, that an order happened and which partner it belongs to. No browser is involved at any point.

It is also called a postback or S2S, and it is the only one here whose reporting cannot be interfered with. Nothing the customer's device does can reach a conversation it is not part of.

It is worth being exact about what that fixes. A server call replaces the browser at the sale end, and the identifier it reports still has to have been captured on the click, which in most setups is a first-party cookie or a click identifier your own server holds onto.

Affise, which sells this kind of tracking, puts the reason plainly: the method carries click IDs, "making it immune to browser privacy restrictions, ad blockers, and ITP updates."

ITP is Apple's Intelligent Tracking Prevention, the Safari feature that restricts what a site can store. The summary holds for every platform's version of the method, not theirs alone.

We think this is the decision, and we would not spend long on it. If your program can run the sale end server to server, run it there, and treat everything in the browser as a convenience rather than the record.

The cost is real, and it is worth stating plainly: a server call needs somebody who can change what your checkout does once an order completes, which is a developer task rather than a settings toggle.

That is the whole objection. It is real on a small team, and it is paid once.

The Code With No Click Behind It

Some sales have no click to record. A creator says a code on a podcast, a partner hands out a card at an event, and the customer types the code at checkout days later.

A code-based match skips the middle of the chain entirely. There is no stored record to read, because the customer identified the partner themselves by typing it.

It is the hardest of the four to break, for the obvious reason: nothing in the customer's browser is being asked to remember anything. It is also the least informative, because you learn who sent the sale and nothing about the journey.

One setup detail decides whether it works, and it catches people. A discount code created in your store's own backend is only a discount.

Refersion makes the point in its guide to tracking methods: the code has to be designated as a tracking method inside the affiliate platform, or the sale is never credited to anybody.

Two other clickless routes are worth knowing: a platform can match on the customer's email address at checkout, or attach a specific product code to a partner so any purchase of that item is credited.

Two horizontal orange bars on a zero to one hundred percent scale show what advertisers and agencies said about their own affiliate tracking. The first bar reaches 20% and is marked believed they were reliant on third-party cookies. The second reaches 29% and is marked said they did not know how their own affiliate program was tracked. The axis below them is labeled percent of surveyed advertisers and agencies, 2023. A quoted panel underneath reports what the channel's own trade body told the UK regulator in 2024, that affiliate marketing relies on first-party tracking cookies, unlike the programmatic display industry. A closing line states that the risk that is left is quieter, because a first-party record still sits in a browser, and a browser can cap how long it keeps it, clear it early, or never write it because a privacy tool intervened.
Neeraj Jivnani · Survey figures from the Interactive Advertising Bureau affiliate and partnership working group in Australia, advertisers and agencies surveyed for its 2023 guide. The trade body statement is from the Affiliate and Partner Marketing Association's 2024 submission to the UK regulator. Reading the two survey answers together is our own
Use this chart — embed code and citation
Embed on your site
<a href="https://neerajjivnani.com/blog/affiliate-tracking/"><img src="https://neerajjivnani.com/infographics/affiliate-tracking/half-the-room.png" alt="Two horizontal orange bars on a zero to one hundred percent scale show what advertisers and agencies said about their own affiliate tracking. The first bar reaches 20% and is marked believed they were reliant on third-party cookies. The second reaches 29% and is marked said they did not know how their own affiliate program was tracked. The axis below them is labeled percent of surveyed advertisers and agencies, 2023. A quoted panel underneath reports what the channel's own trade body told the UK regulator in 2024, that affiliate marketing relies on first-party tracking cookies, unlike the programmatic display industry. A closing line states that the risk that is left is quieter, because a first-party record still sits in a browser, and a browser can cap how long it keeps it, clear it early, or never write it because a privacy tool intervened." width="1200"></a> <p>Chart: <a href="https://neerajjivnani.com/blog/affiliate-tracking/">Neeraj Jivnani</a></p>
Cite it
Neeraj Jivnani, "Affiliate Tracking: Four Ways a Sale Gets Credited, and What Each One Misses", neerajjivnani.com, https://neerajjivnani.com/blog/affiliate-tracking/

Free to republish with a link back to this page.

A four-row reference table headed only one of the four reports the sale without the customer's browser sets out the four mechanisms that can record an affiliate sale, notes that they sit at different links of the chain and that one of them reads another, and adds that even the strongest of them still needs the click to have been recorded somewhere first. Its columns are where each one lives, what it needs to survive and what stops it. The cookie set on the click lives in the customer's browser, needs a record written on the click that is still there at the sale, and is stopped when the customer clears their cookies, blocks them, switches from a phone to a laptop, or runs an ad blocker. The tag on the confirmation page also lives in the customer's browser, needs the stored record underneath it and a request that gets through because it does not replace the cookie but reads it, and is stopped by an ad blocker catching the request or by a checkout on a different domain from the one that was tagged. The call between two servers, highlighted in orange as the exception and described as a developer task rather than a settings toggle, lives between your server and the platform's, and needs the identifier it reports to have been captured on the click, which in most setups is a first-party cookie or a click identifier your own server holds onto. What it cannot rescue is a record that was never written, because the thing that went missing is the record the sale end would have read, though nothing the customer's device does can reach a conversation it is not part of. The code with no click behind it is typed by the customer, needs nothing remembered because it is the one mechanism that never needed a record, and is stopped when a code created in your store's own backend is never designated as a tracking method inside the affiliate platform. A closing line says that if your program can run the sale end server to server, run it there, and treat everything in the browser as a convenience rather than the record.
Neeraj Jivnani · Our own reading of the four mechanisms and where each one sits in the chain. No survey and no sample: it describes how each method works, not how often each one fails
Use this chart — embed code and citation
Embed on your site
<a href="https://neerajjivnani.com/blog/affiliate-tracking/"><img src="https://neerajjivnani.com/infographics/affiliate-tracking/only-one-leaves-the-browser.png" alt="A four-row reference table headed only one of the four reports the sale without the customer's browser sets out the four mechanisms that can record an affiliate sale, notes that they sit at different links of the chain and that one of them reads another, and adds that even the strongest of them still needs the click to have been recorded somewhere first. Its columns are where each one lives, what it needs to survive and what stops it. The cookie set on the click lives in the customer's browser, needs a record written on the click that is still there at the sale, and is stopped when the customer clears their cookies, blocks them, switches from a phone to a laptop, or runs an ad blocker. The tag on the confirmation page also lives in the customer's browser, needs the stored record underneath it and a request that gets through because it does not replace the cookie but reads it, and is stopped by an ad blocker catching the request or by a checkout on a different domain from the one that was tagged. The call between two servers, highlighted in orange as the exception and described as a developer task rather than a settings toggle, lives between your server and the platform's, and needs the identifier it reports to have been captured on the click, which in most setups is a first-party cookie or a click identifier your own server holds onto. What it cannot rescue is a record that was never written, because the thing that went missing is the record the sale end would have read, though nothing the customer's device does can reach a conversation it is not part of. The code with no click behind it is typed by the customer, needs nothing remembered because it is the one mechanism that never needed a record, and is stopped when a code created in your store's own backend is never designated as a tracking method inside the affiliate platform. A closing line says that if your program can run the sale end server to server, run it there, and treat everything in the browser as a convenience rather than the record." width="1200"></a> <p>Chart: <a href="https://neerajjivnani.com/blog/affiliate-tracking/">Neeraj Jivnani</a></p>
Cite it
Neeraj Jivnani, "Affiliate Tracking: Four Ways a Sale Gets Credited, and What Each One Misses", neerajjivnani.com, https://neerajjivnani.com/blog/affiliate-tracking/

Free to republish with a link back to this page.

The Fallbacks, and What They Are Guessing

When the primary mechanism has nothing to say, platforms commonly fall back to guessing who the visitor probably was. You end up paying a commission on that guess, which is worth understanding before it is a line in your accounts.

A fingerprint match is the common one. The platform assembles a signature from the signals a browser exposes anyway, things like the operating system and version, the screen resolution, the language and the graphics hardware, and looks for the same signature at the sale.

That sounds precise. Precision is not the same as certainty.

Session matching is the weaker sibling. It credits a sale within the same browsing session as the click, which works right up until the customer closes the tab and comes back tomorrow.

What a Fingerprint Is Claiming

A fallback is not a worse version of a cookie. It is a different kind of claim altogether.

A cookie says this browser was told to remember partner 8634127. A fingerprint says a visitor who looks statistically similar to that one bought something, and we think it is the same person.

You are paying a real commission on an inference. That is sometimes the right trade, because the alternative is paying nobody for a sale a partner genuinely drove.

What makes it a problem is not knowing it is happening.

A program running heavily on fallbacks looks identical in the dashboard to one running cleanly, and the number you report upward has quietly changed meaning.

Ask your platform what share of your conversions are matched by a fallback.

It is a number they have and one they rarely volunteer.

One sale, through the mechanisms your program actually has

Tick what your program runs, then name one ordinary thing that happened to one customer. Nothing is scored and no share is worked out here. The question is only which of your own mechanisms has anything to say about this sale.

What your program runs

What happened to this customer

The cookie set on the click

It reports the sale

The record was written on the click, and it holds the partner's identifier and the time.

The tag on the confirmation page

It reports the sale

It fires on the confirmation page, reads the stored identifier, and reports the sale back to the platform.

It does not replace the cookie. It reads it.

The call between two servers

Your program does not run this

Your server telling the platform's server, directly, that an order happened and which partner it belongs to.

The code with no click behind it

Your program does not run this

The customer types a code at checkout, so there is no stored record to read.

Underneath all four, what platforms commonly reach for

When the primary mechanism has nothing to say, platforms commonly fall back to guessing who the visitor probably was.

  • A fingerprint match looks for the same signature at the sale, and says a visitor who looks statistically similar to that one bought something, and we think it is the same person.
  • Session matching credits a sale within the same browsing session as the click, which works right up until the customer closes the tab and comes back tomorrow.

What is paying this commission

A record, read back at the sale. This sale is credited by the cookie set on the click and the tag on the confirmation page, and nothing here is being guessed.

Change one thing about the customer and watch how much of that survives. When the one carrying a sale has nothing to say, the credit falls to a guess.

Who Gets Paid When Two Partners Touch One Order

Which partner gets paid is decided by a written rule, not by the order of events.

Say a reader finds a running-shoe review in March, leaves, and comes back in April through a cashback site. Two partners touched that order and one commission is available.

The industry default is last click.

The partner whose link was clicked most recently before the purchase takes the commission, and everybody earlier in the journey takes nothing.

It is the default because it is simple to compute and impossible to argue with, not because it is fair. The review that created the demand and the coupon site that captured the intent are both real contributions, and only one is paid.

Other models exist and platforms will implement them. First click pays the partner who introduced the customer, and linear splits the commission across everybody who touched it.

Time decay weights toward the end of the journey without zeroing the start, and position-based pays the first and last click most.

Impact's guide lists a sixth, algorithmic attribution, which uses machine learning to assign credit across touchpoints rather than following a fixed rule.

What Your Own Program Document Says

The default is not the rule that binds you or your partners. The rule that binds is the one in your own program document, and programs differ.

Loopy Loyalty's affiliate policies, a live program document, state that where a customer clicks multiple affiliate links, the first eligible link clicked during the cookie window receives attribution.

First, not last, and written plainly in the terms.

The same document runs a 45-day window and lists exactly what will stop a referral qualifying, including a customer who clears cookies, changes device or signs up through an unsupported regional domain.

That is what a good program document looks like.

If yours cannot answer the two-partner question in writing, that is the gap to close before you change anything technical.

Where the Chain Breaks

Tracking breaks in a small number of ordinary ways, and none of them announce themselves. The sale still completes, the customer is still happy, and the report is short.

Grouping them by which link fails is what makes the list usable, because the link decides who can fix it.

The click never carried the identifier. A partner posted a plain product URL instead of their link, or an intermediate redirect dropped the parameter on the way through. This is the partner's half and it is the easiest to audit.

The record was never written, or did not survive. Cookies blocked, cleared or capped, a privacy extension in the way, or a customer who researched on a phone and bought on a laptop. This is the browser's half and you cannot fix it, only route around it.

The sale end never reported. An ad blocker caught the tag, or the checkout that completes the order is on a different domain from the one that was tagged.

Somebody gamed it. Cookie stuffing and its relatives are why platforms run fraud checks on conversions at all, and the reason they bite here is that a faked record and a real one look identical at the moment the sale reads it back. The symptom on your side is a partner converting far better than anybody else for no reason you can name, which deserves an afternoon rather than a celebration.

The Group You Cannot Fix, Only Route Around

The second group is the uncomfortable one. It is nobody's fault, and moving the sale end off the browser does not rescue it, because the thing that went missing is the record the sale end would have read.

The only mechanism that survives this group is the one that never needed a record. A code the customer types arrives with the partner's name attached.

The Numbers That Tell You It Is Working

You do not need a metrics framework here, only the three numbers that say whether the chain is holding and the one comparison that says when it is not.

Clicks tell you the link is being shared and used. Conversions tell you the sale end is reporting. The rate between them is the one to watch over time.

The comparison that matters is your affiliate conversion rate against your site's overall conversion rate.

Affiliate traffic usually converts better, because somebody already recommended you.

When that flips, tracking is the first thing to check and not the last.

A partner sending real buyers whose sales go unreported looks exactly like a partner sending bad traffic, and the two have opposite remedies.

Watch it per partner rather than in aggregate. A single partner whose clicks hold steady while their conversions fall off is usually a broken implementation on one placement, not a change of heart.

Questions People Ask About Affiliate Tracking

Four questions come up more than the rest.

What is affiliate tracking? It is how a purchase gets attached to the partner who sent the buyer: their link carries an identifier, something stores it when the visitor arrives, and something at the checkout reads it back and credits them.

What is the best affiliate tracking software? Nobody can answer that for you and a ranked list would age before you finished reading it. Three questions decide it: does it report conversions without relying on the browser, does it integrate with your checkout without custom work, and can you configure the attribution rule you want. A platform that answers yes three times is the right one for you.

Can you make $10,000 a month with affiliate marketing? Some publishers do. That is a question about the size of an audience and the rate card, not about tracking, and tracking only decides whether you are paid for what you already earned.

Is affiliate marketing real or fake? It is one of the most established channels online. The trade body's 2024 submission to the UK regulator cites Similarweb for the scale of it: 47 of the UK's top 50 retail sites run affiliate programs.

The Part of the Chain You Own

Most of this chain is not yours.

You do not control what a browser keeps, what a customer clears, or which device they finish on.

Two things you own outright: which mechanism carries the sale end, and what your program document says when two partners touch one order.

Both are decisions rather than settings, and both are usually made by default.

Moving the sale end off the browser is the one that changes what your numbers mean, and writing the attribution rule down is the one that changes what your partners believe about you.

Everything else is the cost of doing business with somebody else's browser.