Measuring the True Revenue Impact of Ad Blockers

You cannot recover revenue you do not know you are losing. Most gaming publishers have a vague sense that ad blockers cost them money, but when pressed for a number, they guess, and in our experience they usually guess low.

The reason: your ad platform only reports served impressions. It cannot report the impressions it never had a chance to serve. Your analytics platform reports pageviews from visitors with and without ad blockers. The gap between those two numbers is your ad-block loss.

Here is how to measure it accurately, calculate the dollar impact, and build a business case for investment in recovery. All the figures in this post come from one illustrative example site, so you can follow the math through every step and swap in your own numbers.

The Example Site

Every table below uses the same hypothetical gaming site:

• 5,000,000 monthly pageviews tracked in analytics
• 38% ad-block rate (gaming audiences commonly block at roughly 30–45%, against 15–30% on the general web)
• $10 page RPM (revenue per 1,000 pageviews on pageviews where ads load, blended across geographies)

We use pageviews throughout. If you prefer sessions, the same method works, but use session RPM (revenue per 1,000 sessions) consistently; never mix a page RPM with a session count.

Why Standard Reporting Underestimates the Problem

Your ad server (Google Ad Manager, a header bidding wrapper or a direct SSP) reports impressions served and revenue earned. These numbers are accurate for the pageviews where ads loaded.

Your analytics platform (Google Analytics, or equivalent) reports total pageviews, including those from visitors with ad blockers. These numbers are also accurate, apart from visitors who block analytics too (more on them below).

The problem is that most publishers look at one or the other, not both together. The ad server numbers feel complete because they show impressions, CPMs and revenue in tidy reports. But those reports have a blind spot the size of your ad-block rate.

On the example site, 38% of 5,000,000 pageviews means ads load on only 3,100,000 pageviews. The other 1,900,000 are invisible to your ad server. Any RPM your ad server reports is calculated on the 3.1 million pageviews it saw, so it overstates what you earn across your whole audience.

Step 1: Measure Your Actual Ad-Block Rate

You need a measurement of your own traffic, not an industry average. Your ad-block rate depends on your audience, traffic sources, device mix and geography. Here are three methods.

Method A: Ad-Block Detection Script

Deploy a lightweight JavaScript detection script that checks whether a known ad element loaded. The standard approach:

1. Create a "bait" element: a div with class names that ad blockers commonly target (e.g., ad-banner, ad-container, adsbox).
2. On page load, check whether the element was hidden or removed by the ad blocker.
3. Log the result (blocked or not blocked) to your analytics platform as a custom event.

Some blockers are good at ignoring bait elements, so use more than one signal:

• Test bait element visibility (primary signal)
• Attempt to load a script from a known ad domain and check whether it fails (secondary signal)

No detection method is perfect, so treat the result as a close estimate. In the EU, running detection code on a visitor's device may itself require consent under ePrivacy rules; check with your legal adviser before deploying it there.

Method B: Analytics vs. Ad Server Comparison

Compare total pageviews in your analytics platform against total ad impressions in your ad server. It is less precise, but it works without deploying any new code.

The formula:

Estimated ad-block rate = 1 - (monetized pageviews / total pageviews)

Where "monetized pageviews" is calculated as:

monetized pageviews = total ad impressions / average impressions per non-blocked pageview

Example: Your analytics shows 5,000,000 pageviews. Your ad server shows 18,600,000 impressions. Your average impressions per non-blocked pageview (including refreshes) is 6.

monetized pageviews = 18,600,000 / 6 = 3,100,000
ad-block rate = 1 - (3,100,000 / 5,000,000) = 38%

The weak point is the "average impressions per pageview" assumption, which varies by page type and session length.

Method C: Server Logs vs. Analytics vs. Ad Server

If you log page requests on your web server or CDN, compare three counts: server-side pageviews, client-side analytics pageviews and monetized pageviews.

Server logs capture everyone, whether they block ads, analytics or JavaScript. Suppose your server logs show 5,200,000 pageviews (after filtering out bots), your analytics shows 5,000,000, and ads load on 3,100,000:

• True audience: 5.2M pageviews
• Analytics-tracked: 5.0M (96%)
• Ad-monetized: 3.1M (about 60% of the true audience)
• Effective ad-block rate: about 40%

That is higher than the 38% from Method B because it includes visitors who block analytics as well as ads, a segment Methods A and B cannot see. The rest of this post uses the analytics-based 38% on 5,000,000 pageviews, so treat every loss figure as slightly conservative.

Step 2: Calculate Your Revenue Loss

Once you have your ad-block rate, the calculation is straightforward:

Monthly lost revenue = total pageviews × ad-block rate × page RPM / 1,000

But there are two versions of this calculation, and they produce different numbers.

The Simple Calculation

Uses your current page RPM as reported by your ad server:

5,000,000 pageviews × 38% × $10 page RPM / 1,000 = $19,000/month

The Adjusted Calculation

Your reported RPM reflects the visitors who do see ads. The ad-blocked segment can be different:

• Device mix: Ad-block users skew desktop, where CPMs are often higher than mobile.
• Geography: Ad-block rates differ by country, and so do CPMs.
• Engagement: Many ad-block users are power users with longer sessions.

Depending on your audience, the RPM that ad-blocked pageviews would have earned can be higher or lower than your reported RPM. Your segment data (Step 3) tells you which. As an illustration, suppose it is 15% higher:

5,000,000 × 38% × ($10 × 1.15) / 1,000 = $21,850/month

The difference is $2,850/month, or $34,200/year, that the simple calculation would miss.

Step 3: Segment the Data

Aggregate numbers are useful for the business case, but actionable recovery requires segmentation. The tables below split the same example site three ways. Every table adds up to the same totals: 5,000,000 pageviews, 1,900,000 blocked pageviews (38%) and $19,000 of lost revenue per month.

Device Type

Lost revenue here uses the site's $10 page RPM for every device, to keep the example simple. In practice, use each segment's own RPM, as the geography table does.

Desktop is where most of your ad-block loss sits. Mobile rates are lower because most mobile browsers, including Chrome on Android, do not support ad-blocking extensions. Mobile blocking comes from browsers with built-in blocking (such as Brave), content blockers in Safari on iOS, and network-level blockers.

Traffic Source

Again at the $10 page RPM:

This kind of split often shows that your most loyal traffic (direct, returning users) and community referrals (Reddit, Discord) block the most. Returning users are the ones most worth recovering, because they visit frequently and have high lifetime value.

Geography

Here each region uses its own page RPM. The regional RPMs are chosen so they blend back to the site's $10 page RPM on pageviews where ads load, which is why the total still matches.

US and European traffic drives most of the loss in this example, because those regions combine meaningful ad-block rates with the highest RPMs. Recovery efforts targeting them have the highest return.

Step 4: Build the Business Case

With measurement and segmentation in hand, you can build a business case for recovery that is not based on guesswork.

The Investment

Ad-block recovery typically involves some combination of:

• Detection scripts: Low cost (open-source options exist, or build your own)
• Acceptable Ads: Free for most participants; larger entities pay a licensing fee to eyeo, which operates the program
• Anti-ad-block technology: A monthly fee to a provider, usually scaled to traffic, plus integration work
• Value exchange implementation: A one-time development cost

Get real quotes for your traffic. The costs in the table below are placeholders to show the method.

The Return

For the example site's $19,000/month in ad-block losses. The recovery shares are illustrative assumptions, not measured rates; your results will depend on your audience, your blockers and your provider.

Monthly net is monthly recovered minus monthly cost; payback is the one-time cost divided by monthly net. The full-stack recovery is less than the sum of the three rows (5% + 20% + 40% = 65%) because the layers overlap: each one can only recover traffic the others missed. If you are large enough to owe an Acceptable Ads licensing fee, deduct it from that row.

In this example every approach pays back its setup cost within a few months. Your version of the table, with your own quotes and a measured recovery rate from a test, is what decides how aggressively to invest.

Presenting to Stakeholders

If you need executive or team buy-in, frame it this way:

1. Current state: "We earn $X/month from advertising. Our ad-block rate is Y%. We are losing about $Z/month in unrealized revenue."
2. The gap: "Our analytics shows [N] pageviews per month. Our ad server only monetizes [M] of them. The gap is [N−M] pageviews."
3. The opportunity: "With [recovery approach], we expect to recover [percentage] of that gap, adding [$amount]/month for a one-time cost of [$setup] and [$cost]/month."
4. Proof of concept: "We can test the detection script and polite messaging in one sprint to validate our ad-block rate before committing to larger investments."

Step 5: Monitor Ongoing

Ad-block rates are not static. They shift with:

• Browser changes: Chrome finished removing Manifest V2 extensions in 2025, including the original uBlock Origin; uBlock Origin Lite and other Manifest V3 blockers still block most ads. Expect a shift in which blockers your visitors use rather than an end to ad blocking.
• Ad-blocker releases: New blockers or major updates to existing blockers can spike your rate.
• Traffic source shifts: If you start getting more traffic from communities like Reddit or Discord, your ad-block rate will likely rise.
• Audience changes: Ad-block rates tend to be stable month to month but move when your audience composition changes.

Set up a monthly reporting cadence:

• Total pageviews vs. ad-monetized pageviews
• Ad-block rate by device, source and geography
• Recovery rate by approach (if you have implemented any)
• Net revenue impact (lost minus recovered, minus recovery costs)

Track these numbers the same way you track RPM and fill rate. They are just as important to your revenue picture.

What to Do Next

Your ad server cannot show you what it never had the chance to serve, so looking only at its reports understates your ad-block loss. Measure your actual ad-block rate, calculate the dollar impact with your own traffic and RPM, segment it to find where recovery pays best, and build a business case that includes every cost: you are losing $X, you expect to recover $Y, and it will cost $Z up front plus $W a month.

For the options on the recovery side, read our guide to anti-ad-block strategies that don't alienate your players, or see publisher results.