Render Rate: The Only Pop Traffic KPI That Predicts Profit (2026 Data)

Every pop media buyer tracks CPM, CTR and conversion rate. Almost nobody tracks the number that sits underneath all three and quietly decides whether a campaign can ever be profitable: render rate — the percentage of paid impressions where your page was actually seen by a human for at least one second.

We instrumented a live production pop campaign end to end — every billed impression, every server arrival, every script execution, every second of real visibility — across more than 40,000 measured deliveries. This article publishes the full funnel, the number at the bottom of it, and the uncomfortable math of what it takes to move it.

What render rate actually is (and is not)

Render rate is not viewability in the display-ad sense, and it is not bounce rate. We define it operationally, because we measure it operationally:

• Delivered — your server returned the page with HTTP 200.
• Parsed — the browser began reading the HTML (a head-of-document marker fired).
• Executed — JavaScript booted.
• Rendered — the page was in a foreground, visible tab for at least one continuous second, confirmed by the Page Visibility API.

That last stage is the KPI. A pop impression that is delivered, parsed and executed in a background tab that the user closes unseen has cost you exactly as much as one a human read — and converted exactly as often as one that never loaded.

The measured funnel

Here is a representative 24-hour window from the instrumented campaign, per 100 delivered pages:

• 70 reached the parser (30 never executed a single byte — the tab was killed before parsing; see where pop traffic actually disappears)
• 69 booted JavaScript (parse-to-execute loss is tiny — this is not a broken-page problem)
• 43 were visible for at least one second
• 17 survived ten seconds or more in the foreground

So a buyer paying for 100 impressions received 43 rendered ones. Their effective CPM is 2.3× the sticker price before a single bot is counted. And this funnel starts at delivery — it excludes the billed impressions that never reached the server at all, which we cover separately in pre-arrival waste.

Why blocking cannot fix it: the 46.5% wall

The reflex answer is "block the bad zones." We tested that reflex exhaustively with a prospective simulation — policies that only use information available before each day's traffic, so no hindsight cheating:

• Current evidence-based blocking: 96% of traffic retained, 41–43% rendered.
• Block every zone trailing under 50% render: only 57% of traffic retained, 46.5% rendered.
• Block every zone under 66%: 34% of traffic retained — still 46.5%.
• Block everything under 80%: 28% of traffic left, and the rate fell to 43.7%.

Blocking 71% of a pop campaign's traffic lifted the render rate by less than four points. The loss is not concentrated in bad zones — it lives inside ordinary zones, as users who never foreground the tab. A blocklist cannot reach inside a zone.

This is the single most important finding for anyone who believes one more filter will fix their numbers. Filters remove fraud and junk — essential, and it is why the funnel starts as high as it does — but the remaining gap between 43% and 80% is human tab behavior, and it is bought, not filtered.

The part almost nobody knows: render quality is a stable zone property

Here is the good news buried in the data. When we measured week-over-week correlation of per-zone render rates, we got r = 0.82. Zones that render well keep rendering well. In our population, zones qualifying at ≥80% held ~80% on their next twenty deliveries. This means render rate is predictable enough to buy on:

• Our top persistent tier renders at 89% — more than double the broad average.
• A ≥70% tier held above 80% forward.
• A ≥60% tier held ~70% forward.

The catch — and any honest analysis must state it — is capacity. Those high tiers are a small share of total inventory (in our campaign, roughly 13–139 deliveries per day against a broad lane of ~1,100). A 90% lane at 1% of your volume is a research result, not a business. The play is a two-lane structure: a broad protected lane for volume, and a dedicated high-render lane bought from the persistent cohort — the full method is in the high-render whitelisting guide.

How to measure your own render rate this week

1. Delivery marker: log every 200 response server-side, keyed by a unique per-impression ID.
2. Parse marker: an inline beacon at the very top of <head> — before any script tag that can be deferred or killed.
3. Visibility marker: a beacon that fires only after the Page Visibility API reports one continuous foreground second.
4. Join the three by impression ID. Render rate = visible / delivered. Never substitute analytics sessions for any stage — analytics itself is stage 3 of a 4-stage funnel and silently merges every earlier loss.

If you cannot instrument this yourself, this is exactly the funnel PureGuard measures natively for every connected campaign — per zone, per day, with the persistent high-render cohort computed for you.