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 1: the CNAME subdomain (recommended, one DNS record)
Point a subdomain of your site — for example analytics.yourdomain.com — at BusinessMCP with a single CNAME DNS record. In your BusinessMCP dashboard, open Connections → Traffic quality → First-party tracking domain, enter the subdomain, and add the CNAME record it shows you (a CNAME to cname.vercel-dns.com). We attach the domain and issue the TLS certificate automatically; once it verifies, your install snippet updates to load from your subdomain.
Because the tracker always sends its data back to whatever origin served it, nothing else changes: the script tag src becomes https://analytics.yourdomain.com/track.js and the beacons follow. No code changes, no second snippet.
The honest limitation: on Firefox, uBlock Origin performs "CNAME uncloaking" — it resolves the CNAME chain and re-checks the real target against its filter lists. So a slice of Firefox users can still be blocked if the canonical host is listed. In practice the CNAME approach recovers the large majority of blocked traffic (all Chrome, Edge, Safari, and Brave blockers, which do not uncloak), which is why we recommend it as the default. If you want to close the Firefox gap too, use Option 2.
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