According to new research, somewhere around 40% of global internet users employ some form of ad-blocking technology.

There are many browser extensions out there today available to web users that help them block pesky ads around the web. This category of tools originally aimed to stop display and video ads from degrading the browsing experience, but has evolved into a broader set of tools that has resulted in collateral damage impacting various vendor tools designed for analytics, feature management, and experimentation.

Types of ad blockers

Let’s use the term “blocker” as the umbrella term throughout this post, but it’s worth noting that we commonly hear ”ad blocker” being used as the catch-all term for any type of browser extension that blocks resources from loading in a user’s web browser.

The two main “blocker” categories are:

• Ad blockers: These are designed to block advertising and unwanted content. They often implement several methodologies, including removing HTML elements with classnames matching certain keywords, as well as DNS-based resource blocking (examples: AdBlock, Adguard).

• Privacy blockers: These are designed to block websites from identifying and tracking user behavior. These are typically DNS-based, and a bit more nascent as web users have become more privacy-aware (e.g., uBlock Origin, Ghostery).

💡 The popular ad blockers now have hybrid blocking capabilities, allowing users also enable privacy blocking as well.

Block lists and DNS-based blocking explained

Blockers implement various flavors of a “block list,” which is a giant list of keywords used to match cookie names, html content, images, iframes, as well as hostnames (ie: ads.google.com, google-analytics.com) in order to suppress unwanted content.

DNS-based blockers will cancel HTTP requests to hostnames contained in the list, essentially suppressing a tool from loading/initializing or firing event-tracking requests over the network. The privacy blockers implement a “privacy block list” of provider hostnames known to do some form of tracking, which includes virtually every SaaS provider.

It’s unclear exactly what the criteria & decision process that lands a provider on a block list, but it generally feels like it’s at the discretion of the maintainers of these open-source projects out in the wild.

These lists are maintained by Fanboy (a.k.a. ryanbr), MonztA, Khrin, and Yuki2718. [from the EasyList repository]

Check out our sandbox project

Take our “sandbox” project for a spin! In this project, we have generated real-time sample data for you to explore and experiment with.

Test Drive Now

Should you circumvent blockers?

This is entirely up to website owners and feature-flagging/experimentation practitioners, but consider this:

A user launching your web app might have an adblocker enabled with the intent of blocking “ads,” but incidentally becomes invisible to your feature management tooling. This is something of a grey area, as their intent was not necessarily to block your feature management and analytics tools.

On the other hand, if users have privacy/tracking blockers enabled, they likely intend to remain untrackable and invisible to your tools.

If you are using Statsig for managing targeted rollouts of new product features—with the intent of measuring metrics to minimize any unwanted impacts—blockers could prove to be problematic and a detriment to delivering key features and optimizations that will benefit the user experience. However, there are means to circumvent blockers if these practices are critical to your software deployment process, which we’ll discuss below.

Solutions

• DNS blocking could affect any number of aspects of your client-side tools, including the loading of the script itself, requests to initialize the SDK client, or any event logging calls made by the client.

• Statsig’s presence on the block lists is less than other providers at the time of writing this, likely due to the fact that we were founded more recently—but this could change!

• Client-side tools & tracking are subject to blockers as well as a user’s network and privacy settings. Server SDKs are not subject to any of these user tools, and therefore cannot be blocked or suppressed.

• Customers can implement a Custom proxy and use their own domain for all network connections. Our Client SDKs provide a simple option to specify your own URL endpoint as the API server, which means the requests will not be suppressed by any blockers.

• Users with privacy blockers may wish to not be tracked at all, in which case it is best to respect that preference!

*If you have any questions about this topic, contact Statsig today to speak with our technical teams and discuss solutions and best practices that best suit your requirements.

Request a demo

Statsig's experts are on standby to answer any questions about experimentation at your organization.

Grab a Demo