This practical method uses fictional examples. It does not report a client engagement, production trace or measured campaign improvement.
Separate the two postback legs
This note starts after an expected conversion appears in RedTrack. The advertiser-to-tracker leg may have worked, but that does not prove the tracker sent an eligible event to the source. Confirm the event belongs to the intended campaign and is not a duplicate or a manually added test.
Define the discrepancy using one acquisition cohort, timezone, attribution window and event. A deposit event can be a repeat deposit. A unique depositor can be a returning customer. An FTD requires a first qualifying deposit; an approved FTD requires the advertiser's validation. A source's generic “conversion” column may mean something else entirely.
Keep the event timestamp, receipt timestamp and approval timestamp distinct. Deposits are not revenue, and a value field must carry the agreed meaning and currency. Do not send deposit amount as affiliate commission.
Trace one event before comparing totals
RedTrack's official FAQ recommends checking campaign postback or API configuration, outgoing logs and the click's ref id. The sequence below expands those checks into a decision record. RedTrack troubleshooting FAQ.
- Find the original click and its source identifier
Use the RedTrack click ID to locate the click record. Check the ref ID captured from the traffic source. The tracker click ID and source click ID serve different systems; they are not interchangeable.
An empty ref ID, an unexpanded macro or an ID from another source cannot be fixed by sending more postbacks. Check the source template and actual campaign URL against the source's documented macro. Compare a known valid click. Do not guess or manufacture a missing historical ID.
- Check whether this event should be forwarded
Inspect campaign-level postback settings or the relevant API integration, event mapping and any event, payout or status filters. Confirm the destination campaign or goal. A pending FTD should not be promoted to approved FTD just to make reports match.
- Inspect the outgoing record
Look for an outbound attempt for that event. If none exists, investigate eligibility and dispatch configuration. If one exists, inspect the rendered destination and parameters, send time, response body and retry history. For API delivery, use its corresponding logs.
Keep credentials and raw click or customer identifiers out of shared screenshots. Use local aliases in a support summary; retain originals only in the authorized system.
- Read acceptance at the destination
A timeout leaves delivery uncertain. A rejection needs its exact documented reason. HTTP 200 is a transport-level success response; inspect the body and the source's event log before assuming acceptance. It is not evidence of business approval, an approved FTD or paid commission.
- Reconcile the source report
Verify goal selection, campaign, timezone, click-date versus conversion-date reporting, attribution eligibility and the source's reporting delay. Compare received, accepted, attributed and displayed states separately. The source may acknowledge a request without crediting it to the report you opened.
Worked example: the ref ID was never captured
Fictional diagnostic trace. All aliases below are invented. This is not a production incident or a claim that a repair recovered revenue.
| Record | Observation | Interpretation |
|---|---|---|
| RT-DEMO-A | The click record has an empty ref ID. | RedTrack lacks the source-side identifier for this click. |
| EVT-DEMO-A | A deposit event is linked to RT-DEMO-A. | The incoming tracker leg has a record. First-depositor status and approval remain unproven. |
| Source handoff | The outgoing record contains no usable source click ID. | The source cannot reliably match this request to the intended click. |
Suppose inspection then shows that the campaign URL omitted the source click-ID mapping. That evidence supports correcting this mapping for future clicks, followed by a controlled verification. It does not justify replacing the blank value with the RedTrack click ID.
The old event remains unreconciled unless the original source identifier can be recovered from an authorized record and a supported reconciliation process exists. Record that limit. A successful future test proves the corrected path under test conditions, not automatic recovery of every historical event.
Verify without polluting optimization
RedTrack's official traffic-source postback test explains why a source-generated click is needed to supply a ref ID. It also describes creating a synthetic conversion. That procedure can contaminate live reporting if used without isolation.
Use a documented sandbox or a clearly separate test campaign and test event, excluded from production bidding, billing and business reporting. Confirm those exclusions at both ends before testing. Do not send a fake FTD or approved FTD into a live optimization goal. If isolation is unavailable, verify through a genuine authorized event or coordinate a supported test with the source and advertiser.
Before replaying anything, check whether the destination already accepted it and how it deduplicates. A timeout is not proof of failure. Keep an event identifier and retry record; avoid blind repeated requests. For an advertiser-to-RedTrack test, follow the advertiser or affiliate network's own supported process.
Close the incident with evidence, then resume decisions
A useful closure states which setting changed, the redacted event checked, source acceptance and attribution evidence, the report window allowed, duplicate handling and any unresolved historical gap. If approvals are still pending, say so.
While the signal is unreliable, freeze scaling and cap or pause affected delivery under the existing risk limit. Resume optimization only after the intended event reaches the intended goal and the business definition is intact. Report reconciliation establishes a usable attribution path; it does not measure advertising incrementality.
Official documentation checked 25 October 2026. UI labels and supported integrations can change; use the current documentation for the specific source.