Analytics blocked by ad blockers

Ad blockers are doing what they advertised. If script.js loads from an analytics host, there is a decent chance EasyList or a cousin never lets it run. Your dashboard then describes a quieter, richer, more "engaged" audience than the one that actually showed up. That audience is the people who do not run uBlock.

SiteLine does not magically appear first-party. The default snippet points src and data-endpoint at SiteLine. That is third-party to the browser. Some lists will ignore it. Some will not. You will not get a percentage from us. Measure with and without a blocker on a real page.

What blocking looks like in SiteLine

• Live stays dead while you can see the page yourself.
• Network tab: script.js never loads, or collect POST never fires, or both.
• GSC clicks exist for the URL; analytics pageviews on that path are far lower. (Also caused by missing snippet, wrong allowlist, or redirects — check those first.)
• GA4 is also low, but not by the same amount, because the blocklists and the identity models differ.

Bots are a separate filter. SiteLine drops known crawler user agents before quota. An empty Live on a site that only gets Googlebot is correct. An empty Live on a site with paying humans and a red blocked request in DevTools is ad blocking or a bad endpoint.

What actually reduces loss

Reverse-proxy two paths on the site's host:

• /js/script.js
• POST /api/analytics/event

Load them same-origin. Full configs (nginx, Caddy, Cloudflare Worker skeleton, Vercel rewrites): proxy docs. SiteLine does not manage CNAMEs. If someone on your team is waiting for an "analytics.example.com" record SiteLine will provision, they will wait forever.

React apps: set endpoint to the first-party collect URL. Do not proxy the script and leave collect on SiteLine.

This reduces loss. It does not eliminate it.

• Lists match path patterns (/api/analytics, script.js, plausible, umami, generic "collect" names).
• Some blockers inspect CNAME chains and still classify the upstream.
• Privacy browsers drop or partition more than cookies; SiteLine is already cookieless and still needs a successful POST.
• Corporate proxies and Safari ITP are not the same as uBlock, but they also drop traffic.

If you need "every human," you need a world without blockers. You do not have that world.

What not to do

• Do not rename script.js to beacons.js and call it a strategy. Paths still have to proxy to SiteLine's /js/script.js unless you are doing something undocumented. This product expects those two upstream paths.
• Do not inject the tracker only after a "marketing cookies" opt-in if the rest of your story is cookieless. You will empty the dataset for the people who clicked reject, which is most of them. Counsel may still require a banner for other vendors; do not fold SiteLine into that gate by habit.
• Do not disable the hostname allowlist in your head. It is not optional. Events from unknown hosts are rejected.
• Do not "make up" blocked traffic in a spreadsheet so the client deck matches ads.

A practical order of operations

1. Confirm the snippet is on the page and the public id matches Install.
2. Confirm data-endpoint is absolute (or same-origin after a proxy exists).
3. Confirm allowlist includes the host you typed in the address bar.
4. Open the page with blockers disabled. Live should move.
5. Open it with a popular blocker enabled. Note whether script.js / collect disappear.
6. If they disappear and the gap matters, put the proxy in front of both paths.
7. Re-test with the blocker on. Expect improvement, not 100%.
8. Write the remaining gap into the report as instrumentation reality.

Quota: events that never arrive do not count. Events that arrive through the proxy do. Billing does not discount for ad-blocker loss.

Goals and funnels cannot recover blocked hits. If step 1 is a pageview the blocker ate, the visitor was never in the funnel.

FAQ

Will a first-party proxy get us past every list?

No. It is the correct mitigation for "blocked because the host is SiteLine." It is not a stealth mode.

Does cookieless tracking avoid blockers?

No. Blockers key off script URL, request URL, and known tracker behavior. Cookies are a different fight. SiteLine's daily hash is a privacy model, not an unblockable one.

Should we dual-tag GA4 and SiteLine to compare loss?

You can. You still will not know the true visit count. You will know two incomplete series. Use GSC clicks as a lagged lower bound for search landings only, not for all traffic.