Summary in 64 words

Ad blockers are widely used tools these days. Users install this software to improve loading times of websites or to simply remove intrusive advertisement. But what does this mean for us as a testing company? We saw some sites break and are now including tests with enabled ad blockers. This helps our customers to see where problems might occur and to improve user experience.

Introduction

The amount of advertising increases and more and more users take this matter in their own hands and install ad blockers. Users also become privacy-conscious and do not want to expose their browsing behavior to an ever increasing number of companies. Facebook’s, Twitter’s, and Google’s ad or content pixels are on nearly every page nowadays. Adobe collects data as well with font services, Scene7, and Omniture. There are lots of big and small third parties that live on pages and are included as a service. We have seen websites with over 50 third party services on a single page of their web shop.

Ecommerce

You might wonder why this topic suddenly is of interest. Well, with our existing customers we often experienced that ad/tracking blockers can break pages. In one case scenario, the add to cart action was broken, in another you couldn’t continue through with checkout, and finally customers could not select the size of a product because the dialog simply didn’t open. No visible error messages. It just wouldn’t work anymore.

In all case scenarios it helped to turn off Ghostery and reload the page. By the way It turned out that, when looking into it, it was the blocked call to Omniture that messed up the JavaScript execution on the site.

Just take a look at the recent study by Payfair about ad blocking. About 200 million users worldwide already block ads or tracking services. This amounts to 10% to 25% of the users per site and these numbers are significant.

Test Implications

We neither want to discuss the pros and cons nor the implications for the industry, we want to see this as a fact. Facts influence testing and so we have to react to a change in user behavior. Remember when Chrome became popular? We had to add Chrome to the mix and Chrome is now the leading browser nearly everywhere.
So what shall we do? Well, the answer is easy and obvious. We simply test that when users choose to use ad and tracking blockers, the site works as intended in terms of major functionality. Features that cannot work due to the third party dependencies such as video playback won’t break the site but cause a graceful degradation of functionality.

We might want to focus on the most important business case: the checkout or in other words, enabling the user to purchase something.

Some of the most popular ad block programs are AdBlock, AdBlock Plus, Ghostery, and, because it has been released recently and does not have a business case behind it: EFF Privacy Badger.
Having said this, why don’t you go ahead and add a few simple test cases to your regression test suite or perform exploratory tests on your site while using ad and tracking blockers to find out which features might be affected.

Beyond blocking

Of course many third party service users might just argue that you should not block ads or tracking services at all. Let’s pretend you’re not using any tracking or ad-blocker software. It would still be necessary to check how a site behaves while third party services are down, down meaning physically down and not blocked.

If a third party does not respond, returns garbage instead of the usual JavaScript, or simply is slow, your site suffers similarly to a user blocking that traffic. Consequences can even be worse because blocked at least means predictable speed, while slow or unresponsive means that the entire site suffers from a performance problem that is out of your control.

By the way, as a user, you might also be unable to control what is permitted and what isn’t, because your network does the filtering for you. See a case study by the Simon Fraser University Canada.

The task for the site owner is: always validate what would happen if your third parties fail. Does your site fail with them?

One more thing

If you are reading this as an owner of a site that heavily integrates external services, services that incorporate content into your pages, that execute JavaScript, and display messages, you should be aware of a few things. Any of these services can be hacked, attacked, or modified and suddenly your site has a security problem. Keep that in mind when your marketers, sales, or business teams pressure you for another content tracker, for the inclusion of another site optimizer, or site analytics. Less is more!

Another small yet often overlooked fact are uptime dependencies. Let’s take a look at some numbers. If your service provider gives you an uptime of 99.9% and each of the third parties does the same, your total availability is about 98.91% when you include only 10 external services. This means you have a total downtime of almost 4 days per year. This does not include a single day of planned maintenance. That is definitely not what you are looking for.

Verdict

Third party integrations have been a challenge before. Now a test for intentionally disabled third party integrations has to be part of the test mix to make sure that your site performs the way you want it to.