If your postback is not firing, the conversion exists on the network side but never reaches your tracker. In almost every case the cause sits in one of about a dozen places, and you can find it by checking them in order, from the click itself to the last report filter.
This checklist follows the path of the data: your link, the offer URL, the network settings, the postback URL, your receiving side and finally the report. If you are new to the mechanism, read Postback URL explained first.
Start with the click ID. Open your tracking link, follow it to the offer and confirm that the sub ID parameter holds a real value. If it does, check that the macro names in the postback URL match the network's own list, then ask the network to fire a test conversion and see whether your tracker receives a request at all. That split (request never arrives versus request arrives but is not counted) narrows the problem to half the list.
First, find out which half of the chain is broken
Two very different problems look the same in a report: "I see no conversions". Either the network never called your postback URL, or it called and your tracker did not count it. Before going through the list, look at your tracker's click log and any request log you have for the postback endpoint. If you can see incoming requests with errors or empty values, you are in the second group. If you see nothing, you are in the first.
The checklist
Work through these in order. Stop when you find the break, fix it, and run another test conversion.
1. The click ID is not passed to the offer link
This is the most common cause. Open your tracking link, follow the redirect and read the final URL. The sub ID parameter should contain a value like a8f3c21d. If it is empty, or if it contains the literal text of a macro such as {clickid}, the tracker did not substitute it. Check that the macro in your offer URL is the one your tracker uses, spelled exactly.
2. Wrong macro name in the postback URL
The network replaces only the macros it knows. If you pasted {clickid} into the postback but your network's macro is {subid}, the request goes out with the literal text {clickid}, and your tracker finds no matching click. Copy the macro names from the network's documentation, not from another network's guide.
3. The parameter was stripped by a redirect or landing page
A prelander, a link shortener, a redirect step or a form handler can drop query parameters. The click ID leaves your tracker, but the offer never receives it. Walk the full path by hand and read the URL after each step. Pay special attention to pages that build a new link to the offer in code: they often forget to copy the incoming parameters.
4. URL encoding problems
Special characters in a URL must be encoded. If a value contains a space, a plus sign, an ampersand or a hash, it can cut the parameter off or get changed on the way. A double-encoded value is another variant: %2520 instead of %20. Keep click IDs simple (letters and digits) and check what the network actually sends by looking at a raw request.
5. http vs https
If your domain redirects http to https, some networks do not follow the redirect on postback calls, or they follow it and lose the parameters. Put the final https address into the network settings. Also confirm that the certificate is valid. A network's server will usually refuse to talk to a domain with a broken certificate.
6. The network did not fire the postback at all
Sometimes the setup on your side is right and the network is silent. Ask for a test postback or a test conversion. Many networks have a log of outgoing postbacks with the response code your server returned. If that log is empty for your conversion, the network did not send anything, and the problem is in its settings or in the conversion itself (see items 7 and 8).
7. The postback is set on the wrong offer or level
Networks store postback settings at different levels: account, offer group, single offer. A URL saved on the account may be overridden by one on the offer. A URL saved on a different offer will never fire for the one you run. Open the settings of the exact offer you promote and check what is set there.
8. The status filter excludes the event
Many networks let you choose which statuses trigger a postback. If only approved is ticked, you will not see pending conversions until the advertiser confirms them, which can take days. If your tracker only accepts a specific value for approved, a different word from the network gets ignored. Compare what the network sends with what your tracker expects.
9. The conversion was rejected as a duplicate
Two kinds of duplicate protection exist. The advertiser may reject a repeat conversion from the same user. Your tracker may also treat a repeat transaction ID as an update of an existing conversion rather than a new one. If you re-run a test with the same click ID and the same transaction ID, the second call does not add a row. Use a fresh click for every test.
10. The receiving side blocks the request
If your tracker or a firewall in front of it allows only certain IP addresses, the network's servers must be on that list. A WAF rule, a rate limit or a security plugin can also return an error to unfamiliar traffic. Look at the response code the network logged: 403 or 429 point to a block on your side, 404 to a wrong path, 5xx to a server error.
11. Time zone confusion in reports
The conversion can be there, just on a different day than you are looking at. The network reports in one time zone, your tracker in another, and a conversion registered close to midnight lands in the neighbouring day. Widen the date range by a day on both sides before you conclude it is missing. In TDS.SO, stats day boundaries follow your own time zone, so check which zone your account uses when you compare with the network's report.
12. The conversion is delayed
Some advertisers confirm conversions in batches, and some verify manually. The network may register the conversion at once but send the postback only after review. If the click was recent, wait for the normal approval time of that offer before you start changing settings. The network's conversion report with timestamps will show whether the event is simply still on hold.
Symptom to likely cause
| What you see | Likely cause | Check |
|---|---|---|
| Sub ID in the offer URL is empty | Click ID not passed | Offer URL macro in the tracker (1) |
| Postback arrives, click not found | Wrong macro, parameter stripped or encoded | Macro names, redirects, encoding (2, 3, 4) |
| Network log shows no outgoing postback | Wrong offer or level, status filter, network did not fire | Settings on the exact offer (6, 7, 8) |
| Network log shows 403 or 429 | Block on the receiving side | IP allowlist, firewall, rate limit (10) |
| Network log shows redirect or SSL error | http vs https, certificate | Protocol and certificate (5) |
| Conversion appears once, a retest shows nothing | Duplicate protection | Use a new click and a new transaction ID (9) |
| Conversion shows up a day off | Time zone difference | Report time zones (11) |
| Everything is correct, nothing yet | Hold or batch approval | Network report timestamps (12) |
A worked example
Say you ran 400 clicks to an offer yesterday, and the network reports 6 conversions while your tracker shows 0. Here is how the checklist narrows it down.
- You open your own tracking link. The offer URL ends with
?subid=and nothing after it. The click ID is not being passed: the offer URL in the tracker used a macro that the tracker does not recognise. You fix the macro. - You make a new test click. The URL now ends with
?subid=b71e09aa. The first problem is solved. - You ask the network for a test conversion on that click. The network log shows the postback was sent and your server returned 200, yet the conversion does not appear. The log line shows the request contained the literal text
{clickid}. - The network's macro was
{subid}. You change the postback URL and repeat the test. The conversion appears on your test click.
The 6 conversions from yesterday were lost, because the postback was not firing correctly when they happened. Ask the network support whether they can resend postbacks for those conversion IDs. Many cannot, so keep the network's own report as the source for reconciliation.
How to keep it from happening again
- Run a test conversion every time you change the offer link, the landing page or the redirect method.
- Compare conversion counts in the network report and in the tracker once a week for a small sample. A growing gap shows up early this way.
- Save a note with the network's macro list next to your postback URL.
- Keep the click ID in the URL through every step. The post on click ID and sub ID explains how the identifier moves and what can drop it.
FAQ
Why is my postback not working even though the URL looks right?
Usually the URL is fine and the value is wrong. Look at the raw request the network logged. A literal {clickid} or an empty click ID tells you the macro or the offer link is the problem, not the address.
How long does a postback take to arrive?
A technical call arrives within seconds of the event. The event itself can take much longer, because advertisers confirm conversions on their own schedule. Check the network report to see whether the conversion is registered yet.
My network has no postback log. How do I see what it sent?
Use the request log on your side if your tracker or server keeps one, or ask the network support for the outgoing request for a specific conversion. A test conversion on your own click makes this much easier.
Can bot traffic cause missing postbacks?
Bots rarely convert, but they do inflate the click count, so conversion rates look lower than they are. Filtering them out of the click stream keeps the stats honest. See Bot filtering for how TDS.SO handles it.
Conversion tracking in TDS.SO is in beta, and you can read what the analytics section covers on the Analytics page.
Guides and write-ups on routing, bot filtering and tracking from the TDS.SO team.
All articles by the author