Why "Ad Blockers" Are Also Changing the Game for SaaS and Web Developers

Unless you’ve been living under a digital rock for the last few months, you’ve undoubtedly heard the buzzing echo of the raging ad blocking debates. And since Apple dropped a metaphorical bomb on the matter by allowing ad blockers apps on their iOS 9, the temperature just kept rising.

According to Page Fair’s now-infamous Ad Blocking report, around 200 million users run ad blocking software on their browsers. With the appalling state of some ad units and practices out there today, chances are this number will keep growing, a lot. Consequently, numerous posts highlighting issues faced by the concerned parties (content creators, publishers, advertisers & online users) were published.

This post will address the issues faced by another, slightly different party: SaaS startups & web developers.

The point of this article isn’t to take a firm stance on the whole ad blocking debate. Of course, we know darn well it can affect us: online advertising is an acquisition channel we’ve played with in the past, and we intended to try again sometime.

Thing is, for us, this issue goes much, much farther than paying for ads that are blocked by potential customers. Let me demonstrate how and why we came to pay closer attention to the whole thing.

So what happened to us, exactly?

The forbidden route

We know the ad blocking phenomenon isn’t exactly fresh from the oven. So why write about this now, you may ask?

Well recently, as most of our active users noticed, we released a whole new, revamped version of our merchant dashboard. It's a key part of our product, where merchants handle inventory management, discounts, and a whole other bunch of stuff. All in all, the release went well, and we were proud of ourselves (especially of our lead engineer Charles). But after brushing off our shoulders and toasting with some good scotch, we realized something was wrong. When logging into the dashboard, many of us weren’t able to see the sales analytics and graphics on the default screen. After receiving two or three emails from customers, we knew there was a real problem to fix.

Yanick, one of our developers, put on his problem-solving cape and got to work. As every web developer would have done, he started by hitting the F12 key to open debugger tools. Soon enough, he found the source of the error:

uBlock Origin was preventing Snipcart from fetching the URL /api/analytics in our dashboard.

We foolishly thought: “Hmm. Well now, this isn’t an ad, so… what’s up?”. It wasn’t long before the Internet reminded us that uBlock Origin and uBlock are more than mere ad blockers; they're general purpose blockers. Their blocking reach extends far beyond the advertising realm: it’s a matter of online privacy as a whole. Which means analytics tools & crash reporters’ tracking scripts and cookies can be blocked too.

Yanick then proceeded to GitHub to uncover the inner workings of the blocking software a bit. The source code led him to the EasyPrivacy list. It just so happens that the URL route we used to display our sales analytics was flagged on this uBlock Origin default blocking list. After exchanging a few frowns, we changed the route and solved our users’ problem.

Needless to say, we were slightly irritated at the fact that a valuable feature for our merchants, totally unrelated to online privacy issues, was blocked by the software. So we dug a bit more into those default blocking lists.

The ghosts we missed

We quickly spotted a few listed third parties names that reminded us how effective those blockers can be. Especially when we read: Google Analytics.

Why the facepalm? Well, most of our website visitors and potential users are tech-savvy developers who are highly susceptible of running general purpose blocking software such as uBlock & uBlock Origin. In other words, we had just realized that a potentially substantial chunk of our website traffic were basically… ghosts.

We learned something we should’ve learned a while ago: we can’t rely 100% on our tracking analytics. As a SaaS startup that focuses most of its growth on content marketing and website optimization, that’s not exactly good news. So for SaaS businesses, ads are just the tip of the ad-blocking/general purpose blocking iceberg. And what’s under the water here has a much more important potential impact on the businesses themselves.

So what are SaaS startups and web developers to do?

Ads apart, we identified mostly 2 types of blocked data both SaaS and web developers might encounter:

1 - Stuff that shouldn’t be blocked, or that is blocked for wrong reasons. For instance: Our sales analytics graphics in our dashboard following a blocked route.

2 - Stuff that, as a business, we’d rather have unblocked, but is blocked because of privacy protection lists. For instance: The metrics on Google Analytics regarding our website visitors running blocking software.

Which means:

1 - Even if you're not relying on advertising, you need to consider ad blockers and general purpose blockers when developing web apps.

For web developers, we believe that serious app testing should be done while running ad blocking and general purpose blocking software. It should now be included as an important step in any development-related quality assurance process. As strong proponents of continuous integration development practices, we'll be sure to look for ways to automate this kind of testing.

2 - If your SaaS relies on web analytics and tracking software, you need to take into account ghost traffic and alternate measurement solutions.

For SaaS startups, the answer is a bit more complicated. Some of them might depend on online advertising to generate a part of their revenues. If it is so, it puts them directly at the forefront of the debate we mentioned in the post’s intro. And since this is an industry-wide debate, we won’t get into the specifics in this article.

Some of them, like us, also rely heavily on website optimization and trackable, organic marketing efforts to grow. In that regard, I think there are many options to consider (some that we definitely will take a look at). For instance, there are tools allowing you to measure which percentage of your traffic is running blocking software. This knowledge would allow us to adapt our metrics accordingly.

Maybe we’ll see a rise of alternate tracking solutions such as server-side analytics and custom, in-house analytics?

Maybe a more important place in the optimization process could be allowed for qualitative, direct feedback tools?

As for us, we do not wish to take a stance against ad blockers and general purpose blockers. I mean, we’re using the software ourselves. And as a startup that repeatedly claims it wants to grant developers more freedom, we’d be quite hypocritical if we were not to respect their browsing choices.

So we’re not going to try and block the blockers. We’re going to try and adapt, and see where it takes us. Hopefully, we’ll be back with another post that follows up on this whole thing!

We’d really love to hear your thoughts regarding the ad blocking and general purpose blocking situation. Especially if your experiences relate to ours in any way. The comments section is all yours! And if you enjoyed the post, please, take a second to share it on Twitter.