First-Party Analytics: Cookieless, Ad-Blocker-Proof Data

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.

Blockers are only one leak. Safari’s Intelligent Tracking Prevention caps script-set storage so returning visitors look new; Firefox ships tracking protection by default; and every consent banner a visitor declines or ignores is a session a consent-gated third-party tool never records. Stack these and third-party analytics commonly miss a meaningful, often double-digit share of real traffic — the exact figure depends on your audience, and anyone quoting one precise number for every site is guessing.

Worse, the loss is skewed: it concentrates in technical, higher-income, privacy-aware segments — often your best customers. The fix is to make measurement part of your own site: first-party analytics, served from your domain, without third-party cookies to block or gate.

First-party means the browser sees your domain, not an analytics vendor’s: the script loads from your site (or a subdomain you control) and the data beacons go back to the origin that served it. Cookieless means no cookies at all — BusinessMCP mints a random visitor id in localStorage (first-party storage, set by your page, never readable cross-site) and uses a daily-rotating server-side hash for sessions, so there is no persistent cross-site identifier and nothing for cookie-blocking features to strip.

Because the events land on infrastructure acting for your site, the server side can do the heavy lifting honestly: layered bot filtering, geo lookup, channel classification, and revenue attribution happen after ingestion — and the data is yours, feeding your own analytics, CRM, and MCP endpoint rather than a vendor’s ad network.

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.

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.

// vercel.json / netlify-style rewrite — replace <script-origin> with the host your
// BusinessMCP install snippet loads from
{
  "rewrites": [
    { "source": "/stats/script.js", "destination": "https://<script-origin>/track.js" },
    { "source": "/stats/event", "destination": "https://<script-origin>/api/analytics/event" }
  ]
}

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.

Serving analytics first-party changes the delivery path, not the legal analysis. A cookieless design with no cross-site tracking and rotating identifiers materially lowers the privacy footprint, and many businesses run it on legitimate interest — but EU ePrivacy rules concern reading and storing anything on the visitor’s device, and some regulators read that strictly enough to cover a localStorage id too. First-party is a strong posture, not a universal exemption.

Our posture, stated plainly: the tracker runs by default and you are the data controller — add a privacy notice, and where your audience or your lawyers require it, gate the tracker behind consent (a data-require-consent attribute plus one consent call wires it to any banner). The US Global Privacy Control signal is honored where it legally applies: on the ad-sharing layer (conversion forwarding and audience sync), which is what GPC actually governs.