Every operator eventually stares at three screens that disagree — the tracker says one number, the network another, the ad platform a third — and has to decide whether it is nothing to worry about or a leak draining real money. Knowing the difference is one of the most valuable skills you can build.
Tracking data is never perfectly clean, so the goal is not zero discrepancy — it is knowing which gaps are the normal cost of doing business and which are a genuine fault you must fix before you scale a decision on top of bad numbers. This guide covers the usual suspects: discrepancies between systems, broken postbacks, double-counting, attribution mismatch, missing conversions, and consent and blocker gaps — and gives you a routine for finding the culprit. It assumes you already understand the plumbing in postback tracking and pixel tracking.
The first thing to internalise is that some disagreement is always present, and panicking over it wastes time. As a working rule, a discrepancy of roughly five to ten per cent between two systems is normal and expected — it comes from timing, deduplication, rounding and unavoidable data loss. Anything above about fifteen per cent deserves investigation, and a gap that suddenly widens is more alarming than one that is large but stable, because a stable gap usually reflects a structural quirk you have already accounted for, while a moving one signals something just broke. Treat these thresholds as directional, not gospel — the acceptable range varies by traffic type and platform — but the principle holds: judge the trend as much as the size. A steady twelve per cent is often fine; a jump from three per cent to twenty overnight is a fire.
| Symptom | Likely cause | Where to look / fix |
|---|---|---|
| Tracker shows conversions, network shows none | Broken or unfired postback | Test the postback URL & click ID |
| Total conversions exceed real sales | Double-counting | Add dedup by event/transaction ID |
| Platforms each claim the same sale | Attribution model / window mismatch | Align windows; trust one source |
| Sudden drop in tracked conversions | Missing pixel or changed page | Re-check firing on the new flow |
| Steady under-count on some browsers | Consent / ad-blocker gaps | Move to server-side capture |
| Numbers off by a fixed daily lag | Processing delay | Compare same finalised window |
The most common hard failure is a postback that never fires or fires wrong. The classic signature is a tracker that records conversions the network cannot see at all, which means the server-to-server signal connecting them is broken somewhere. The usual culprits are a missing or malformed click ID, so the conversion arrives with nothing to attribute it to; a postback URL that was never verified or was pasted with a typo in a token; or a firewall or firing condition that silently drops the request. The fix is methodical: send a test conversion end to end, confirm the click ID is captured at entry and passed all the way through to the postback, and check both systems log the same event. A postback that works in isolation but fails on live traffic almost always points to a parameter that is present in your test but empty in the real funnel.
The mirror-image problem is too many conversions, where your reported total quietly exceeds the real sales the advertiser confirms. Double-counting usually comes from an event firing more than once — a pixel on a thank-you page the user reloads or returns to, a postback retried without deduplication, or the same conversion captured by both a pixel and a server feed with no shared ID to reconcile them. It is more dangerous than under-counting because it flatters you: it inflates conversion rate and ROI, and you can scale a campaign that looks like a winner but is not. The defence is deduplication by a unique identifier — an order or transaction ID, or a shared event ID across pixel and server — so the same real event is only ever counted once no matter how many times the signal arrives.
Sometimes nothing is broken at all and the systems still disagree, because they are attributing the same conversion by different rules. Two platforms will both legitimately claim a sale if their attribution windows differ — a seven-day click window on one and a thirty-day window on the other — or if one uses last-click while another uses a data-driven model that spreads credit across touchpoints. This is the single most common reason totals across channels add up to more conversions than actually happened, and no amount of debugging will "fix" it because there is no bug. The remedy is not technical but analytical: align windows where you can, then pick one source of truth for money decisions rather than summing across platforms that each grade themselves generously. The attribution models guide explains why each model tells a different story.
A sudden, unexplained drop in tracked conversions is usually a break, not a market shift, and the timing tells you where to look. If the fall lines up with a site change, a checkout redesign or a new landing page, the pixel or postback most likely no longer fires on the new flow — the thank-you page moved, an extra step was added, or a script was removed. If it lines up with nothing on your side, suspect the advertiser's page, a broken redirect or an expired integration. The instinct to blame the traffic source is usually wrong; verify the tracking first. Reproduce a conversion yourself, watch whether the event fires, and compare against a known-good baseline from before the drop. A conversion that completes for the user but never reaches your reports is a tracking failure, and every day it runs unnoticed is money you cannot see and cannot optimise.
Not every gap is a bug — some are the permanent tax of the modern web. Consent banners mean a share of users decline tracking outright, and their conversions may never be recorded browser-side even though the sale is real. Ad blockers strip an estimated fifteen to thirty per cent of browser-side signals, and privacy-first browsers like Safari cap the cookies pixels rely on. The tell-tale sign is a steady under-count concentrated on particular browsers or regions rather than a sudden break — Safari traffic quietly reporting fewer conversions than its share of clicks would predict, for instance. You cannot debug this away, because nothing is malfunctioning; the fix is architectural. Moving measurement server-side recovers a large portion of these lost events precisely because the signal no longer depends on the user's browser cooperating. Treat consent and blocker loss as a known, quantifiable haircut, not a mystery to solve each week.
When numbers disagree, resist the urge to guess and work the problem in order. First, ask whether the gap is new or long-standing — a stable gap is usually structural and safe, a fresh one is a break. Second, check the obvious mechanics before the exotic theories: the pixel fires, the click ID is present, the postback URL is verified, the windows match — misconfiguration, not conspiracy, is the number-one cause of bad data. Third, compare the same finalised time window across systems, since a chunk of apparent discrepancy is just one platform reporting in near real time while another batches on a day's delay. Fourth, reproduce a conversion end to end and watch it travel. Only once the plumbing is cleared should you attribute the remainder to the unavoidable consent and blocker haircut. This ladder — trend, mechanics, timing, live test — turns a frightening wall of mismatched numbers into a short list of checks, and it keeps you from scaling a decision on data you have not actually validated. Feed the clean result back into your dashboard so the next anomaly is easier to spot.
Roughly five to ten per cent is normal and expected from timing, deduplication and rounding. Above about fifteen per cent is worth investigating. Just as important as the size is the trend — a stable gap usually reflects a known structural quirk, while a gap that suddenly widens signals that something just broke.
Almost always the postback. Either the click ID is missing so there is nothing to attribute, the postback URL was never verified or has a typo, or a firing condition is silently dropping the request. Send a test conversion end to end and confirm the same event lands in both systems.
Two reasons. Double-counting, where the same event fires more than once without deduplication, and attribution overlap, where platforms with different windows or models each claim the same sale. Deduplicate by a unique transaction or event ID, and pick one source of truth rather than summing across channels.
Not entirely — some users decline tracking or block it, and that is a permanent feature of the web, not a bug. You can recover much of it by moving measurement server-side, so the conversion signal no longer depends on the browser cooperating. Treat the remainder as a known, quantifiable haircut rather than a weekly mystery.
If you run campaigns on gut feel, you are flying blind with your own money.
Beginner · 6 min readHow affiliate tracking really works: clicks, click IDs, postbacks, server-to-server flows and why clean attribution is the foundation of a profitab...
Core · 10 min readWhat a tracking pixel is, how it fires in the browser, how it differs from server-to-server tracking, and where the Meta Pixel, the Conversions API...
