Your traffic source bills you for 8,000 clicks. Your analytics shows 900 sessions. Your offer shows zero conversions. Somewhere between those three numbers your money went, and every guide you have found so far says “it is probably bots” without telling you how to check.

This is a diagnosis, in order of likelihood. Each step is a check you can run yourself in a few minutes, with no product and no engineering. Work down the list and stop at the first one that fails — that is your problem.

6
Real Causes
1
Is Usually Yours, Not Theirs
20
Minutes to Diagnose

Before you start: get three numbers

Almost everyone debugging this argues from two numbers when the answer lives in three. Write these down:

The gap between A and B, and the gap between B and C, are completely different problems with completely different fixes. Conflating them is why most people never solve this.

Cause 1: Your redirect chain is eating the traffic

Check: Is B far below A? If your server received 5,000 requests for 8,000 billed clicks, roughly 3,000 visitors never arrived.

Why it happens: Popunders open in a background tab. Browsers throttle, suspend and discard background tabs aggressively. If anything in your chain requires the browser to act after the page loads — a JavaScript redirect, a meta-refresh, a “click to continue” interstitial, a cloaking script, a cookie-sync hop — a suspended tab never performs that action, and the visit dies silently.

The fix: Remove every browser-dependent hop between the click and your landing page. The server should name the destination in an HTTP 302 header, so the browser has nothing to decide and no script to run.

Why this is first: when we measured this on our own live campaign, an interstitial page we had added ourselves was costing 15 percentage points of arrival. Removing it moved arrival from 52% to 67% and confirmed renders from 29% to 42%, on identical spend. The largest single leak was ours, not the traffic source's. Full teardown: 924 clicks measured end to end.

Cause 2: You are comparing clicks to sessions and panicking

Check: Is B close to A, but C far below B? Then the traffic is arriving and your analytics simply is not recording it.

Why it happens: Analytics needs JavaScript to execute. A background tab may load the HTML and never run the tracker. Ad blockers strip analytics on a meaningful share of traffic. Users close the tab before the script fires.

The fix: Trust your server log over your analytics for delivery questions. Analytics undercounts by design on pop traffic. If B is healthy, your delivery is healthy — move to cause 5 or 6, because your problem is the offer, not the traffic.

Cause 3: Genuine bot traffic

Check: In your server log, count requests per IP and per user-agent string. Sort by frequency. Look for the same IP hitting dozens of times, or one user-agent string dominating an implausible share of visits.

Why it happens: Fraud is only profitable when it repeats. That repetition is the single most honest signal available to someone with no tooling — far more reliable than any individual “suspicious” attribute.

The fix: Blocklist the zones producing the repetition, not the individual IPs, which rotate. Judge at the zone level where evidence accumulates.

The trap: do not conclude “bots” from a low render or low JavaScript rate alone. On pop traffic that inference is often backwards — a real human on a suspended tab produces exactly the same silence as a bot, while a headless browser executes JavaScript flawlessly. Why no-render is not a bot signal covers this in depth, and getting it wrong means blocking humans while keeping the actual fraud.

Cause 4: Proxy-routed traffic that passes every check

Check: Look at the ISP and network for your traffic. If it all looks like clean residential broadband but converts at zero, ordinary reputation checks will not help you — they will keep saying the traffic is fine.

Why it happens: Residential proxies exit through real home connections. Geolocation, ASN classification and IP reputation all return clean results, and they are all technically correct. The IP is not the fraud; it is a borrowed exit door.

The fix: This is the one cause you probably cannot solve with server logs alone, and it would be dishonest to pretend otherwise. What you can do is compare zones against each other: a zone whose traffic looks statistically unlike every other zone from the same source is worth cutting even without proof of the mechanism. The full explanation, including the hard limit nobody admits.

Cause 5: Geo, device or targeting mismatch

Check: Compare the countries, devices and browsers in your server log against what your offer actually accepts. A surprising share of “bot traffic” complaints are desktop traffic hitting a mobile-only offer, or tier-3 geos hitting a tier-1 landing page.

The fix: Tighten targeting at the source before blaming quality. This costs nothing and is the second most common real cause after cause 1.

Cause 6: The offer or the landing page

Check: Load your landing page yourself on a mid-range phone over mobile data, not desktop wifi. Time it. If it takes more than a few seconds to become usable, a meaningful share of arrivals leave before it renders.

The fix: This one is unglamorous and frequently correct. If B and C are healthy and the traffic profile matches your targeting, the traffic is not your problem — the page or the offer is.

The order matters more than the list

Most people start at cause 3 because “bots” is the satisfying answer, and it requires no self-examination. In our own measurement the single biggest loss was cause 1 — our own architecture — and it was invisible until we counted requests instead of clicks.

Run the checks in order. Get A, B and C first. Nine times out of ten the answer is already visible in the gap between them, and you will have spent twenty minutes instead of another $200 finding out.

Further reading: ghost traffic explained · invalid traffic for media buyers · how to audit pop traffic for bots