Operations and diagnostics
Diagnose and resolve an affiliate tracking incident
Distinguish falling activity, broken links, missing events and approval delays, then restore tracking with an explicit reconciliation process.

Before you begin
Falling reported conversions do not identify the failure. Orders may have declined, clicks may be missing, an integration may have changed or an export may be late. This procedure organises evidence before changes. It assumes a test environment and provider contacts. Confirm expected delays and recovery capabilities for your particular system.
Record the symptom and preserve context
Record first observed time, timezone, programme, country, channel and metric. Compare matching weekdays, campaigns and approval states. Distinguish zero events, gradual declines and interface/export differences. Note recent publishing, redirect, tag, consent, app and checkout changes. Preserve relevant configuration before editing it. Share only necessary diagnostic extracts, without credentials or unrelated personal information.
Check independent business activity
Start with orders or CRM and separate recorded from approved sales. If business activity also falls, tracking failure is not established. Check availability, payment and campaigns. If business sales remain stable, compare programme-eligible orders with reported conversions. Not all site sales belong to a partner; record known exclusions before interpreting a missing-event rate.
Replay a controlled journey
Use identifiable test partners and orders under provider procedures. Start from the actual channel, follow the link, inspect the landing and observe purchase. Check identifiers at each stage: a working shop URL may have lost partner information. Test consent choices within the intended implementation. Do not restore refused collection to clear an alert. One successful journey does not establish universal coverage.
Find the first divergence
Map source link, redirect, landing, order, event emission, reception and platform state. Record expected behaviour, observed behaviour and dated evidence. An emitted event missing at its destination calls for response, schema and queue checks. A received event absent from reports may concern filters, timezone or status. Locate the first divergence instead of changing several components simultaneously.
Make a testable correction
Write the suspected cause, proposed change, expected result and rollback method. Apply a limited fix, then replay the journey with new identifiers. Record restoration time and version. Avoid bulk replay without uniqueness rules. Confirm accepted identifiers, states and periods before backfill. Duplicates can create extra commissions; refunded orders must not be replayed as new sales.
Handle the affected period separately
Restored new conversions do not settle old events. List potentially missing orders with business identifier, amount, currency, state and eligibility evidence. Designate an authoritative record. Tell partners the period, confirmed facts and claim route. Do not promise full recovery before reconciliation. Give every difference an owner and an expected decision.
Close with evidence
Closure requires a successful critical journey, period reconciliation and decisions on differences. Preserve timeline, supported cause and changes, separating facts and hypotheses. Add an alert suited to wrong destinations, absent events, undrained queues or amount differences, and test it. Assign an improvement with an owner and evidence of success.
A working record to adapt
| Signal | Evidence | Next step |
|---|---|---|
| Clicks absent, orders present | Source link and redirect chain | Replay arrival from the affected channel |
| Event emitted, conversion absent | Test identifier, response and queue | Check reception before replay |
| Amount differs | Base, currency, state and refund | Compare matching units |
| New events restored | Post-fix sample and historical differences | Separate recovery and backfill |
Practical answers
Questions to settle before signing
Should every order be replayed?
Only after eligibility, deduplication and recovery procedures have been confirmed.
Does an empty dashboard prove failure?
No. Check filters, timezone, states, business activity and documented delay.
What should support receive?
A minimal reproducible case, timeline and expected versus observed behaviour without unnecessary sensitive information.
When can an incident close?
When the journey works and the affected period has documented treatment and owners.
Sources and further reading
This guide is designed to help you ask better questions and organise a practical plan. It is educational and does not constitute legal, tax or financial advice. Platform rules, market conditions, technical capabilities and eligibility requirements can change, sometimes with little notice. Confirm material decisions with current official sources and, where the consequences matter, with qualified professionals who understand your market and organisation.
