Your affiliate network says 100 leads for yesterday. Your tracker says 70. Neither number is necessarily wrong. They count different things, at different moments, with different rules, and the gap is usually a sum of several small causes rather than one big bug. The way to deal with it is to stop comparing totals and start matching individual conversions.
This article gives you an order of work: what to export, how to match, which causes to check first, and a worked example with made-up numbers. It applies to any tracker and any network, so the exact menu names will differ.
Export the network's conversions with their click IDs, export the tracker's conversions for the same period in the same time zone, and match them by click ID. Every conversion that exists on one side only belongs in one of a few buckets: status differences (pending, rejected), a missing click ID, a postback that never arrived, a day-boundary shift, duplicates or currency. A small gap of a few percent between clicks and tracker is normal. A gap of 30 percent means one of the buckets is large, and the match will show which.
Step 1: stop comparing totals
Two totals tell you only that there is a gap. To find the cause you need a list of rows on each side. From the network, export every conversion for the period with at least: click ID (often called subid or aff_sub), conversion time, status, payout and offer. From the tracker, export the same fields for the same period.
Before comparing, make both sides use the same rules:
- The same period and time zone. More on this below, it is the most common reason for a daily mismatch.
- The same event. A "lead" in the network may be a registration, a deposit or a confirmed sale. Make sure the tracker's conversion type is the same event.
- The same status filter. If the network total includes pending and rejected rows, include them in your export too, then filter later.
Step 2: match by click ID
Put both lists in a spreadsheet and use the click ID as the key. You will end up with three groups:
- In both. Matched. Compare status and payout on these rows to catch smaller differences.
- In the network only. The network has the conversion, your tracker doesn't. These are the rows to investigate: postback not received, click ID missing or different, or an outside filter.
- In the tracker only. Less common. Usually duplicates, test postbacks or a conversion that the network later removed.
Rows in the network that have no click ID at all are their own group. They can't be matched, and they tell you where the ID was lost. If you need the background on how the ID travels, read click ID and SubID: how to pass them through redirects.
The usual causes, in the order to check
| Cause | How it shows up | How to check and fix |
|---|---|---|
| Time zone and day boundaries | Totals differ for one day but match over a week; the gap moves to the neighbouring day | Find the network's report time zone and set the tracker's to match, or compare whole weeks |
| Statuses counted differently | Network total includes pending and rejected; tracker counts approved only or the other way round | Compare by status. Rows that are pending in the network will appear in revenue only once approved |
| Postback not firing for some events | Conversions are in the network, absent in the tracker, with a valid click ID | Check the postback URL per event type and the network's postback log. See postback not firing |
| Click ID lost on some sources or devices | Network rows with empty subid, often clustered by source, browser or device | Group empty-subid rows by traffic source and device, then test that path |
| Duplicates | Same click ID twice, or a postback fired twice for one conversion | Deduplicate by click ID and event; check whether the network retries postbacks |
| Attribution window | Conversions that happen days after the click are present on one side only | Compare the lifetime of a click in the tracker with the network's window |
| Currency and payout | Counts match, money doesn't | Compare payout per matched row; check the currency the network sends and the one the tracker stores |
| Bots counted differently | Click counts differ even before any conversion | Compare raw clicks to humans-only clicks on each side, see below |
| Cached or delayed reports | Numbers change when you reload an hour later | Look at the report's last-updated time; compare closed periods, not the current hour |
Time zone and day boundaries
Networks report in a fixed time zone that you often can't change, and trackers report in either a server zone or the user's own. A conversion at 23:40 in one zone is already the next day in another. Over a month the effect averages out, but for a single day it can move a noticeable number of leads from one column to another.
Two habits help. Look up the time zone your network reports in and write it next to your reports. And when you reconcile, use a period that is long enough and closed on both sides, such as full days a few days in the past. In TDS.SO the day boundaries of the stats follow your own time zone, so set it to the one your network uses if you want daily numbers to line up.
Statuses: pending, approved, rejected
This is the biggest single source of gaps on offers with manual review, such as finance, nutra or any lead that a human checks. The network counts a conversion the moment it arrives, as pending. A tracker may count only approved conversions, or may record a status change only if the network sends a second postback. In TDS.SO the tracker (in beta) takes revenue from approved conversions, and cost from all clicks, so a pending lead in the network will not be in revenue until its status changes.
Check two things: whether the network sends a postback for status changes (pending to approved, approved to rejected) and whether your postback URL handles the status field. If it doesn't, your tracker either never sees the approval or never sees the rejection.
Bots and click counts
Sometimes the gap starts earlier than conversions. The ad network bills for 1,000 clicks, the tracker shows 870. Reasons include clicks that never loaded the tracking link (the visitor closed the page), duplicate counting on the source side and traffic filtered by your own rules. A tracker that filters bots will log them with a reason but exclude them from the human count. A source usually counts every click it sent.
Compare raw clicks to raw clicks first, then humans to humans. In TDS.SO the overview shows total clicks, unique visitors, humans and bots per day, and the click log keeps filtered clicks with the reason (for example vpn or datacenter), so you can see what was set aside. If you want to tune that side, the traffic filtering page lists the levels and signals. For the background, see JS fingerprint vs IP blocking.
Worked example with made-up numbers
Say the network shows 100 leads for yesterday and the tracker shows 70. You export both lists and match by click ID. The 30 missing rows break down like this:
| Bucket | Rows | What it means |
|---|---|---|
| Empty click ID in the network | 11 | All from one mobile source; the landing's button link had no parameter in an in-app browser |
| Pending in the network | 10 | Valid click ID, status pending; the tracker counts approved only, so they will appear after review |
| Near midnight | 6 | Conversions between 23:00 and 01:00; the network and the tracker use different time zones, so they land on different days |
| Postback never received | 3 | Valid click ID, approved, absent in the tracker; the network's postback log shows timeouts |
Eleven plus ten plus six plus three is thirty. Only the first and last rows are real losses (14 conversions you could be optimizing on). The pending rows will arrive on their own and the midnight rows are in the tracker under the other date. After you fix the landing link and look into the timeouts, tomorrow's gap should shrink to the pending rows alone, which is how you know the fix worked.
Both sides were right by their own rules, so the match doesn't pick a winner. It turns "the numbers disagree" into a short list of things you can change.
What gap is normal
There isn't a fixed number you can rely on. A few percent between clicks and tracker is common, and a small difference in conversions is expected because of timing and statuses. What matters is stability: if the gap is a steady few percent and explained by pending rows and time zones, leave it. If it jumps for one source, one device or one day, something changed on that path, and the match will point at the path.
One more rule of thumb: don't make budget decisions on yesterday's numbers if your offer has a review period. Wait until most of the pending rows have a final status.
FAQ
Which number should I trust, the network's or the tracker's?
For payment, the network's numbers are the ones you get paid on. For optimization the tracker's numbers are more useful because they carry your sub parameters. Reconcile them so you know how far apart they really are and why.
Why do the numbers match in total but not by day?
That points to time zones or to delayed approvals. A week or a closed month will line up, a single day won't.
Why does the network count more conversions than my tracker, with no empty click IDs?
Look at statuses first, then at the postback log on the network side for failed or retried requests. A valid click ID that never made it to the tracker usually means a postback problem.
How often should I reconcile?
Once a week is enough for most setups, and right after you change a landing page, a redirect method or the postback URL.
If you track conversions in TDS.SO, the analytics page shows how clicks, humans and bots are counted, and the tracker with postbacks, conversions and ROI is in beta.
Guides and write-ups on routing, bot filtering and tracking from the TDS.SO team.
All articles by the author