BusinessMCP

Getting started

Ad-Blocker-Proof Analytics: Serve Your Tracker First-Party

Ad blockers filter analytics served from third-party domains, so a chunk of your real traffic never gets counted. Serving the tracker first-party — via a CNAME subdomain or a reverse proxy on your own domain — recovers most of it.

6 min readJuly 28, 2026

Why ad blockers cost you real visitors

Most ad blockers (uBlock Origin, Brave, AdGuard, Safari content blockers) work off shared network filter lists — EasyList and EasyPrivacy — that match requests by hostname. When your analytics script and its data beacons load from a third-party analytics domain, those generic rules match and the request is blocked before a single event is sent. The visitor is real, engaged, and completely invisible in your numbers.

Depending on your audience this is commonly 10–40% of traffic — and it skews technical, higher-income, privacy-aware segments, which are often your best customers. You are not just under-counting; you are under-counting the people who matter most.

The fix is to make the analytics look like part of your own site. When the script and beacons are served first-party — from your domain, not a third-party one — the network filters that block by third-party hostname no longer match. BusinessMCP supports two ways to do this.

Option 2: a reverse proxy under your own domain (maximum resistance)

A reverse proxy serves the tracker from a path on your own apex domain — for example yourdomain.com/stats/script.js and yourdomain.com/stats/event — with no CNAME in the chain at all. Because there is nothing to uncloak, this defeats even Firefox uBlock Origin. The trade-off is that you set it up on your own infrastructure.

If you are on Cloudflare, the simplest route is a Cloudflare Worker (or a Transform Rule / route) that proxies requests under /stats/* to your BusinessMCP origin, forwarding the path and method unchanged. On Vercel or Netlify, add a rewrite in your config that maps /stats/script.js to the BusinessMCP track.js and /stats/event to the analytics event endpoint. On Nginx, a pair of location blocks with proxy_pass to the BusinessMCP host does the same. In every case the rule is the same shape: requests to a first-party path are transparently forwarded to us, and the browser only ever sees your domain.

Then set your script tag to load from that first-party path and keep your data-tracker id as-is. Verify it end-to-end by loading a page with an ad blocker enabled and confirming the event still arrives in your dashboard. Because the script derives its endpoint from its own URL, serving it from a first-party path automatically routes the beacons first-party too.

Which one should you pick?

Start with the CNAME subdomain. It is a single DNS record, we handle TLS, and it recovers the large majority of blocked traffic with zero infrastructure work. For most businesses that is the right call and you are done in five minutes.

Reach for the reverse proxy only if you specifically need to recover Firefox-uBlock users, or you already run a CDN/edge layer where adding a proxy rule is trivial. It is strictly more resistant, at the cost of a little setup on your side.

Whichever you choose, everything downstream is unchanged: the same first-party events flow into your analytics, CRM, revenue attribution, ad audiences, and your MCP endpoint. You are simply making sure the visitors you already have actually get counted.

Frequently asked questions

Does serving analytics first-party hurt privacy or GDPR compliance?

No. BusinessMCP is cookieless, honors Do-Not-Track and Global Privacy Control, and uses a daily-rotating hash instead of persistent identifiers regardless of how the script is served. First-party serving changes the delivery path, not what is collected. You can also gate the tracker behind a consent banner with data-require-consent.

Will the CNAME approach ever stop working?

It keeps working for the vast majority of ad-blocker users. The one exception is Firefox with uBlock Origin, which uncloaks CNAMEs. If that segment matters to you, the reverse-proxy option removes the CNAME entirely and closes the gap.

Do I need to change my tracking code when I switch to first-party?

Only the script src (the CNAME subdomain or first-party path). The data-tracker id stays the same, and the beacons automatically follow the origin the script was served from — so custom mcph.track() calls and data-mcph-goal attributes keep working untouched.

Turn your business into one AI-ready MCP server

Connect your tools, install one tracking script, and expose your unified data to any AI agent through a single secure endpoint.

Get started free