WORLD AFFILIATE GUIDEINDEPENDENT · INTERNATIONAL · PRACTICAL

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.

Network switches and Ethernet cables
Editorial image for Tracking incidentPhoto : Jon ‘ShakataGaNai’ Davis · CC BY-SA 3.0 · Resized and converted to WebP.

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

SignalEvidenceNext step
Clicks absent, orders presentSource link and redirect chainReplay arrival from the affected channel
Event emitted, conversion absentTest identifier, response and queueCheck reception before replay
Amount differsBase, currency, state and refundCompare matching units
New events restoredPost-fix sample and historical differencesSeparate 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

EDITORIAL NOTE

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.

Related guides

Each guide covers a different part of the same operating system.

Next step

Turn the framework into a shortlist.

Write down the outcome you want, the limits you cannot ignore and the evidence that would make a test successful. Then compare only the platforms that fit those conditions.

Compare platforms →Open the glossary

Explore categories

Explore individual service descriptions, selection criteria and a practical test for each tool family.

Explore categories →

Move from selection to operations