Ad blocking: why your RPM looks fine while your earnings fall
Reported RPM divides revenue by impressions that were actually served. Revenue per visitor divides it by everyone who arrived. Blocked visitors are missing from the first and present in the second, so a rising block rate moves your earnings while leaving the number on your dashboard completely unchanged.
- Take pageviews from analytics and impressions from your ad account. Same date range, same property. These two numbers are measuring different populations, and the difference is the point.
- Divide impressions by pageviews. That ratio is roughly your served rate. One minus it is a floor on your block rate — a floor, not the number itself.
- Remember your analytics is blocked too. The same extensions that block ads block analytics scripts. Your pageview figure already excludes some of the people you are trying to count, which makes the calculated block rate lower than the real one.
- Use a server-side count if you have one. Web server logs or an edge analytics product count requests rather than script executions, so they see the blocked visitors your JavaScript analytics cannot. The gap between the two counts is itself informative.
- Track revenue per session, not just RPM. It is the number that moves when blocking rises, and the only one that answers "is this audience worth more or less than last quarter".
Two numbers, two denominators
Your ad account reports RPM as revenue divided by impressions served, times a
thousand.
The number that describes your business is revenue divided by visitors who
arrived.
For a site with no ad blocking these are the same thing. For every real site
they are not, and the distance between them is the share of your audience whose
browser removed the ads before they ever loaded.
The consequence is worth stating flatly, because it explains a very common and
very confusing experience:
A blocked visitor produces no impression. They disappear from the denominator
of reported RPM completely. They do not disappear from your traffic.
So a site can watch its block rate climb quarter after quarter, earn measurably
less per visitor, and see a reported RPM that never budges. Nothing is broken.
Nothing is misreported. The dashboard is answering a question you did not ask.
Measuring it, and why your first number is wrong
The obvious method:
served rate = impressions ÷ pageviews
block rate ≈ 1 − served rate
Take impressions from the ad account and pageviews from analytics over the same
range. If you served 700,000 impressions against 1,000,000 pageviews, roughly
30% of your audience saw nothing.
Now the part most explanations leave out: that 30% is a floor, not the
answer.
The extensions that block ads also block analytics scripts. Your pageview number
is already missing a chunk of the same people. You are dividing a deflated
numerator by a deflated denominator, and the result understates the problem —
sometimes considerably.
If you want a truer figure, count requests rather than script executions: web
server logs, or an edge analytics product that runs before any JavaScript. The
gap between your server-side count and your JavaScript count is itself a useful
signal, and on a technical audience it can be startling.
What this changes about decisions
Judge changes on revenue per session. If you move a unit and reported RPM
improves, you have learned something about the impressions you serve. You have
learned nothing about whether the site earns more. Revenue per session answers
the second question, and it is the one that pays.
Read niche RPM figures with the denominator in mind. Published CPC tables
describe clicks. They say nothing about how much of a niche's audience is
reachable at all — which is why technology and gaming earn so
much less than their advertiser rates imply, and why
food earns so much more than its unremarkable CPCs
suggest.
Treat blocking as an audience property, not a problem to solve. It is a
consequence of who reads you. That makes it a factor in choosing what to write
about — and a much better lever than trying to defeat it.
On anti-adblock walls
The tempting response is detection: notice the blocker, demand it be turned off,
withhold the content.
Worth weighing honestly before you build it. It is an arms race you do not win
permanently. It damages the experience specifically for technically-minded
readers, who are disproportionately the people who link to and share work. And
in some jurisdictions the detection mechanism itself has attracted legal
challenge.
Some publishers make it work, generally with a polite request rather than a wall.
Most get further by accepting the constraint and choosing formats and topics
where it bites less.
The connection to everything else
Blocking is a slow slope, not a cliff. That matters for diagnosis, because it
tells you which kind of problem you are looking at.
If revenue per visitor has slid gradually over a year, blocking is a strong
candidate. If it fell on a specific date, it is not — that is
mechanical, and the first thing to check is whether
your ads.txt still contains every line it should.
Frequently asked
- Why does reported RPM stay flat while earnings fall?
- Because a blocked visitor produces no impression at all. They vanish from the denominator of reported RPM entirely, so the average across served impressions is unaffected. They do not vanish from your traffic, so revenue per visitor falls. Both numbers are correct; they answer different questions.
- How do I measure my actual block rate?
- Compare impressions from your ad account against pageviews from analytics over the same period. The shortfall is a floor on your block rate. It is a floor rather than the answer because the analytics number is itself deflated — the same extensions block it.
- Should I use an anti-adblock wall?
- Weigh it carefully. Detection scripts are an arms race, blocking-the-blockers damages the experience for the audience most likely to link to and share your work, and in some jurisdictions the detection itself raises legal questions. Most publishers get more from choosing formats and topics that attract a less block-heavy audience.
- Which niches lose the most to blocking?
- Technology and gaming, by a wide margin — technically capable audiences who installed a blocker years ago and never thought about it since. Food, parenting, home and general lifestyle lose far less, which is part of why their real earnings often beat their published CPCs.