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.
The below article touches upon how ad blockers work and offers strategies for monetizing adblock users.
I’ll be focusing here on desktop, browser-based ad blocking, but you can read about mobile ad blocking here.
Table of Contents:
First off, why should I care about ad blockers?
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%.
Your exact ad block rates will depend on your site and audience make-up, but you should at least assume a not insignificant portion of your revenue could be nullified by ad blockers.
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.
|Ad Blocker||Total Downloads|
|AdBlock Plus (by eyeo)||10MM+|
|AdBlock (by GetAdBlock.com)||10MM+|
- AdBlock Plus (by eyeo) - 10MM+
- AdBlock (by GetAdBlock.com) - 10MM+
- uBlock Origin - 10MM+
- AdGuard - 6MM+
- Ultra AdBlock - 3MM+
- Ghostery - 2MM+
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.
Browser Extensions (Chrome, Microsoft Edge/IE, Firefox)
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.
In this scenario, the ad blockers have the final say of what’s shown - not the browser itself.
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.
- 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.
Element hiding allows ad blockers to block the native ads on Google, eBay, Reddit, Twitter, and many others.
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.
The truth is, with the CSS hiding capability, the blockers just need to identify any custom ad CSS and add it to their master regex list for the tools to work.
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.
These lists have to actively be maintained too. Many ad tech vendors strive to find ways to circumvent blockers, usually through switching up identifiers / element names / encrypting requests to their servers.
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.
I tested AdBlock Plus on Chrome’s Canary version that includes Manifest V3, and the extension worked as normal, so it’s unclear if this change will impact your ad revenue.
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.
Separate App (Safari)
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:
- Apple’s Safari works like Chrome’s Manifest V3 by default.
- They are Content Blocking Extensions that require the apps to tell Safari what regexes to block, versus being able to tell Safari what exactly to render
- Safari’s Content Blocking tools allow extensions to do request blocking and element hiding
- The blocking of native ads (via page elements) seems more hit and miss than other browsers. For instance, even though AdBlock Plus blocks the native ads of Twitter and Google on Chrome, it does not block them on Safari. Ghostery, meanwhile, caught Google but not Twitter. It’s unclear if this is due to a technical limitation or a stale regex list
- Safari’s rule list is capped at 50K, while the standard EasyList has about 70K, so the Safari block list also won’t be as holistic as on other browsers
Built-in browser ad blockers (Opera, Brave)
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:
- Google first grades a site on its overall ad experiences, looking specifically for universally-hated ad units like pop-ups, autoplay ads, and sticky ads (versus standard banner ads)
- If a site gets a failing grade, then moving forward Chrome automatically blocks ads on that page for any visitor, using EasyList
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.
While there are no public stats on VPN/DNS ad block usage, you can expect it’s very low.
|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:
Look at Google Analytics for browser details
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.
Understand ad block usage rates
To see what % of your traffic uses an ad blocker, you could:
- Add this .js file to your server
- Use Google Tag Manager
- Use this Adblock analytics dashboard
- Build your own solution
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.
Join the Acceptable Ads program (AA)
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.
For companies above that threshold, Acceptable Ads charges a 30% cut of all incremental revenue gained from being whitelisted.
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.
Larger companies, on the other hand, will have to weigh whether that 30% fee is high enough to warrant spending time building ad block workarounds.
That said, joining this program won’t be a perfect approach in isolation, as:
- Users can toggle off Acceptable Ads, so you can’t monetize those users
- While the three biggest blockers are in the program, smaller ones like Adguard and Ghostery are not
- It doesn’t address monetization of users with Brave/Opera or VPN/DNS ad blockers
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.
Prompt users to turn off the ad blocker
Here, you identify who’s using an ad blocker and then prompt them with a dialog box. This message could include:
- Asking them to disable the ad blocker, but letting them continue (a “soft” approach)
- Asking them to donate in some other fashion, but letting them continue
- Telling them the content is gated and unavailable unless they do 1 or 2 (a “hard” approach)
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.
Tread lightly, though: a 2017 Blockthrough report showed that 74% of users leave sites with ad block walls.
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.
Provide an alternative value exchange for ad block users
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.
To do this, you’d need to identify, at time of page load, that the user has an ad blocker and then dynamically adjust the content they see.
Move to a non-ad monetization strategy
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.
Insert ads into your videos and podcasts
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 Adzerk’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.
Don’t do anything
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.
Additionally, for in-house ad platforms, your ads will be blocked only if a community member identifies and submits your specific code.
It’s possible this never happens, so doing nothing may be the easiest approach to start with.
For native ad servers, offer server-side ad experiences with CSS workarounds
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 Adzerk’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:
- There are many reasons to move to server-side ad serving that have nothing to do with ad blocking. You can learn more here.
- If you don’t meet the AA fee threshold (10MM affected impressions/month), or it would be just a minimal fee, joining this program prevents you from needing to implement complex workarounds, while also respecting your users’ ad block wishes.
- This should be pursued only if you’re providing privacy-centered, user-friendly, native ad experiences. Most ad block users are not against ads per se; they are against obtrusive, PII-stealing ads. This can be seen in Hubspot's research that 82% of ad block users are fine with publishers monetizing them via ads. The reason they install ad blockers, instead, is due to intrusive, slow, and disruptive ad experiences.
(An example of an innovative native ad unit)Given that, please don’t bypass ad blockers to show obtrusive programmatic ads. Use this as an opportunity to monetize via user-first native ads instead.
- You must make sure to clearly mark all ads as ads (we dive into disclosure requirements here). It may be tempting to hide this tag in order to bypass ad blockers, but you should not.
In order for this strategy to work, you’ll want to take the below steps.
If you don’t take them, your native ads may still fly under the radar and not be caught/blocked, but these actions are important in limiting any regexes that could be used to identify and hide the ad’s CSS elements.
EasyList Regex Result 33across 33Across is a known ad network. If it's included in any outgoing URL, that request is stopped
For impression tracking, avoid obvious impression pixels and employ an `onload` script that fires after rendering.Why? You wouldn’t be able to track impressions if it doesn’t fire.
EasyList Regex Result ||amazon-adsystem.com Since this expression is in Amazon's impression tracking scripts, their tracking pixels are blocked
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.Why? Otherwise, the ad blocker could use a regex in the tracking URL to block the whole element.
Regex Blocks yelp.com#?#li[class^="lemon--li"]:-abp-has(a[href^="/adredir?"]) Since Yelp uses "adredir" in their ad tracking URLs, the blockers use this to identify the whole element to hide
Employ the same element names for organic and sponsored content.Why? If you have specific CSS for the ad elements, the ad blockers can identify and hide them.
Regex Blocks reddit.com##.promotedlink Since Reddit includes "promotedlink" in the div class for their ads, it's easy for blockers to hide this element
Incorporate the ad label in a way that’s difficult to identify with a regex.Why? Since for native ads often the only difference between organic and sponsored content is the “sponsored” label, this is a key string that ad blockers use to hide ad elements
Regex Blocks twitter.com#?#div[data-testid="trend"]:-abp-contains(/Promoted/) As mentioned earlier, ad blockers look for a specific Twitter div class that also has a "Promoted" label nestled in it, then blocks the whole element
To address the labeling issue, you could:
- Add the ‘sponsor’ label directly to the image Rather than the ad label be a text element on the page, it could be built into the saved image.
- Have the ‘sponsor’ label be an entirely separate element Here, you don’t try to hide the word from appearing on the page, but you structure the code so that a regex couldn’t exclude the ad without hiding all content. 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.
(HuffPost's Paid Content section is not blocked nor is on the AA whitelist)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?
- Engage in extensive obfuscation
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.
(Facebook's desktop Promoted Posts are not blocked nor are on the AA whitelist)
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.
Finally, make sure to QA your site to understand how ad blockers impact the user experience
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.
The only thing worse than giving your users a bad ad experience is giving them one that drives no revenue.
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.
Join the Ad.Product community
Sign up for our monthly newsletter and to be notified of member-exclusive events and opportunities.
Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.