Ad Blockers and SourceTag

Ad blockers and privacy extensions can occasionally block SourceTag’s script from loading. This page covers how common the issue is, what happens when the script is blocked, and what you can do about it.

Does SourceTag get blocked?

SourceTag’s script is served from cdn.sourcetag.io. Most ad blockers focus on known advertising and analytics domains like Google Analytics, Facebook Pixel, and major ad networks. SourceTag is not on the major filter lists (EasyList, EasyPrivacy, etc.), so the vast majority of ad blockers will not block it.

That said, some aggressive privacy extensions (like uBlock Origin in strict mode or Brave’s built-in shields set to aggressive) may block requests to unfamiliar third-party domains. In those cases, the script would fail to load.

How common is this?

Ad blocker usage varies by audience:

B2B sites typically see 10-20% of visitors using an ad blocker
B2C sites can see 20-30%, sometimes higher for tech-savvy audiences
Most ad blockers use the default filter lists, which do not include SourceTag

In practice, the number of visitors who both have an ad blocker installed and have it configured aggressively enough to block SourceTag is typically very small. For most business websites, the impact is negligible.

What happens when the script is blocked

SourceTag is designed to fail gracefully. If the script doesn’t load:

Forms still work normally. The script not loading has no effect on form submission. Visitors can still fill in and submit forms as usual.
Hidden fields won’t be populated. The attribution data simply won’t be there for that submission. You’ll receive the form data without the st_ fields.
No JavaScript errors. The script uses the async attribute, so a blocked request doesn’t throw errors or break anything on the page.

The worst case is a missing attribution data point, not a broken user experience.

CNAME approach (workaround)

If ad blockers are a concern for your audience, you can set up a CNAME record on your domain that proxies requests to the SourceTag CDN. This makes the script appear as a first-party resource, which ad blockers almost never block.

For example, you’d create a DNS record like:

scripts.yoursite.com  CNAME  cdn.sourcetag.io

Then update your script tag to use your subdomain:

<script src="https://scripts.yoursite.com/scripts/YOUR_SITE_ID/st.js" async></script>

Since the browser sees the request going to your own domain, ad blockers treat it as first-party and let it through.

Note: Setting up a CNAME requires access to your domain’s DNS settings. The exact steps depend on your DNS provider (Cloudflare, Route 53, GoDaddy, etc.). You’ll also need an SSL certificate that covers the subdomain, which most providers handle automatically.

Tips for maximising coverage

Load the script early. Place the script tag high in the <head> section. The sooner it loads, the less chance of interference from other scripts or extensions.
Use the WordPress plugin if applicable. The WordPress plugin can set server-side cookies, which persist even if the JavaScript is blocked on a return visit (the initial visit still needs the script).
Don’t worry about perfection. No analytics or attribution tool captures 100% of visitors. Even Google Analytics is blocked by ad blockers at a higher rate than SourceTag. The goal is directional accuracy, not absolute completeness.
Monitor your data. If you notice a significant number of form submissions without any SourceTag data, ad blockers might be more prevalent among your audience than expected. The CNAME approach would be the next step.