Somewhere in every traffic-quality dashboard there is a metric called render rate, and somewhere in every media buyer's head is the belief that low render means bots. We believed it too. Then we measured it per visit, and the belief did not survive.
The seductive, wrong inference
A real human loads a page. A real page runs JavaScript. Our beacon fires. Therefore a visit with no beacon is not a real human.
Every step is plausible. The conclusion is wrong, and on pop traffic it is wrong often enough to wreck your zone list. A missing beacon has at least six causes and only one is “not a real human”:
- The tab was suspended or discarded before the script ran — the normal life of a popunder.
- The user closed the window before parsing finished.
- The beacon was blocked by a filter list, extension or strict privacy mode.
- The page was served but the visit never reached the element carrying the marker.
- The identifier that would attribute the beacon was missing, so it landed unattributed.
- It genuinely was automation.
A metric that cannot distinguish six causes is not a bot detector. It is a measurement coverage metric wearing a bot detector's uniform.
It is worth reading how the wider industry frames this. Standard viewability guidance — see AdPersonam's viewability guide — is written around display and video inventory that sits in a foregrounded tab, where an unfired beacon really is anomalous. Popunder inventory breaks that assumption at the format level: the tab is backgrounded by design. Applying a foreground-tab viewability standard to a background-tab format is how a perfectly ordinary human visit gets scored as fraud.
That gap is the reason PureGuard spent months rebuilding measurement before touching detection thresholds — the filter was never the weak link, the evidence model was.
Render can be inverted
The most expensive lesson of this work: render rate can be inverted relative to quality. Low render can be real humans on suspended background tabs — the definitional behaviour of the format you deliberately bought. High render can be an automation fleet, because executing JavaScript is trivial for a headless browser and hard for a sleeping phone.
Block on low render and you will systematically remove real humans and keep the sophisticated bots — while your revenue falls and your quality score rises. That is the most demoralising possible outcome, because every number on screen says you are winning.
Fix the definitions before the traffic
| Signal | What it proves | What it does not prove |
|---|---|---|
| Destination request | The browser asked for the page | That anything was displayed |
| Destination 2xx | The server answered successfully | That the client drew it |
| Parser marker (no-JS pixel) | HTML parsing reached that element | Final render or visibility |
| JS boot | JavaScript executed | That the DOM was ready or painted |
| DOM ready / FCP | The page rendered | That anyone could see it |
| Visible ≥1 second | It was on screen, foregrounded | Engagement or interest |
Rule one: full confirmed render must be a conjunction, on the same visit. Render evidence and visibility evidence for one identified visit — never the union of two beacon streams. We caught our own reporting claiming 31% full render while DOM/FCP and visible-1s each sat at 29% — arithmetically impossible for a subset, and purely an artifact of unioning sets. Under a strict conjunction the true figure was 29%.
Rule two: independent beacons are not a funnel until joined per visit. In our ledger, JS boot outnumbered the parser marker and visibility outnumbered DOM ready. As a funnel that is nonsense. Correctly read, they are separate streams with separate failure modes.
What the per-visit evidence showed
| Cohort | Visits | Share of arrivals |
|---|---|---|
| Both parser marker and JS | 449 | 72.3% |
| No parser marker and no JS | 134 | 21.6% |
| JS but no parser marker | 37 | 6.0% |
| Parser marker but no JS | 1 | 0.2% |
| Full confirmed render | 391 | 63.0% |
The 21.6% with no client evidence is the honest “no render” band — and we cannot tell you what those visits are, because by definition they produced no client-side witness. Anyone who tells you that band is bots is not measuring, they are asserting.
The 6% with JavaScript but no parser marker should be impossible if the marker fired for everything that parsed the page. It points at an instrumentation inconsistency in our own stack — most likely a marker in the page footer while JS boot fires from the head, so a visit abandoned mid-parse produces the second and never the first. We have not proven that, and we will not write it down as proven.
Unmeasurable is not zero
The most useful convention we adopted. If a route physically cannot produce a stage — a destination on someone else's domain where you can never run a beacon — that stage must display as not available, never 0%. Showing 0% claims a measured failure that was never measured, and somebody downstream blocks a zone because of it.
We enforced this after finding revenue and conversion rungs reporting a confident 0.0% for routes with no writer at all, and a funnel rung reporting 107% because two differently-scoped populations had been divided by each other. Those are not rounding errors. They are false statements about traffic quality, and they get acted on.
A practical checklist
- Never block on render alone. Require a corroborating signal a sleeping tab cannot fake — and remember a headless browser produces render evidence more reliably than a real phone.
- Separate cost signals from fraud signals. “No measurable browser evidence” is a fair reason to pay less. It is not evidence of fraud.
- Define full render as a conjunction and assert the invariant in code: it can never exceed either part.
- Check where your earliest marker sits. A no-JS marker in the footer measures parse-to-completion, not parse.
- Report coverage next to every rate. A rate computed on the joinable subset is not a platform rate.
The delivery half of this story — where a third of accepted visits vanish before the page is ever requested — is measured in our 924-visit popunder teardown.
After months of measurement the most valuable thing we produced was not a better bot filter. It was the discipline to say “we do not know” in a specific, bounded way instead of reaching for the nearest satisfying story. Render measures your instrumentation as much as the traffic. Fix the instrument first, then judge the traffic.