The partner dashboard shows a deposit. Your tracker shows zero. Before changing the offer, pick one transaction and follow its identifiers. A total tells you there is a discrepancy; a trace tells you where it starts.
To troubleshoot a missing S2S conversion, establish four things in order: the business event exists, its original tracker click ID survived, the receiver processed the callback, and the report includes the resulting record. Stop at the first boundary where evidence disappears.
This guide provides a diagnostic worksheet and a six-event acceptance test. Examples are illustrative, not results from a live advertiser account. Tracker-specific behavior is linked to documentation checked on September 7, 2026.
Start with one conversion, not two dashboard totals
Ask the advertiser for one completed event with its transaction ID, type, saved tracker click ID, timestamp with timezone, amount and currency. Request the actual outbound callback and response, with authentication values redacted.
| Identifier | What it connects | Illustrative value |
|---|---|---|
| Traffic-source click ID | Ad platform to tracker | source-42 |
| Tracker click ID | Tracker visit to advertiser event | click-demo-001 |
| Business-event ID | One registration, deposit or order | deposit-demo-001 |
| Delivery-attempt ID | One HTTP attempt, including a retry | attempt-02 |
Generating a new business-event ID for every retry can inflate conversions. Reusing one business-event ID for separate deposits can suppress legitimate revenue. Keep the identity of the event separate from the identity of its delivery.
Postback troubleshooting: symptom to evidence
| Symptom | First check | Evidence that narrows the cause |
|---|---|---|
| Advertiser has a conversion; receiver has no request | Sender log, destination, DNS/TLS and access controls | No send attempt indicates a sender-side gap; a failed attempt identifies a delivery problem |
| Request arrives; click cannot be found | Returned tracker click ID versus original click log | Blank value, unresolved macro or a different ID identifies a mapping problem |
| HTTP 200; conversion absent | Response body and receiver processing log | Rejection, duplicate handling or queued processing explains the missing row |
| Registration appears; deposit does not | Event mapping and duplicate policy | Deposit is filtered, mapped incorrectly or treated as an existing event |
| Conversions exceed real transactions | Event IDs across repeated deliveries | Several rows for one business-event ID indicate duplicate counting |
| Count matches; revenue differs | Amount meaning, currency and update behavior | Deposit value was used as commission, currency differs, or a retry increments revenue |
| Event exists in logs but not the report | Date basis, timezone, filters and columns | The record appears after aligning report definitions |
Use the table to decide which evidence to collect next. A symptom by itself does not establish the cause.
1. Follow the click ID through every handoff
An illustrative offer link after macro expansion might be:
https://offer.example/signup?sub1=click-demo-001
The advertiser must preserve that value and return it in the field your tracker expects. Compare the expanded URL with the advertiser's stored value, rather than comparing two configuration templates.
Keitaro's documented troubleshooting flow follows subid through the offer and back into the postback. Its processing errors distinguish a missing click, a missing or unknown status, and an incorrect postback key. Each requires a different correction. Keitaro troubleshooting
Useful shortcut: inspect the ID at the final offer page, submitted form and stored event. A parameter in the address bar may never reach the backend. Check intermediate pages and app handoffs too.
The names sub1, subid, cid and clickid are not interchangeable instructions. Use the receiver's generated URL and the sender's documented macro for the field that actually retained the tracker ID.
2. Separate HTTP delivery from conversion processing
What a successful HTTP response proves about a business event depends on the endpoint's contract. A proxy, queued receiver or custom handler may acknowledge a request before a conversion becomes visible.
Capture status code, body, timestamp and receiver disposition together. Inspect redirects before following them automatically: an HTML login page is not a conversion-processing result.
This is a Keitaro-shaped request for a controlled test campaign. Replace the host, key and click ID with values from that setup. Automatic retries are deliberately omitted so one execution produces one attempt.
curl --get --silent --show-error --include --max-time 15 \
'https://tracker.example/REPLACE_WITH_TEST_KEY/postback' \
--data-urlencode 'subid=REPLACE_WITH_REAL_TEST_CLICK_ID' \
--data-urlencode 'status=lead' \
--data-urlencode 'tid=registration-test-001' \
--data-urlencode 'payout=0' \
--write-out '\nHTTP %{http_code}; duration %{time_total}s\n'
The placeholder host cannot validate your integration. With real credentials this records or updates test data; use a campaign excluded from paid optimization. Compare the response with the receiver's conversion log.
3. Test retries separately from repeat purchases
A retry delivers the same event again. A repeat purchase is a new event. Preserve that difference throughout the integration.
| Tracker | Documented behavior to check | Practical implication |
|---|---|---|
| Keitaro | Conversion imports include subid, payout, optional tid and status | Preserve transaction identity when updating a particular conversion |
| Voluum | By default, another postback for the same click without a unique txid is not accepted as a new conversion | Distinct purchases need appropriate transaction IDs; duplicate acceptance changes this safeguard |
| RedTrack | Duplicate modes can ignore, create, edit or increment payout; type-level configuration takes precedence over status-level configuration | Inspect the effective mode for each event before replaying requests |
Sources: Keitaro conversion imports, Voluum affiliate-network settings, RedTrack conversion types and duplicates.
Useful shortcut: write the intended duplicate policy beside each event mapping. For example: registration counts once; each distinct deposit counts once; a retry adds nothing; a correction updates the existing event. Configure those rules with the receiver's actual transaction and event fields.
For a custom receiver, advertiser plus event type plus business-event ID is one possible deduplication key. This is a design example, not a claim about those trackers' internal implementation. Persist the event and deduplication record atomically so concurrent retries cannot both be counted.
4. Define registration, deposit and FTD explicitly
Agree what qualifies as a first-time deposit. Does the operator emit FTD on payment success, settlement or another eligibility check? Which identifier represents the player across devices?
Create a mapping sheet containing sender event, receiver event, transaction-ID field, payable status and amount meaning. Registration should not silently become a sale because a template supplied a default status.
A deposit amount and affiliate revenue are different quantities. If a player deposits 50 and the contract pays commission of 20, decide which metric receives each amount. A generic payout field cannot infer that distinction.
5. Run this six-event acceptance test
Use a real click from a dedicated test campaign and the advertiser's test mechanism where available. Direct callbacks test the receiver boundary only; they do not prove that the advertiser captured the original click.
The following contract treats registrations and deposits as separate events and counts each distinct deposit amount once. These are acceptance criteria, not observed product defaults.
| Delivery | Test input | Expected cumulative result |
|---|---|---|
| A | Registration reg-001, original click ID | 1 registration; 0 deposits |
| B | Deposit dep-001, same click, amount 10 | 1 registration; 1 deposit; deposit total 10 |
| C | Exact retry of B, including event ID | Counts and deposit total unchanged |
| D | New deposit dep-002, same click, amount 15 | 1 registration; 2 deposits; deposit total 25 |
| E | New event with missing tracker click ID | No additional attributed conversion; documented error or unattributed outcome |
| F | New event with unmapped event type | Documented rejection or fallback; no silent misclassification accepted |
If C changes revenue, investigate duplicate policy. If D disappears, investigate event identity. If E attaches to an unrelated click, investigate attribution. If F becomes a paid conversion, correct the mapping before feeding that signal to an ad platform.
Save the actual response and record outcome beside each row. The completed worksheet becomes a regression check for your integration and a useful attachment for support.
6. Retry without manufacturing revenue
For a sender you control, store delivery state durably and apply bounded backoff to transient failures according to the receiver's contract. Preserve the business-event ID on every attempt; generate a fresh attempt ID for diagnostics only.
A timeout is ambiguous: the receiver may have processed the event before the connection failed. Validate duplicate handling before enabling automatic retries. An unresolved macro or invalid key needs correction rather than repeated delivery.
After delivery works, reconcile by event identity. Compare eligible advertiser events with accepted tracker events for the same types and time window. List missing IDs, extra IDs and amount mismatches separately. Matching totals can hide a missing conversion and an unrelated duplicate that cancel each other out.
7. Align reporting before declaring data lost
Occurrence time, callback receipt time and original click time can fall on different dates. Choose the same date basis and timezone on both sides, then apply identical status and event filters. RedTrack includes timezone differences and duplicate settings among causes of inconsistent conversion reporting. RedTrack troubleshooting
Also distinguish advertiser-to-tracker delivery from tracker-to-ad-platform delivery. A conversion present in your tracker proves only the first part. Inspect the outgoing integration separately if the traffic source still shows zero.
Send support one trace they can locate
Include tracker click ID, business-event ID and type, occurrence time and timezone, expected amount and currency, expanded callback with secrets removed, delivery time, HTTP status and body, receiver-log outcome and report filters.
Ask: “For this transaction and click, where did processing stop?” That is an actionable request for both teams.
Quick answers
Why is my postback not working? Trace one confirmed event through saved click ID, actual send attempt, receiver processing and report filters. The first missing piece of evidence determines the next check.
Why does a postback return 200 but show no conversion? Check the endpoint's response contract, processing logs, duplicate rules, event mapping and report filters. A response code alone does not establish that a new attributed conversion exists.
Can I resend a missing conversion? First confirm whether it was already recorded. Preserve business-event identity and follow the receiver's documented update or import procedure. Validate duplicate behavior on test data first.
Does S2S tracking need a click ID? Click-attributed tracking needs an identifier linking the event to its original visit. Depending on the integration, it may travel through URL parameters, stored backend data or an API mapping. A callback cannot reconstruct an identifier the advertiser never retained.
For choosing the underlying system, see how to choose a tracker. For the broader measurement problem, read why one million impressions can leave a brand invisible.