Accurately measuring ad blocking rates
Ad blocking, and content blocking in general, is a major topic of discussion in the industry right now, and many are struggling to formulate a response tailored to their particular websites and their users. Although worldwide users' interest has been growing for years (see Google Trends), it is not yet clear what a compromise that caters to the needs of users, website publishers, and advertisers would look like.
Regardless of the wider industry debate (more on that below), ad and content blocking are here to stay, and you need to define a response suitable for your website and your users. To start, you need to measure the percentage of your users who use content blockers.
Although there are many demographic- or industry-wide reports on ad blocking rates, not many robust ways to measure accurately the percentage of users on a given website who block ads have been documented.
Many of the published methods rely on using existing analytics trackers, like Google Analytics or Omniture. However, some popular blockers, like Ghostery and uBlock Origin, block popular analytics packages as well as ads by default, and others can be configured to do so too. This means you are likely not measuring what you think you are measuring if you use existing analytics to measure ad blocking.
The solution is to spin up your own analytics infrastructure. (In another blog post we will talk about why this should be a strategic investment for all sites and apps in 2016). For just measuring ad blocking, you only need something very lightweight. In this post, we will sketch out a simplified version of a technique we've been developing, which we've tested with uBlock, uBlock Origin, Ghostery, Disconnect, and Firefox private browsing mode with the new Tracking Protection.
The core of the technique requires two analytics URLs:
A creative ping URL: This is a URL that is pinged/called when the ad creative is displayed by the ad network. For example, DoubleClick for Publishers calls it the "Third-party impression URL".
A control URL: This URL is pinged/called every time you think the page should have impressed an ad.
To test your configuration, enable one ad blocking extension at a time and visit the test page (ideally using a fresh incognito mode browser window every time). The control URL should be pinged but the creative ping URL would not.
This configuration generates raw data, and allows you to get a rough estimate of the ad blocking rate. However, this number is likely to be misleading without further enhancements. Here are general tips and thoughts for production use:
You'll need to account for many edge cases (e.g. how to account for the ad or analytics URLs not getting pinged because of client-side network connectivity issues), and you'll need to process the data (e.g. to account for bot traffic). How you do that will depend on your current setup and we can't give specific advice.
You need to pick URLs that will not be blocked by the default patterns used by content blockers. Don't use something like "analytics" or "tracker". In our tests, "example.com/lib" worked well.
Use an image tag to ping the control URL (as the src attribute).
Create a new ad unit and placement specific for this use. Have only one placement on the page, and configure the ad to be shown 100% of the time (i.e. every pageview). In our tests, we simply served the site's logo in the footer as the ad's creative, which worked well for both users and our tests.
If you show the ad to a sample of your traffic, be sure the sample is representative of your overall traffic and your calculations later on account for that. Likewise, if you place this test ad on just one section of a site, be sure that section is representative of all site traffic.
With some modifications, you can use the same infrastructure to measure analytics blocking.
If you don't currently display ads on your site but are still curious about your users, you may be eligible for DFP Small Business. Failing that, there are other techniques.
Keep the responses of the ping URLs as lightweight as possible, as you don't want to affect the page loading performance and skew the numbers.
We can help if you are stuck.
Why you need a strategy for handling ad blocking
Let's take a step back and survey the industry debate. As noted, these ad and content blockers have been around for years. The discussion took a new urgency earlier this year when Apple announced that Safari on iOS 9 would support content blocking. With content blocking pushed into the mainstream, the industry reacted:
Some asked users to whitelist the site (e.g. Guru3D.com).
Some documented the issue and started planning for the future (e.g. Snipcart).
To counter these countermeasures, some users install extensions to "poison" the clickstream data for a publisher by clicking on every single ad (Wired has a summary).
But before you decide what is the best response for your site and users, you need to measure the current, baseline, blocking rate, and continue to measure it going forward. You also need user and business research to find the right response. If you need help with any of these topics specific to your website, please get in touch.