Skip to content
← Insights

Attribution in affiliate programs: rules, statuses, and evidence before settlement

Design verifiable attribution rules, conversion statuses, and evidence to settle affiliate commissions with fewer disputes.

Diagram of attribution rules and conversion statuses in an affiliate program

A disputed commission is rarely explained solely by a link that failed to record a click. It often reveals that the program has not defined precisely enough which commercial journey counts, who can claim it, when entitlement to a commission is confirmed, and what happens if the order changes afterward. If these decisions are resolved in a spreadsheet at the end of each month, the program relies on interpretations rather than operational rules.

Attribution rules for affiliate programs must translate the commercial process into verifiable conditions. The goal is not to capture every possible case from day one, but to establish a clear, implementable, and auditable model. A platform such as Afilnet Affiliate can be part of an ecosystem connected to ecommerce and conversion data; even so, the quality of the outcome depends on events, identifiers, and business decisions being defined before data is integrated.

Start with the commercial journey, not the commission

Start with the commercial journey, not the commission — Linkses visual guide

Before choosing an attribution window or a last-click model, document the journey that can end in a sale or a commissionable outcome. In ecommerce, a typical sequence is: partner click, arrival on the site, customer registration or identification, cart creation, order, payment authorization or capture, shipment, cancellation, and possible return. In demand generation, it may include a form, data validation, sales contact, opportunity, and contract.

Not all events are equivalent. A click starts a potentially attributable relationship, but it does not prove a sale. A created order can be a useful signal, although it may still be canceled. Payment can confirm collection, while the end of the return period usually determines final eligibility. Also document alternative paths: guest checkout, deferred payment, split orders, coupon use, sales assisted by an agent, or device changes.

For each event, indicate its source system, when it is recorded, and whether it can be corrected. For example, ecommerce may be the source for orders and returns; the CRM, the source for lead acceptance; and the payment system, the source for financial confirmation. This separation prevents a technical signal from becoming a commercial truth without validation.

Define the attributable unit and its identifiers

The rule must first answer a basic question: what is attributed? It may be a complete order, an order line, a new customer, an activated subscription, or a qualified lead. The answer affects calculation and exceptions. If compensation is paid per line, a partial return changes part of the commission; if compensation is paid per order, you need to decide how to handle a later amount change.

Assign stable identifiers and retain their relationship:

  • Partner: internal identifier for the affiliate or partner originating the interaction.
  • Interaction: click identifier, referral code, or equivalent data connecting the visit to the source.
  • Customer: pseudonymized or internal identifier when needed to apply new-customer rules, without exposing unnecessary personal data.
  • Order or lead: business key from ecommerce or the CRM.
  • Conversion: its own stable, idempotent identifier that makes it possible to recognize that an update is not a new sale.

Idempotency is critical: if the same event arrives twice because an integration is retried, it must update the same record rather than generate two commissions. Also define which identifier takes precedence when several exist. An order may have a commercial reference, a technical identifier, and an invoice number; the model must specify which one is used for deduplication and which one is used for investigation.

Write rules that can be verified

A useful rule does not say “attribute fairly”; it states which data is evaluated and what the outcome is. It can be expressed as a readable policy and as implementable logic. For example:

If there is a valid partner interaction within the 30 days before the order,
and the order belongs to the eligible channel,
and no applicable exclusion exists,
then assign the conversion to the partner according to the defined priority.

Every program should specify, at a minimum, these criteria:

  • Eligibility: products, countries, customer types, campaigns, and channels that generate a commission.
  • Starting event: click, code use, registration, or another accepted interaction.
  • Attribution window: period between the interaction and the attributable event, with a defined time zone.
  • Priority: last valid click, first click, promotional code, rules by partner type, or a documented order of precedence.
  • Exclusions: self-referrals, confirmed fraud, test orders, ineligible customers, or incompatible channels.
  • Limits: maximum amount, number of conversions per customer, commission on the net amount, or exclusion of taxes, shipping, and discounts.

Priority rules are especially sensitive. If a customer arrives through editorial content and then uses a coupon, it is not enough to decide once which channel “deserves” the commission. You must establish the policy, communicate it, and record the data that proves its application. It is also useful to distinguish between not attributable and attributable to another source: the former may indicate missing data; the latter, a deliberate conflict resolution.

Model conversions and commissions as a state machine

A conversion should not move directly from “received” to “paid.” A state model reduces ambiguity, distributes responsibilities, and protects settlement from commercial changes. A practical sequence is as follows:

  1. Pending: the event and preliminary attribution were received, but the order or lead does not yet meet the final validation condition.
  2. Under review: there is conflicting data, evidence is missing, or a control was triggered, such as a possible duplicate.
  3. Approved: it meets the rules and has passed validations and the applicable commercial period.
  4. Voided: it is no longer commissionable due to cancellation, return, confirmed fraud, error, or failure to meet an exclusion.
  5. Settled: the approved commission has been included in a payment close. This status must retain the period and settlement reference.

Define which transitions are allowed and who can perform them. A return after approval must leave a traceable reversal, not delete the original conversion. After settlement, the adjustment may require a debit note, a balance that can be offset in the next period, or a defined financial process. The decision belongs to business and finance; the system must retain both pieces: the original fact and the adjustment.

Integrate updates without creating new conversions

Ecommerce, CRM, payments, and customer service do not always issue information at the same time. An order may initially arrive as pending payment, change to paid, be reduced due to stock shortages, and ultimately be returned. Treat these messages as updates to the same unit when they share the agreed business identifier.

Establish a mapping table between external events and internal actions. For example, “order canceled” may void a pending conversion; “partial refund” may recalculate the commissionable amount; “address changed” probably should not affect attribution. If an event arrives out of order, use a timestamp, version, or source priority to prevent an older status from overwriting a more recent one. Integrations must also clearly distinguish between a technical retry and a new commercial event.

Retain evidence to resolve discrepancies

The minimum evidence must make it possible to answer without manually reconstructing the case: which partner was considered, which interaction was used, which rule was applied, what the window was, which source reported the order, which amount was used, and who approved or voided the commission. Store timestamps with time zone, identifiers, rule version, and coded reason for every status change.

Traceability does not require storing more personal data than necessary. Apply minimization, access controls, and retention periods defined by applicable obligations. For incidents, prioritize sufficient technical and commercial data—references, statuses, amounts, and decisions—over indiscriminate copies of customer information.

Good evidence does not only prove that a sale occurred: it proves why that sale was attributed, approved, or voided under an active rule.

Prepare the close and measure operational health

Before settlement, set a cutoff date, the person responsible for approving exceptions, and a policy for late events. Review pending conversions older than the expected period, cases under review, recent voids, negative amounts, and changes after the close. The close must generate a frozen set of commissions eligible for settlement; subsequent adjustments must be entered as new, auditable transactions.

Measure operational indicators that reveal design failures: percentage of conversions without sufficient interaction or evidence, duplicate rate, proportion of conversions under review, voids by reason, average time to approval, and volume of adjustments after settlement. An increase in conversions without evidence may point to an incomplete integration; too many manual reviews usually indicate insufficiently objective rules or inadequate data.

Checklist before putting the rules into production

Checklist before putting the rules into production — Linkses visual guide
  • The attributable unit and commissionable amount are defined for each conversion type.
  • Identifiers connect the partner, interaction, customer where applicable, order, and conversion without relying on free text.
  • Eligibility, window, priority, exclusion, and limit rules have test examples.
  • Order, payment, cancellation, return, and modification events have explicit handling.
  • Statuses, transitions, responsible parties, and void reasons are documented.
  • Deduplication and the handling of technical retries have been tested.
  • Queryable evidence exists for every decision, along with a discrepancy procedure.
  • The period close accounts for pending items, reviews, and subsequent adjustments.

Review this design when checkout, return policies, the CRM, payment methods, or the partner offering changes. The rules are not a static document: they are a controlled representation of the commercial process. Keeping them aligned with that process is the basis for settling commissions using consistent and defensible criteria.

Sources and references

  1. Web technology standardsW3C
  2. Web security guidanceOWASP Foundation
  3. Web performance guidanceweb.dev
Linkses · Boost your business

Written and reviewed by the Linkses editorial team. Revisión editorial de Linkses.