Paying Affiliates for Traffic They Did Not Bring: Attribution and Abuse

Paying Affiliates for Traffic They Did Not Bring: Attribution and Abuse

In short. An affiliate programme loses money in two ways that look identical in the dashboard. One is abuse - a partner claiming sales they had no part in. The other is an attribution policy that never decided who gets credit, so honest partners are paid twice for one customer. The second is more common and costs more, because nobody is doing anything wrong. Below: the policy that has to exist before the first payout, the signals worth acting on, and why automatic bans cost more than the abuse they prevent.

This page is about running a programme. For building one, see how to build and launch an affiliate platform; for choosing between commission models, see RevShare vs PPS with the numbers.

The question nobody answers until it costs money

A customer arrives through partner A on Monday, leaves, returns through partner B on Thursday and pays. Who earned the commission? Every possible answer is defensible, and the programme must pick one before the first payout, because changing it afterwards means telling partners their earnings were recalculated.

⚠ The last row is where most programmes actually live. Not a decision, an accident of implementation - and it stays invisible until a partner asks why a sale they clearly influenced went elsewhere.

Whatever is chosen, three things must be written down and visible to partners: the attribution window, what happens on a tie, and what a refund does to a commission already accrued.

Signals worth looking at

None of these proves anything on its own. They are reasons to look, not reasons to act.

• Conversion far above the programme average. The most common honest explanation is a genuinely well-matched audience; the common dishonest one is traffic that was never theirs.
• Sales with no measurable engagement before them. A purchase with no browsing preceding it is unusual in this category, where people look before they pay.
• Refund rate far above average. Costs twice - the refund and the dispute fee - and is the signal most directly tied to money.
• Arrivals clustered in a way real audiences are not. Same referrer, same timing pattern, no variation across days.
• Sales that begin immediately at full volume. Real traffic sources ramp.

⚠ On privacy: device fingerprinting is one of the signals that gets recommended here, and for European traffic it engages data-protection and e-privacy obligations. It belongs in the conversation as one input, with that caveat attached, not as routine practice.

Why automatic bans cost more than the abuse

The instinct is to suspend on a threshold. In a programme of any size that is more expensive than what it prevents, for a simple reason: a wrongly suspended honest partner does not come back, and does not stay quiet about it. Affiliates talk to each other, and a programme with a reputation for arbitrary suspensions stops attracting the partners worth having.

What works better, in order:

1. Hold, do not ban. Pause the payout, not the account, and say why.
2. Ask. Most anomalies have dull explanations, and the answer arrives within a day.
3. Size the hold to the measured risk - the disputed portion, not the whole balance.
4. Decide on a stated timetable, so a hold cannot become indefinite by neglect.

Holds and clawbacks, stated so they can be applied

A commission accrues before the revenue is safe: refunds and disputes arrive later. Some hold is therefore reasonable, and the usual mistake is making it unusable in the other direction.

Hold ≈ recent refund and dispute rate × commission accrued in the period
Release on a fixed schedule, published in advance

⚠ What does not work is holding a payout "until the chargeback window closes". That window runs many months; a payout deferred that long is a payout that never happens, and partners of any quality will not accept it. The hold must be proportional to measured risk and released on a date, not on the disappearance of all possible risk.

The same applies in reverse: if a refunded sale claws a commission back, that must be in the terms from the start and visible in the partner's own reporting on the day it happens, not discovered at the next payout.

What has to be in the ledger

Almost every dispute in an affiliate programme is a disagreement about a record. Which means the record has to exist and be the same one both sides look at.

• Every event with the provider's own identifier, so a repeat delivery cannot create a second commission.
• Refusals - refunds, disputes, cancellations - recorded next to the sales they reverse.
• The attribution decision stored with the sale, not recomputed later from rules that may have changed.
• Holds and releases as entries, with the reason, rather than adjustments applied silently.

A programme whose partner-facing report and internal ledger are separate systems will eventually show two different numbers for one week, and the partner will be looking at whichever is higher.

What to check right now

• Whether an attribution policy exists in writing, and whether partners can read it.
• What the attribution window is, and what happens on a tie.
• Whether a repeated postback can create a second commission.
• Whether refunds and disputes reverse commissions, and whether partners see that when it happens.
• How long holds last and whether the release date is published.
• Whether anyone has ever been suspended automatically, and whether they came back.
• Whether the partner report and the internal ledger are the same source.

How adults.dev approaches it

We settle the attribution policy before writing the tracking, because the code otherwise decides it by accident and the decision then hides until a partner complains. The ledger is one source for both sides, with refusals recorded alongside sales, so a disagreement becomes a lookup rather than an argument.

On abuse we build holds rather than bans, sized to measured risk and released on a published date. It catches less in theory and costs far less in practice, because the partners a programme actually depends on are the ones an automatic rule is most likely to remove.

Review your programme with us:
Telegram: @adultsdev
E-mail: info@adults.dev