As you look to monetize your site with ads, it’s important to understand how adblock works and how it could impact your revenue - and what you can do to mitigate this pain.
I’ll be focusing here on desktop, browser-based ad blocking, but you can read about mobile ad blocking here.
Table of Contents:
Ad monetization relies on ads being shown and tracked (and ideally seen and interacted with). For this to happen, not only does the ad need to appear, but the tracking impression pixel needs to fire. Ad blockers prevent both from loading - meaning you’d make no ad revenue for that user’s session.
Ad block usage rates vary by the source. GlobalWebIndex in 2019 pegged it at 35%-40% across every continent, while Statista and eMarketer put it closer to 25%-30%. I have not seen any recent data that puts it below 20% or above 50%.
While there are no recent market share breakdowns, we have a few data points. First, there’s this 2015 breakdown, with AdBlock, AdBlock Plus, and AdBlock Pro (all different companies) comprising 93% of the market.
This Uponit 2017 report meanwhile shows that AdBlock, AdBlock Plus, and uBlock account for about 80% of ad blockers.
Finally, we can look at current Google Chrome extension download counts. No other ad blocker had more than 1MM downloads.
From this, it’s fair to assume that AdBlock Plus, AdBlock, and uBlock are the three giants in the desktop space. As most ad blockers behave similarly, though, it doesn’t particularly matter which ad blocker your users use - only that they do use one.
Below outlines the different types of ad blocking tech. First, though, here's the current market share breakdown for desktop browsers.
For about 90% of the browser market, ad blockers work as free downloadable browser extensions. Before any content is rendered by the browser, these extensions listen to/watch what’s loading, compare that to a filter list, block any matches, and then tell the browser what to render.
Depending on the rule, the ad blocker may leave just an empty space where the ad would have gone, replace it with different content, leave parts of the ad and hide others, or hide the element so there’s no awkward white space.
These tools block ads via one of the two below methods. With both, the software is using regexes (regular expressions) to identify what to block.
These large publishers all built custom, native ad platforms, but their ads still get blocked because they use ad-specific CSS that blockers can identify.
For instance, one actual regex filter they use is:
This is a complicated regex that looks for any on-page
div class on
twitter.com that has a value of
data-test-id="trend" AND which, somewhere nestled in that div class, contains the phrase
Doing a filter for that regex isolates just the ads on Twitter's site - specifically their Promoted Trends ad unit. With the CSS hiding method, ad blockers then instruct the browser not to render the native ad.
I've additionally highlighted in this video how AdBlock Plus stops Google's native search ads from appearing.
Many publishers believe that building their own ad platform means they don’t need to worry about ad blocking, because they aren’t using a third-party ad tag.
To identify what to block, nearly every ad blocker (including the six above) pulls from the same regex list, called EasyList, which contains about 70K expressions like:
These filter lists are manually compiled because AI/ML is imperfect when it comes to differentiating between an ad and standard promoted content. EasyList is maintained through a user community that identifies unblocked content, which is reviewed and potentially added to the list.
I won’t get too technical here, but instead of being able to tell the browser what to render, extensions will now just provide a list of rules in a JSON file requesting what requests/elements should be blocked. Chrome, then, gets the final say on what loads.
But since Chrome is 70% of the US browser market, it’ll be important to watch if Manifest V3 makes it harder for ad blockers to work properly.
Apple’s Safari captures about 5% of the US desktop browser market. Safari’s ad blocking extensions work a little differently than those above: they are downloaded via the Mac App Store and have a corresponding Mac app that connects to Safari.
Some key notes:
I found that these tools worked well for the HTTPS request blocking method, but the native ads on Google, Twitter, Amazon, and others appeared. It’s possible that these built-in blockers don’t employ the CSS element hiding strategy.
Also - technically Google Chrome has a built-in ad blocker, its Better Ads Standard initiative, released to global markets in July 2019. It works differently than other tools, in that:
Due to this implementation, it’s estimated only 1% of publishers were impacted by Chrome's built-in blocker.
VPN (virtual private network) ad blockers work through VPN clients. They block ads by stopping or redirecting DNS (domain name system) requests to ad network servers. Examples include CyberGhost, NordVPN, Perfect Privacy, and Private Internet Access. A more detailed summary can be found here.
Given how VPN/DNS ad blockers work, they would stop request-based ads, but not in-house native ads.
Here’s a quick summary:
|Type||Desktop Market Share||Block Programmatic Ads||Block In-House Native Ads|
|Browser Extensions (Chrome, Firefox, MS)||90%+||Yes, via pre-identified third-party ad vendor codes||Yes, but ad blockers have to manually identify each publisher's code and add to EasyList|
|Mac App (Safari)||5%||Yes||Technically yes, but limited in execution|
|Built-in ad blockers (Opera, Brave)||2%||Yes||No|
Your revenue impact from ad blockers will depend on your traffic’s mixture of browser usage, ad block adoption rates, and type of ad blocker usage.
To get a rough estimate, here are some ideas:
The easiest way to see browser breakdown is via your analytics solution, like Google Analytics. Within GA you can go to Audience → Technology → Browser & OS. You’ll then want to add a “Secondary Dimension: Users - Device Category” so you can see the desktop breakdown too.
To see what % of your traffic uses an ad blocker, you could:
If you have very low rates, you may not need/want to take mitigating actions; otherwise, see below for strategies to monetize your ad block users.
The Acceptable Ads program is a non-profit founded by eyeo, the creator of AdBlock Plus.
It’s a way for publishers to pay to have their ads whitelisted by ad blockers (aka, not blocked). This is done through a “Allow NonIntrusive Advertising” txt file that ad blockers reference alongside EasyList. This whitelist supersedes EasyList, so if the latter blocks it but the former allows it, the ads would appear.
All three of the top ad blockers - AdBlock, Adblock Plus, and uBlock - are in the program, and the setting is enabled by default upon downloading the extension (though users can opt-out by visiting their settings). While some users may manually disable this feature, it’s likely that most do not.
Given this, making it onto the whitelist means you can instantly monetize potentially 80%+ of your ad block desktop traffic.
To join, publishers must have ads that meet their Acceptable Ads Standard.
If you’re building a user-first native ad product, it’s likely you’ll be eligible. If you’re using programmatic ads, you’ll have to be diligent with where you place them and with whom you work.
Anyone with fewer than 10 million affected monthly impressions can join this program for free. According to them, 90% of their whitelisted sites fit into this bucket.
Many of the world’s largest publishers are members of AA, such as Amazon, Google (their search ads), and eBay. You can see this by toggling on and off the “Acceptable Ads” button in AdBlock Plus or by looking into the “Allow NonIntrusive Advertising” txt file.
The program is not without controversy. Large publishers view it as a form of extortion, and there are instances where AA appears to enable paying members to show ads that don’t meet their acceptance criteria. For example, in this video, Buzzfeed’s Tasty.co ads are getting whitelisted, even though they appear to violate the Acceptable Ads Standard.
If you are a small-to-medium company showing user-friendly ads, this is one of your easiest routes to ad block monetization.
That said, joining this program won’t be a perfect approach in isolation, as:
Such tools help get ad blockers to whitelist you, and since they work with more ad blockers than just those that support AA, they could unlock inventory that AA whitelisting alone wouldn't.
Here, you identify who’s using an ad blocker and then prompt them with a dialog box. This message could include:
There are many third-party tools for this, including Admiral and Google Funding Choices. Or you could build the platform yourself. Advice on how to detect ad blockers in real-time can be found here, here, and here.
These notifications have, unsurprisingly, led to a number of anti-anti-ad-blockers that prevent these prompts from appearing, limiting the efficacy of this approach.
The idea here is that if you can’t monetize them with ads - perhaps you monetize them via other means, such as replacing ads with internal promotions that upsell paid products.
NYTimes.com, for example, could substitute their programmatic ads with promotions for their paid Crossword and Recipe add-ons.
Alternatively, your “ads” could tout your ad-free membership plan, an e-mail mailing list, a social follow, an app download, and so on.
Let’s imagine a company whose users skew toward using ad blockers - such as 70% - and they don’t want to join the Acceptable Ads program. Perhaps the best strategy is to find a new monetization route altogether, such as a membership/subscription fee gated by a paywall. You can find a list of third-party paywall vendors here.
That said, even companies with a paywall - like The New York Times - show ads to supplement their revenue, so it’s rarely an either/or approach.
If you are creating your own video and podcast content, you could insert ads directly into the video/audio streams at time of uploading or in real-time using Kevel’s APIs.
Ad blockers look for HTTPS requests and on-page elements; as thus, they can’t block ads within audio/video streams without blocking the whole content (assuming you are compiling the stream on the backend versus using a video ad network tag).
Such a path is applicable to only a sliver of publishers, but is nonetheless one strategy to recoup income lost from ad-blocked display ads.
You can, of course, view lost revenue due to ad blockers as a cost of doing business. This may also stem from wanting to respect your users’ ad blocking preferences.
Twitter, for instance, is not in Acceptable Ads and is not exploiting any ad block loopholes - so their ads, such as their Promoted Trends ad unit, get blocked.
It’s possible this never happens, so doing nothing may be the easiest approach to start with.
In this strategy, you structure your site’s code in a way that’s difficult for ad blockers to find a working regex filter to add to EasyList.
It’s specifically for companies that have built their own ad servers, either entirely in-house or through Kevel’s APIs. Usually this corresponds to user-first, native ad units like sponsored listings, promoted posts, sponsored content, and so on.
Before I pursue this strategy, I want to make a few points:
In order for this strategy to work, you’ll want to take the below steps.
onloadscript that fires after rendering.
onclickscript to proxy the correct tracking URL.
To address the labeling issue, you could:
Huffington Post, for example, does this by having the “Paid Content” line be a part of the page flow and not tied to a specific ad element. There is no code difference between the organic articles above "Paid Content" and the sponsored content below the header.
An ad blocker could theoretically build an expression to block the ad - but in doing so it would block all the organic articles too.
There’s a bit of game theory here, then: does the blocker go conservative with its rules to prevent false positives (aka, organic content being blocked), or do they take a liberal approach to make sure they are catching all ads?
The most complicated route is extensive code obfuscation enabled by scripts, randomized ID strings, and/or purposefully-obscure code. This is a true cat-and-mouse game employed by the largest ad platforms, including Etsy and Facebook (neither get their ads blocked, and neither is on the AA list).
In Facebook’s defense, with $71B in digital ad revenue in 2019, the Acceptable Ads fee would likely be in the billions - so finding a workaround justifies the effort.
Diving into how they do it, their set-up looks to involve appending the "Sponsored" tag post-load with an event script. Meanwhile their sponsored posts have the same CSS as organic posts, so the blockers have no way of easily stopping them. This video dives into how Facebook does it.
Etsy also has a native ad product that isn't blocked by ad blockers.
Their sponsored listing ads employ the same CSS as their organic listings, with the only difference being the word "ad" attached to the top left.
Diving into the EasyList filters, it looks like at one point the community picked up on this and added this filter:
This regex looks for that sponsored label and hides the element if found.
To combat this filter, Etsy cleverly restructured how this "ad" is appended to the listing, so that the “a” and “d” characters are separated within the page’s code, but get placed together due to hidden span classes.
As such, the EasyList filter no longer works, and Etsy can monetize ad block users.
It remains to be seen if these workarounds can outsmart regexes for good, or if it'll be a constant cycle of blockers finding new things to hide and publishers finding new ways of serving the ads. If you're large enough, this game might be justified; otherwise it does come with the risk of engineering time and effort.
No matter what route you take, it’s important to QA your ad experiences across a variety of permutations to catch any bugs or layout issues.
For instance, while most browser/ad blocker combos led to the Amazon ads being hidden and replaced by organic content (so that the user experience is seamless), the combo of Ghostery and Safari leads to the below situation, offering a less-than-pretty browsing experience.
And on Politico.com you have this blocked ad that's effectively just as obtrusive as the actual ad.
This means you’ll want to periodically test if your ads are getting blocked (and across different browsers and blockers) and fix anything that's broken as needed.
Whether you hate or love them, ad blockers are here for good. Their growth was predictable as soon as publishers started overloading their site with ads to maximize revenue.
This came at the cost of poor user experiences due to jumpy content, slow pages, malware, inadvertent PII-sharing, creepy retargeting ads, and obtrusive pop-ups/animations. Software to block such experiences was inevitable.
As you look to mitigate your revenue loss from ad blockers, it'll be important to review your own ad experiences. If you believe your users are frustrated by your current ads, there's an opportunity to incorporate more user-first, native ads that users won't mind.
Such a move could lead to happier users/visitors, as well as more revenue if you're able to start monetizing ad block users.
Chris has worked in ad tech for over twelve years in a variety of roles - giving him customer support, PM, and marketing perspectives from both the advertiser and publisher sides. He's the VP of Marketing at Kevel.