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.
This applies not just to programmatic ads served through JavaScript tags, but also (1) internal promotions delivered through a third-party ad server and (2) custom native advertising platforms built in-house.
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.
It’s not as simple as "ad blockers block JavaScript ad tags from firing.” In fact, different browsers block ads in different ways, not all ad blockers stop the same ads, and upcoming Google Chrome changes (Manifest V3) will upend the process sometime in 2020.
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.
1. HTTPS Request Blocking - Here, the extensions listen to outgoing HTTPS requests and block any from known ad platforms. As much of advertising relies on JavaScript ad tags - which ping the specific endpoints of Google Ads Manager, AppNexus, etc - it’s easy for ad blockers to identify these outgoing requests and tell the browser not to load them. For instance, many brands that do Header Bidding - a popular method for programmatic publishers to drive more revenue - use an open-source tool called Prebid.js. Due to this, the filter list has a rule that looks for the regex of "/prebid". Any time "prebid" is in the outgoing URL, that request is blocked, which would impact any ad exchange or wrapper set-up that includes this phrase anywhere in the server request.
It’s important to note that the software will block anything delivered through the tags. If you are using Google Ads Manager to deliver both programmatic ads AND internal/in-house content, for example, the latter will still be blocked because it’s delivered through the same tag, even if it’s not technically an ad.
2. CSS Rules To Hide Elements - Since some companies display custom native ads through an in-house ad server (and therefore don’t use third-party HTTPS requests), ad blockers have to find an alternative route to stop these promotions.
To do this they use regexes to identify specific CSS elements or "div classes" and then append a CSS rule of {display:none!important} to the CSS stylesheet before sending everything over to the browser to render. This rule tells the browser to hide any instance of that CSS, preventing the ad from appearing.
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 ""Promoted"".
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:
On top of EasyList, most blockers incorporate additional lists, such as EasyPrivacy (blocks trackers), EasyList Cookies (blocks cookies), and Fanboy’s Social Blocking List (blocks social buttons).
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.
One final note about this process: in early 2019 Google announced a breaking change for how extensions work in Chrome, called Manifest V3, which is in beta and expected to launch in 2020.
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.
After announcing this change, Google received much criticism and has since enacted edits (like increasing the number of allowed rules from 30K to 150K, which should cover the EasyFilter list).
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:
Two of the next largest browsers - Opera and Brave - account for about 2% of browser share and have built-in ad blockers. Opera uses EasyList by default, while Brave is a proprietary list.
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.
DNS ad blockers require users to install them as their DNS server. Examples include AdGuard DNS and Pi-Hole (for Raspberry Pi).
Given how VPN/DNS ad blockers work, they would stop request-based ads, but not in-house native ads.
Here’s a quick summary:
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.
If you have built your own ad platform and have full control over the demand, you can apply directly via this form. Before sites are whitelisted, they are submitted to a public forum for review.
That said, joining this program won’t be a perfect approach in isolation, as:
If you rely on programmatic demand, you could alternatively work with dedicated Ad Recovery Providerslike Blockthrough, Admiral, or AAX Exchange, who will handle the application process for you.
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.
1. Request and serve ads server-side through your own CMS or backend application, not through JavaScript tags that ping a specific endpoint.
2. For impression tracking, avoid obvious impression pixels and employ an "onload" script that fires after rendering.
3. For click tracking, strip the on-page URL so the click goes straight to the destination. Then fire an "onclick" script to proxy the correct tracking URL.
4. Employ the same element names for organic and sponsored content.
5. Incorporate the ad label in a way that’s difficult to identify with a regex.
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:
etsy.com#?#a.listing-link:-abp-has(span:-abp-contains(Ad))
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.
