The classic picture: the affiliate network dashboard already shows five leads, the tracker shows zero conversions. Or the reverse — conversions exist, but all of them hang on one click. The postback is the most fragile part of the setup: one extra character in the URL and the stats lie while you optimise a campaign on wrong data. This guide is not about what a postback is (that is covered in a separate article) — it is about why it does not arrive and how to find the break methodically instead of poking at random.
Where Exactly It Breaks: Three Checkpoints
A postback passes three points, and the break is always in one of them. Before changing anything, determine how far the data gets.
| Checkpoint | What should happen | Where to verify |
|---|---|---|
| 1. Click → network | The tracker generates a clickid and passes it in the offer link | Tracker click logs, the offer link in the network: is your parameter with the clickid there |
| 2. Conversion → postback | On conversion the network calls your postback URL with that clickid | Postback logs in the network dashboard (if available) or a test postback |
| 3. Postback → tracker | The tracker receives the request, finds the click by clickid and records the conversion | Incoming postback logs in the tracker |
If the clickid is not visible in the offer link — the problem is at checkpoint 1. If the network shows a sent postback the tracker never sees — checkpoint 3. If the network never sent one — checkpoint 2. Then go through the mistakes for that checkpoint.
Checkpoint 1: The clickid Never Reaches the Network
1. The tracker macro is not substituted
The offer link has a parameter like subid={clickid}, but the tracker uses a different macro syntax — {{clickid}}, [clickid], %clickid% or its own name like {subid}. As a result the literal string "{clickid}" goes to the network instead of the value. Check: open the click log in the tracker and look at the final redirect URL. Curly braces in it mean the macro did not fire.
2. The wrong parameter on the network side
Every network expects the clickid in its own parameter: subid for one, sub1, aff_sub, s1, cid, click_id for others. If you passed the clickid in sub2 but the network's postback returns sub1 — you get nothing back. Check the network documentation or ask your manager which parameter they return in the postback.
3. The parameter is truncated or overwritten
Some networks limit subid length, and tracker clickids can be long. Others overwrite the parameter with their own values if it collides with an internal one. Check: compare the clickid in the tracker log with what the network's click stats show.
4. An intermediate redirect drops parameters
Between the tracker and the offer there is another redirect — a pre-lander, a shortener, your own bridge domain — and it does not pass query parameters through. Check: walk the chain manually with a test clickid and see whether it reaches the final URL.
Checkpoint 2: The Network Does Not Send the Postback
5. The postback URL is not saved, or saved in the wrong place
The most common cause and the most annoying. In a network the postback is configured at account, offer or specific stream level — and a setting at one level does not always apply to another. Verify the URL is set exactly where you run traffic and that it was saved (some dashboards require confirmation).
6. The postback is set for a different status
The network sends a postback on a specific event: lead, approval, sale, hold, rejection. If your postback fires only on "approved" and the leads are on hold — the tracker shows no conversions until they are confirmed. For gambling that is registration vs deposit, for nutra — lead vs confirmed order. Configure postbacks for every status you need and pass the status as a parameter.
7. The postback goes to an outdated tracker domain
You changed the tracker domain, moved to another server, dropped an old subdomain — and the network still has the old postback URL. The network sends honestly, into the void. Verify the domain in the postback URL is the one the tracker currently lives on.
8. HTTP instead of HTTPS, or the reverse
The tracker accepts postbacks only over HTTPS while the network has HTTP configured — and some networks do not follow the redirect to HTTPS. Or the tracker domain's certificate has expired and the request is rejected. Check: open the postback URL in a browser — it must respond without certificate warnings.
Checkpoint 3: The Tracker Receives but Does Not Record
9. IP whitelist in the tracker
The tracker restricts incoming postbacks by IP, and the network sends from other addresses — or changed them. The request arrives and is rejected. Check: tracker logs show an incoming request with a refusal. Either add the network's IPs to the whitelist or disable the filter.
10. Duplicate filter and attribution window
The tracker discards repeat postbacks with the same clickid — that is duplicate protection. If the network sends a lead and then an approval with the same clickid and no status parameter, the second request is treated as a duplicate and ignored. Separately — the attribution window: if the conversion arrives 30 days after the click and the tracker window is 7 days, it will not be attributed.
11. Wrong encoding or stray characters
A payout parameter with a comma instead of a dot, a space in the clickid, a "+" instead of an encoded "%2B", non-Latin characters in the status — any of these can make the tracker fail to parse the request or find the click. Check: compare the exact string from the incoming postback log with the expected format.
12. Clickid not found: a conversion without a click
The postback arrived, the format is right, but the tracker replies "click not found". Causes: the click was in another stream or campaign; the clickid belongs to a test click that was already deleted; the tracker was reinstalled and the click database is empty. Check: search for this clickid in the click log — if it is not there, find where it was lost before the tracker.
15-Minute Diagnostic Flow
- Make a test click through the tracker with logging enabled. Note the clickid.
- Check the final redirect URL: clickid present, in the right parameter, no curly braces.
- Send a test postback from the network dashboard (if there is a button) or open the postback URL manually in a browser with your clickid substituted.
- Open the incoming postback log in the tracker. Is the request visible? If not — checkpoint 2 or network (HTTPS, domain, whitelist). If visible with an error — checkpoint 3, read the error text.
- Find the conversion in the report. If it is missing despite a successful postback — attribution window, duplicate filter or status.
This same run is a mandatory step before launching any new funnel. Five minutes of testing save days of optimising on broken stats.
A Pixel Does Not Replace a Postback
A common mistake: "I have a pixel on the thank-you page, why a postback". A pixel fires in the user's browser and sees nothing of what happens on the network side: approval, hold, rejection, the actual payout. A postback is server-side, independent of ad blockers and closed tabs, and carries the conversion status. For ad platforms the two channels complement each other: server-side data goes to Meta and Google through CAPI and offline conversions, and the logic is the same — based on the clickid from the postback.
Postbacks and Tracker Choice
Different trackers use different macro syntax, different logs and different default protections — that is where half of the mistakes above come from when migrating from one tracker to another. On the differences and what suits whom — Keitaro or Binom: Which Tracker to Choose; reviews in the tracker catalog.
Forum Discussion
Every network has its own parameters and postback quirks. If the checklist did not reveal the break, describe your setup — tracker, network, what the logs show — in the general questions section of the forum: chances are someone has already configured exactly that pair.
Frequently Asked Questions
Why does the network show leads but the tracker shows no conversions?
The postback does not reach the tracker, or reaches it but is not recorded. Most often: the clickid was not passed to the network, the postback URL is not saved or saved at the wrong level, the postback is set for a different status, or the tracker rejects the request due to an IP whitelist or duplicate filter.
How do I test whether a postback works?
Make a test click through the tracker, take its clickid, call the postback URL with that clickid manually from a browser or via the test button in the network, then check the incoming postback log and the conversion report in the tracker.
What is a clickid and why is it in the postback?
A unique click identifier the tracker generates on redirect. The network returns it in the postback, and by it the tracker knows which click, campaign and source produced the conversion.
Why does the postback arrive but no conversion appears?
The tracker did not find the click by clickid, discarded the request as a duplicate, the conversion fell outside the attribution window, or the status in the postback does not match the configured one. The answer is in the error text in the incoming postback log.
Postback over HTTP or HTTPS?
HTTPS. The tracker domain must have a valid certificate and the postback URL in the network must start with https://. Some networks do not follow an HTTP-to-HTTPS redirect.
Do I need a postback if I have a pixel?
Yes. A pixel sees only the event in the user's browser, while a postback carries the conversion status on the network side: approval, hold, payout. Without a postback, real revenue statistics are impossible.
How do I pass conversion status in a postback?
As a separate parameter in the postback URL — e.g. status={status} — and map the network's statuses (lead, approved, rejected, hold) to your conversion types in the tracker. Then an approval updates the existing conversion instead of being discarded as a duplicate.
