Ad-blockers & the first-party proxy

Why ad-blockers eat analytics events, how to confirm it's happening, and how a first-party proxy fixes it with one DNS record.

Content blockers ship filter lists that block requests to known analytics domains. When a visitor with one installed loads your site, the request to the tracker is cancelled before it's sent - so that visit never reaches OakData, and your numbers quietly undercount.

Browseroakdata.coBlocked ✕Browseranalytics.yoursite.comCNAME → OakDataAllowed ✓
Served first-party from your own subdomain, events look like part of your site - not a third party to block.

Confirming it's the blocker

Open your site in a private window with extensions disabled, or on a device with no blocker, and watch Live. If the visit appears there but not from your everyday browser, a content blocker is the cause. In the Network tab, a blocked request shows up as (blocked:other) or simply never fires.

The fix: serve OakData first-party

Point a subdomain of your own site (like analytics.yoursite.com) at OakData with a single CNAME record, then load the tracker from there. Now the request is first-party - same site as your pages - so filter lists have nothing to match, and you recover the visits blockers were dropping.

Managed reverse proxy

OakData can host this for you - one CNAME and you're done, no server to run. The full walkthrough is in the reverse proxy guide.

Where to next