Kinja Data Team

it's A/B test time, my dudes

Ad blocking software is on the minds of a lot of people in digital media & tech right now. The Times, CJR, and Marco Arment have reported or opined about the issue in the last few weeks, to name just a few. Interest in popular ad blocking software, as measured by Google searches, is way up over 2013 levels, though it seems to have leveled off a little since the winter.

Pagefair & Adobe just released their annual ad blocking report. I thought I’d take the opportunity to go through our data on ad blocking and how we’re thinking this new challenge to web publishing.


Our experience compared to PageFair/Adobe

Pagefair says that 16% of the US online population blocks ads. I’m not sure what goes into that calculation exactly, but that’s in line with our experience: overall we see about 15% of our sessions have ads blocked, 13% in the US.

This number hides a huge amount of variability: on a site-by-site basis we range from single-digits to over 20% of our visits employing ad blocking tech. The topic-by-topic usage of ad blocking software on our sites roughly follows the data they published, (reproduced below):


PageFair makes a big deal about the growth of Chrome driving the increase in ad blocking software usage. While that’s true, Chrome is far from being the platform with the highest rate of adoption: Firefox and Opera lead the way.


There’s a clear divide between browsers where installing ad-blockers has been adopted and where it hasn’t. Also notable is that there’s very little mobile ad-blocking: under 1% of mobile & tablet sessions use blockers, compared to 33% of desktop sessions. This obviously is something we will watch with Adblocking coming to iOS 9.

International usage: high but growing slower

Looking at the data by country, blockers are about 13% of sessions from the US. Internationally the number is closer to 20%.


Some of PageFair/Adobe’s adblocking usage information from Eastern Europe is frightening, but I suspect this is largely tied to the skew in interests in traffic from that part of the world: the people who are online and coming to sites that are tracked tend to be from demographics that use ad blocking software: other groups of users haven’t made it online yet or just don’t visit international sites (this is yet another example Simpson’s Paradox, which comes up frequently in our A/B testing).

In our internal data, we also see a much higher percentage of blockers from Eastern Europe, but those visitors also skew towards gaming and tech sites. Once we control for the topics readers there are interested in, we see ads being blocked at a rate much closer to what we see domestically. European ad blocking usage is growing more slowly than in the US, and I’m expecting that trend to continue.


Reaching blocked readers

Readers using ad block are the savvy readers that we want to reach out to. They also are some of our most loyal visitors, and they stay on the site for about 30% longer than our overall average.


While we obviously can’t serve ads to blockers, we have had a lot of success where we can show these readers additional value. Our commerce site, Kinja Deals, gets over a quarter of its visit from readers blocking ads and a similar percentages of our referrals come from these readers. Since our systemwide average of ad blocking software usage is closer to 15%, in this regard many readers blocking ads can be more valuable to us than other readers.

We’re continuing to look for ways to provide value to our readers while giving our clients ways to get the word out about their products and services. From the Promotions team securing amazing deals for readers to the Studio@Gawker team building great content and experiences, all of us at Gawker are trying to navigate this new reality of digital media.


*Technical note: how we test for blockers

We test for blockers by creating ‘bait’: an element on our webpage that looks like an ad. We write the ad early in the process of loading the page. Here’s the relevant code (taken/adapted from the excellent BlockAdBlock project) if the bait is ‘taken’ (blocked) we identify the user as using ad blocking software:

bait = window.document.createElement(‘div’);
adblock_detected = ‘off’;
bait.setAttribute(‘class’, ‘pub_300x250 pub_300x250m pub_728x90 text-ad textAd text_ad text_ads text-ads text-ad-links’);
bait.setAttribute(‘style’, ‘width: 1px !important; height: 1px !important; position: absolute !important;left: -10000px !important; top: -1000px !important;’);
bait.setAttribute(‘id’, ‘bait’);
if (window.document.body.getAttribute(‘abp’) !== null || bait. offsetParent === null ||bait.offsetHeight === 0 || bait.offsetLeft === 0 || bait.offsetTop === 0 || bait.offsetWidth === 0 ||bait.clientHeight === 0 || bait.clientWidth === 0) {
adblock_detected = ‘on’;
if (window.getComputedStyle !== undefined) { if (window.getComputedStyle(bait)
.getPropertyValue(‘display’)===‘none’ ||
.getPropertyValue(‘visibility’) === ‘hidden’) {
adblock_detected = ‘on’;

We then pass the output of adblock_detected to Google Analytics as a custom dimension. This gives us all the flexibility of working with the data that GA allows, and allows us to gather the data efficiently using Google API integrations that we’ve already built.


The major limitation in our tracking is that we don’t see blockers that also block Google Analytics. The most prominent blockers (Adblocker, Adblocker Plus, Ghostery) avoid on default but there are exceptions (uBlock, probably others).


Additionally, we only check once to see if our ‘bait’ has been taken, so adblockers that act slowly or that remove DOM elements after they are already written may not register. In practice, we haven’t seen this as an issue for the major known adblockers.

Share This Story

Get our newsletter