Reason codes affiliates and advertisers can trust

In an affiliate operation, reporting carries money and trust. A publisher promotes an advertiser’s products or services under an affiliate programme, while a network may track the agreed action. Add a call center and fulfilment chain, and several parties now describe the same customer journey from different systems. A vague “rejected” status is not enough for optimisation or a commercial dispute.

A reason-code system should answer three different questions: what happened, what is the record’s current state, and why did it move there? It should also avoid collecting unnecessary personal detail or turning an operator’s impression into a claim of fraud.

1. Separate the event, status and reason

Do not overwrite each attempt with the next attempt. Preserve an append-only event history and derive the current status under documented rules. A “no answer” at 10:00 may be followed by a customer contact at 15:00; it was a valid event but is no longer the lead’s terminal outcome.

2. Design a small observable taxonomy

Start with workflow families. The exact labels can differ, but each code needs one definition, an evidence rule and a next action.

Intake and eligibility

• accepted: entered the active calling queue.
• duplicate: matched a prior record under the written deduplication key and time window; return the matched record reference where contractually permitted.
• missing_required_field: cannot enter the workflow because a named required field is absent.
• market_or_offer_out_of_scope: submitted country, service area, product or campaign is outside the agreed scope.
• suppressed_contact: contact is prohibited by an applicable suppression or withdrawal rule.

Contact process

• callback_scheduled: the customer requested a documented future time.
• no_answer: a specific attempt completed without an answer; normally an event, not a terminal reason until the attempt policy is exhausted.
• unreachable_number: the telecom result shows the number cannot presently be reached under the agreed rule.
• wrong_person_or_number: a respondent states the intended customer is not available at that number.
• language_unavailable: the customer requires a language the active project cannot support; route or close according to policy.
• attempt_policy_exhausted: all permitted attempts were completed with no qualifying contact.

Customer decision

• customer_denies_submission: the reached person states they did not submit the lead or order. This is observable; it is not automatically proof of affiliate fraud.
• price_or_fee_declined: customer declines after the final price and included fees are disclosed.
• delivery_timing_declined: available delivery timing does not meet the customer’s need.
• payment_method_declined: customer will not use the available payment path.
• product_or_offer_declined: customer understands the offer but does not want to proceed; optional approved sub-reasons may capture why.
• not_eligible_under_offer_rules: fails a written advertiser rule; store the rule ID rather than sensitive narrative.
• confirmed: customer explicitly agrees to product, basket, final price, payment and delivery details.

After confirmation

Keep fulfilment and delivery reasons in their source systems but join them to the same order: stock rejection, service-zone rejection, dispatch delay, customer cancellation, failed delivery attempt, refused delivery, address not located, payment/collection issue and delivered. Do not force courier outcomes into the call-center taxonomy.

Avoid a permanent “other” bucket. Allow temporary free text for an unclassified edge case, review it on a schedule and either map it to an existing code or approve a versioned new code.

3. Write the data contract affiliates can inspect

For each status and reason, document:

• stable machine code and human-readable label;
• definition and explicit exclusions;
• whether it is an event, interim state or terminal state;
• which role or system may set it;
• required fields and evidence reference;
• whether another attempt is permitted and when;
• commercial treatment, if the contract links the code to validation or payment;
• permitted transitions into and out of the state;
• schema version and effective date.

Make updates idempotent and traceable

Every status export should have a unique event ID. A retried webhook must not create a second commercial event. Corrections should append a reversal or replacement event with an actor, time and reason—not silently mutate a historical row.

Minimise sensitive information

Affiliate reports usually need operational and commercial evidence, not full call audio, medical information or unrestricted customer details. Use pseudonymous lead/order identifiers, role-based access and a defined dispute route. For health products, avoid free-text notes that capture unnecessary health details. The advertiser should supply approved claims and escalation rules; the reason taxonomy should not encourage agents to diagnose customers. The FTC’s health-products guidance is a useful international risk reference, but market-specific review remains necessary.

4. Build a report that preserves denominator and cohort

A useful source-level report starts with counts, then rates, then reasons.

1. Scope: advertiser, market, offer, source, affiliate/subID, currency and reporting timezone.
2. Cohort: accepted-lead date range and the maturity state of call, dispatch and delivery outcomes.
3. Volume: submitted, technically rejected, accepted, attempted, contacted, confirmed, fulfilment accepted, dispatched and delivered.
4. Conversion: contact/accepted, confirmed/contacted, confirmed/accepted, delivered/dispatched and delivered/accepted—each with numerator and denominator.
5. Reason mix: count and share within the correct parent state. For example, customer-decision reasons among contacted unconfirmed leads—not among all submitted leads.
6. Timeliness: lead age at first attempt, time to first contact and status-export latency using distributions or transparent bands, not only one average.
7. Quality and corrections: audited sample, overturned statuses, unresolved disputes and schema changes.

Never compare percentages without exposing the count, denominator, cohort age and definition version.

Keep “lead quality” decomposed

Instead of a single bad-lead percentage, show observable components: duplicate under rule, missing field, out-of-scope market, wrong number, customer denies submission, contact not achieved after the attempt policy, offer declined and confirmed. This lets the publisher adjust traffic or representation while the advertiser examines price, promise and fulfilment.

5. Govern corrections and disputes

Write the review route into the commercial process before the first invoice.

• Set the time window for a source or advertiser to challenge a record.
• Identify the minimum evidence visible to each role without exposing unrelated customer data.
• Use a reviewer who was not the original status setter for material disputes.
• Record upheld, overturned and inconclusive outcomes.
• Reconcile corrections in the next report and, where relevant, the commercial statement.
• Review disagreement patterns by code and operator; high disagreement may indicate a poor definition, not poor intent.

Treat suspected fraud separately. A flag can route a cluster for investigation, but the final conclusion should follow an agreed review standard. Do not let an operator use “fake” as a convenient substitute for “customer denies submission,” “wrong number” or “duplicate.”

6. Turn reason codes into controlled improvement

The code is the start of a question, not the entire answer.

Run regular calibration with advertisers, operations and QA. Sample positive outcomes as well as rejections. Publish definition changes in advance and keep old cohorts on the schema under which they were operated. That is how reporting becomes a shared control system rather than a post-hoc argument about traffic.