Detect Adblock: technical and UX considerations
If you are a product manager or engineer building a tool to detect Adblock users and recover lost revenue, check this post for important technical and UX tips. Feel free to use our open-source code to get started.
In our post about big shifts happening to online content monetization, we described our observations about Adblock, CTR and UX trends on the Web. One of our conclusions is that as an online publisher or anyone who relies on online ad revenue, you have to decide what to do about the inevitable decline of advertising.
As we discussed in our previous post about challenges for content monetization, this decision will heavily rely on the type of content and audience you have. In general, you can successfully sell content if you have “frequent” readers and unique content. For example, time-sensitive advice which gives readers an “edge” will sell much better than short-form redundant news articles.
Ultimately, you have to decide whether you can charge for online content. If the content is unique and useful to readers, then you can charge for it, and the challenge becomes choosing the right paywall strategy and how to implement it in a user-friendly way. If the content is redundant, short-form and of low value to readers, then direct payments will never become a major source of overall revenue unless your content strategy drastically changes. Still there are few things you can do. One thing which several ad-dependent publishers and content creators already implement is asking visitors to turn off Adblock.
You’re probably familiar this strategy from Forbes, who was the one of the first to implement Adblock detection:
A good rule of thumb to determine whether an anti-Adblock strategy would work for you is to ask the same questions you ask when deciding whether to charge for content or not. If you could charge for content, then it’s very likely you can ask visitors to pause Adblock or whitelist your site.
Another obvious question to ask at first — what fraction of your visitors are actually using Adblock? Some of our clients have mainly mobile traffic, and the total fraction of Adblock users is only about 10%. On the other hand, some sites with mainly desktop traffic and a young, tech-savvy audience have up to 35% of visitors using Adblock. Those publishers are feeling a big loss in ad revenue and will need some strategy to make up for it. If you decide to recover lost ad revenue by asking visitors to turn off Adblock, then there are two main considerations: technology and UX.
Technical consideration for Adblock detection. The first step is to figure out the most robust way to detect Adblock and account for unexpected “edge” cases. We’ve found that the best approach in terms of ease of implementation and robustness is to check whether particular external JS files are being blocked on a visitor’s browser.
For example: https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js
If you decide to build your own anti-Adblock, you have to test out the code for all combinations of Browser (most popular: Chrome, Firefox, Safari, Microsoft Edge) and Adblock (most popular: Adblock, Adblock Plus, uBlock, Adguard, Ghostery). Look out for some versions of Safari in combination with uBlock. Detection might not work due to an `onBeforeLoad` event. For detecting Adblock on mobile browsers, test out on the most popular Adblocking browsers, which are the Adblock Plus Browser and UC Browser.
The next step is to build robust analytics which track the behavior of your guest users. The analytics need to measure not only how many visitors come with Adblock enabled but also how many of them decide to turn it off. Cookies or localStorage, though not 100% reliable, are good enough since the majority of visitors don’t clear them that often. If you implement via some external scripts, be aware that (1) uBlock aims to block pretty much all scripts on the page and (2) Adblock and Adblock Plus use the Anti AdBlock Killer list to block popular Adblock detection scripts. One way to detect Adblock robustly and efficiently is to implement detection natively. If you want to learn more about native implementation, check our code on Github.
UX consideration for Adblock detection. Once you can detect Adblock robustly for all the major browsers and Adblock types, what’s next? What to do with visitors who come to your website with Adblock?
You can either show them Adblock’s whitelisted ads or ask them to turn off Adblock. Showing whitelisted ads allows you avoid directly asking your visitors to turn off Adblock. Companies like Page Fair, Revive Ads, Uponit, and Admiral use this method to display ads even when users have Adblock enabled. However, technically-savvy visitors will notice the ads and can easily block them. For example on this page, you can block ads by manually blacklisting this source: http://www.probuilds.net/js/pgfr/wrapper.min.js.
Alternatively, you can ask visitors directly to turn off Adblock. Ask them to support you and your work by pausing Adblock or whitelisting your website. In choosing this option, there are a few UX rules we suggest:
(1) Don’t use a popup. It’s important to remember that Google punishes your website’s SEO if you use intrusive popups. Popups already have a reputation for being disruptive and untrustworthy — 70% of of US readers are annoyed by them. Most of the time, users try to instantly close a popup, as the “best” popup response rates are only 6%. Instead of a popup, you can show readers your pages but pause them from scrolling, clicking, or otherwise interacting with the content they see. Then you can display a non-intrusive message as a bar on the bottom or side of the page.
(2) Customize the message to your audience. Tell them why you are asking them to turn off Adblock — is it to support your journalists? to pay for the website hosting and maintenance? to pay for your rent or food? (you can add some light-hearted humor). The idea is to make it personal and specific to your site and readers. Another point here is to make the message match your branding, in terms of colors, fonts, and style. You want readers to understand that this message comes from you.
(3) Show some pages for free. For instance, you should always let visitors see the homepage to get a sense of the type of content you offer. Other pages to keep available include your about page, contact page, and any content category pages. If you don’t give new visitors a chance to review you overall content, they’ll instantly bounce away. In addition, these pages add trust to your website, so it’s best to keep them completely available.
(4) Show some content per page for free. We strongly recommend utilizing the “teaser” method we described in detail in this post. With this, you show 1/3 to 1/2 of your article before asking visitors to turn off Adblock. In our experiments, switching from a popup message to a teaser method reduces visitors’ bounce rate by 2x and increases the number of users who decide to turn off Adblock by 2–3x.
(5) Give few options, ideally only one. When you’re asking visitors to take an action on your website, you need to make it as easy as possible. It’s been well-documented that too many choices, while seemingly better for the user/customer, actually paralyze people from making any choice at all. We’ve seen examples of anti-Adblock messages where a publishers asks the user to turn off Adblock, or share their email, or pay to go ad-free, or pay for a regular subscription, or install a browser extension, etc. etc. It’s just too overwhelming.
Adding to this note, we’ve seen a growing trend where publishers experiment with ad-free subscriptions in addition to asking visitors to disable Adblock. A good example is Business Insider, you can see an example here or on any of their articles. From the publishers we’ve talked to, most find that the overwhelming majority of users (>99.5%) will prefer to simply turn off Adblock. With the popularity of free Adblock (Adblock Plus alone has over 100M active users), readers will not be willing to essentially pay for an Adblock on a single website. It can also be a pain to sign up and make a monthly payment, even if it’s as little as $1. In this case, it’s better to just give the single option of whitelisting the website, because there will be many users who are willing to turn off Adblock but just turn away when they see so many choices. Compare Business Insider to Forbes, who has one simple option to turn off your Adblock.
Although in general most readers will not pay to go ad-free, your success will largely depend on your audience and how well they know you — an audience who feels a more personal connection to your brand or you yourself will be more inclined to pay for your ad-free site. So think about who your readers are, and whether ad-free makes sense. Also consider charging the ad-free subscription for one year up front. It may sound appealing to have a subscription that’s just $1–2 per month, but that monthly bill will more likely just annoy users and make them unsubscribe. A payment of $12–20/year is really not a huge commitment, especially if your readers like you enough to pay in the first place.
The direct approach seems to be harder to implement: you have to communicate with your readers, compose an honest message to ask about turning off Adblock, and create simple instructions on how to do so. However we believe this is the best approach. In the war between ads and Adblock, Adblock will prevail since ultimately the internet user controls which elements of DOM on their browser to load and which to block. If readers value your content and you treat them with respect (not showing 20 ads per page, including popups and auto-playing video ads), then when you communicate openly, they will whitelist your site. Some of our customers have recovered over 50% of revenue lost due to Adblocking by following the above advice.
In order to decide if Adblock detection should be used to recover lost ad revenue on your website, you have to consider upsides and downsides. You want to calculate how much revenue you can recover (upside) and whether/how much your bounce rate will go up (downside).
The first step is to measure how many visitors use Adblock on your site. In our experience, a U.S. website can have anywhere between 10 to 35% of its visitors using Adblock. If the audience is young, tech-savvy and mostly comes from Desktop, it’s likely to be in the 30–35% range. If the audience is older, not tech-savvy and mostly comes from Mobile, it’s likely to be in 10–15% range. But any measurements will slightly underestimate the amount of Adblocking, since some ad blockers, like uBlock, even block Google Analytics and make the Adblock user invisible to the website.
The second step is measure how many visitors are turning off Adblock on your site. This is where we can help, or the publisher can build custom analytics by using cookies or localStorage. For our clients, the percent of Adblock users who will turn it off varies between 10 to 50%, depending on the content type. If the content is short-form, redundant and can be found somewhere else for free, then visitors are likely to bounce off. If the content is long-form, unique, and can’t be found somewhere else, then visitors are likely to turn off Adblock.
As an example in deciding whether to implement detection or not — for a website with 30% of visitors using Adblock and 25% of those visitors willing to turn off Adblock, you can recover 7.5% of revenue. To calculate the upside (recovered revenue), we need to plug in the total traffic and average RPM. For a website with 10 million monthly visits and $8 RPM, the monthly recovered revenue would be $6,000. It’s very important to recognize if adblocking is a big problem for your ad revenue. In our experience, most of the small and medium size publishers and content creators do not have a serious adblocking problem for now.
We recently open-sourced our Native Adblock Detector. On average, publishers and website owners recover 20–60% of lost ad revenue by using our product (20–60% of Adblock users decide to turn adblocking off). Native stands for native implementation, where the detector does not call any external JS code to work. You can find the code in this Github repo. Any web developer in your organization can set up the detector in under 15 min by following simple setup instructions.
