Every popunder network sells you clicks. Almost nobody measures what happens in the two seconds after the click. We instrumented a live campaign for 24 hours, joined every visit end to end, and found that a third of the traffic we had already paid for and approved never issued a request to the destination at all.
The advice everyone follows — and why it is wrong
Search for pop-traffic tracking guidance and you will meet the same claim on almost every network blog: on pops, a click means the same thing as a visit or an impression, because the user lands on the page automatically without clicking anything. Several guides go further and advise you to disable the click parameters in your tracker so the two numbers stop confusing you.
That advice is built on an assumption nobody measured: that a pop click and a landing-page visit are the same event. Our data says they are not the same event, and the gap is not small. Of 924 accepted pop clicks, 305 never produced a destination request at all. If a click equalled a visit, that number would be close to zero.
The reason this myth survives is that switching off the click parameter removes the only evidence that would expose it. You stop seeing the discrepancy, so you conclude there was none. The discrepancy is still there and you are still paying for it.
The problem nobody logs
You own two numbers and you trust both: the clicks your source bills you for, and the sessions your analytics reports. When they disagree — and they always disagree — the industry offers comfortable explanations. Bots. Adblock. Sampling. Bad zones.
None of those are measurements. They are guesses that happen to be unfalsifiable, which is why they survive. The real question is simpler: after your filter says ACCEPT and your server issues the redirect, does the browser actually fetch the destination?
For months we could not answer that, for a boring structural reason: nothing joined the acceptance decision to the arrival. Two unrelated populations divided by each other produce confident numbers and no knowledge.
The method, not the opinion
This is the measurement discipline PureGuard now applies to every delivery route it protects, and it was built the slow way: months of production traffic, several wrong conclusions, and a few reporting bugs of our own that had to be found and fixed before any number could be trusted.
- One identifier per accepted visit that survives the redirect — we reused the click token the source already sends, so nothing new is minted or exposed.
- Log it on the accept side, in the row that already holds trust score, ASN, ISP, country and user agent.
- Join it to the destination web-server log, which already records the same token.
- Deduplicate every stage to one visit before computing any rate. Skipping this is how people end up with funnels where a later stage is bigger than an earlier one.
What 924 accepted visits actually did
| Stage | Visits | Share of accepted |
|---|---|---|
| Accepted by the filter | 924 | 100% |
| Server issued the redirect | 886 | 95.9% |
| Client aborted before receiving it | 48 | 5.2% |
| Requested the destination | 619 | 67.0% |
| Destination returned success | 587 | 94.8% of arrivals |
| Page rendered (DOM / first paint) | 420 | 45.0% |
| Visible at least one second | 394 | 42.2% |
| Full confirmed render | 391 | 41.9% |
Read the fourth row again. One in three accepted, paid-for visits never made a request to the destination. Not blocked. Not bounced. Not a slow page. No HTTP request was ever issued.
The loss was our own architecture
Our first instinct was the industry-standard one — bad zones, bots, junk sources. The data killed that within an hour.
The campaign ran through an intermediate “bridge” page: a small HTML interstitial between our redirect and the destination, added months earlier for legitimate browser-protection reasons. On paper, harmless. In the logs, catastrophic. It ended with a JavaScript hop, a 2-second meta-refresh fallback, and a manual link — all three require the browser to do something after the page loads.
Pop traffic is exactly the traffic that cannot be relied on to do anything after load. A popunder opens in a background tab. Background tabs get throttled, suspended and discarded by every modern browser. A JavaScript navigation in a suspended tab does not run late — it frequently never runs.
We froze the bridge architecture as a baseline cohort, then replaced it with a plain server-committed HTTP 302, where the server names the destination in the redirect header and the browser has nothing to decide.
| Metric | Bridge page | Server 302 | Change |
|---|---|---|---|
| Destination arrival | 52% | 67% | +15 pts |
| Page rendered (DOM/FCP) | 31% | 45% | +14 pts |
| Visible ≥1 second | 29% | 42% | +13 pts |
| Full confirmed render | 29% | 42% | +13 pts |
All four differences are statistically significant (two-proportion z-tests, p between 0.0006 and 0.006). On that one campaign the change produced roughly 140 additional destination arrivals and 116 additional confirmed renders in 24 hours from identical spend.
The rule
On pop traffic, the server must commit the delivery. If any step requires the browser to act, you lose the visits that were already suspended — and that is a large, systematic share, not an edge case.
This is not only about bridge pages. Meta-refresh chains, JavaScript redirect hops, click-to-continue interstitials, cookie-sync detours and “checking your browser” screens all carry the same tax. Each converts a guaranteed server action into a hopeful client action.
What is still missing, honestly
We did not solve everything. About a third of accepted visits still never request the destination even with a clean server redirect. We classified them exactly:
- Client aborted before the redirect arrived — HTTP 499 in the server log, roughly 5% of accepted visits.
- Redirect issued, destination never requested — the large remainder.
- Wrong endpoint, dead destination, expired signature, logging miss, broken identity join — each tested individually, each returned zero.
So the loss is real, client-side, and happens after a valid redirect to a healthy destination. Whether that is users closing tabs, browsers discarding them, or something else is not observable from the server, and we will not dress a hypothesis as a finding. Early identity data is suggestive in one direction: the missing visits are high-trust, residential, spread across many networks and zones, with no repeated client fingerprints — which is not what a bot population looks like.
What to do with this
- Count your own funnel: accepted → redirect issued → destination request → render. If you cannot produce those four numbers for one campaign, that is the finding.
- Remove every browser-dependent hop between your decision and the destination.
- Join on one identifier per visit and deduplicate before you divide.
- Never report a stage your route cannot measure as 0%. Report it as not available — a zero claims a failure you never measured.
The uncomfortable part: the biggest single leak was not the traffic source, the zones, or the bots. It was a well-intentioned page we had added ourselves.
If you want the same funnel measured on your own traffic without building the joins yourself, that is what PureGuard does — and the companion piece, why “no render” is not a bot signal, explains why the render half of this funnel is so easy to misread.