Browser Extension

Ad blockers and privacy extensions commonly block requests to analytics domains and script files by name. When the script or the beacon is blocked, no visit is counted. This is expected behavior, not a configuration error you can fix on your end.

How extensions block tracking scripts

Ad-blocking and privacy extensions maintain filter lists — databases of hostnames, URL patterns, and script names that are commonly used for tracking. When your browser requests a resource that matches a filter entry, the extension blocks the request before it reaches the network. The browser never receives the file, and whatever purpose the file served is simply not performed.

statelessid.com and asset.js are recognizable as analytics tooling by their naming and behavior. Some filter lists may include them. A visitor using uBlock Origin, Privacy Badger, Ghostery, AdGuard, Brave Shields, or similar tools may have requests to statelessid.com blocked automatically, without the visitor having taken any explicit action to block your site specifically.

The block is silent. The page renders normally. No error appears in the browser console that your visitors see. The visitor has no indication that any blocking occurred. From your dashboard's perspective, the visit simply does not exist — there is no partial record, no blocked-beacon counter, no way to know it happened from the dashboard.

How to test for extension interference

Open your site in a private or incognito browsing window with extensions disabled. Most browsers disable extensions in private mode by default, though some extensions opt into private mode explicitly. Use a browser profile you have never installed extensions into, or use a different browser entirely, to get a clean environment.

Open the developer tools Network tab before loading the page. Load the page. Check whether requests to statelessid.com appear. If they do in the clean environment but do not in your normal browser profile, an extension in your normal profile is blocking them. This tells you your instrumentation is working correctly; the missing counts are from your own browser testing with extensions active.

This test also reveals whether you yourself are inadvertently filtering your own site during development. If you test your site frequently with an ad blocker active, your own visits will not appear in the dashboard. This creates the appearance of low traffic that does not reflect what your real visitors experience on browsers without blocking extensions.

What the block means for your visit counts

Visitors who use tracking-blocking extensions are not counted in your dashboard. Their page loads are real — they arrived, they read your content, they may have converted — but their beacons never fired. The visit count in your dashboard is a minimum: it represents page loads that were not blocked. The true number of page loads is higher by some amount you cannot measure from within the dashboard.

How much higher depends on your audience. Technical audiences, privacy-conscious audiences, and audiences who have been using the web long enough to install extensions tend to have higher blocking rates. A developer blog may have 30–50% of its visitors blocking analytics. A general-audience retail site may have far fewer. Neither rate is something your dashboard can report — the blocked visits leave no trace.

This is a structural fact of how client-side analytics works, not a problem unique to StatelessID. Cookie-based analytics tools, server-side logging, and other approaches each have their own blind spots. Client-side script blocking is one of the most predictable of those blind spots.

Is there a workaround

Some hosting setups proxy requests to analytics endpoints through a first-party domain — instead of the browser calling statelessid.com directly, it calls yoursite.com/analytics, and your server forwards the request. This approach can evade domain-based blocking because filter lists cannot easily block requests to your own domain without breaking other functionality.

StatelessID does not currently provide a built-in proxy mode. If your hosting setup supports reverse-proxying and you want to implement a proxy path, the beacon endpoint details are available in the technical documentation. Understand that this approach changes what filter lists can detect and may have implications for your privacy disclosures. Setting up a proxy is a self-managed undertaking.

Troubleshooting

If your own dashboard visit count seems lower than your server access log count, extension-blocked visits are the most common explanation. Server logs record every HTTP request that reaches the server, including those from visitors whose browsers block client-side scripts. Comparing the two counts gives you a rough sense of the blocking rate for your audience.

If a colleague reports that visits do not appear after they browse your site, ask whether they have an ad blocker or privacy extension installed. Have them open the developer tools Network tab and load the page with you watching. If no request to statelessid.com appears, the extension is blocking it. This is not a misconfiguration — it is the extension doing what it is designed to do. Their visits will not appear in the dashboard.

If you are testing your own site and notice that none of your own visits are appearing, check your browser extensions before concluding something is broken. A single visit in a clean browser environment that produces a count in the dashboard confirms the instrumentation is working. Absent visits in your normal browser are almost certainly blocked by your own extensions.