Analytics Installed But Showing Zero Users? Here Are 7 Reasons Why

This is the most common reason for analytics installed zero users situations, and it is also the one people check last because it feels too simple. Standard reports in GA4, Mixpanel, and most major analytics platforms do not update in real time. GA4's standard reports can take 24 to 48 hours to reflect data that has already been received. Mixpanel is generally faster but can lag by hours on cold starts, especially for a brand-new project that hasn't received any events before.

The reason this catches people is that the installation looks identical whether events are flowing correctly or not. You set everything up, you visit your site, and you check the Users report the same day. It says zero. So you assume something is broken, and you start pulling the install apart to find the problem. Meanwhile the data is sitting in a queue, perfectly fine, waiting to be processed.

Most analytics tools with real-time reporting have a Realtime report or a Live view that updates within seconds, not hours. This is specifically designed to let you verify that your installation is working before the standard reports catch up. If you see yourself appear in the Realtime report when you visit your site in another tab, the installation is working correctly and you just need to wait.

uBlock Origin, Brave Shields, Firefox Enhanced Tracking Protection, and Safari Intelligent Tracking Prevention all block major analytics scripts by default. This is not an edge case. Developer and technical audiences, which tend to be exactly who shows up first for a new product, run ad blocker penetration rates of 30 to 50 percent in some studies. If your early adopters are mostly developers or technically sophisticated founders, you could be installing analytics correctly and still missing half your traffic from day one.

The maddening part is that there is no error in your DevTools console when an ad blocker blocks a script via its own rules (as opposed to a CSP block, which does log an error). The script just never loads. No requests appear in the Network tab. No users appear in analytics. It looks identical to a broken installation because, from the browser's perspective, the script never ran.

You cannot fix this from inside your analytics tool. Ad blockers operate at the browser level, and their block lists are maintained independently of what any analytics company does. The structural solutions are server-side event tracking (your server sends events to the analytics platform, not the browser), or a first-party proxy where analytics requests go to your own domain before being forwarded on, so the browser doesn't recognize them as a third-party analytics request. Both require meaningful engineering work.

Single-page applications built with React, Next.js, Vue, Nuxt, or SvelteKit do not reload the page when a user navigates between routes. The user clicks a link, the URL changes, the component updates, but there is no full browser page load. Most analytics tools trigger their pageview event by listening to the browser's page load event, which fires once, on the initial load, and then never again for the rest of the session.

The result is that your analytics sees every user as having visited exactly one page. They land on your homepage, analytics fires one event, and then every subsequent click through your app is invisible. If you are on a plan or viewing a report that counts "active users" based on event count, one event per user with no follow-up activity can sometimes look like zero meaningful engagement, or in some configurations, zero tracked users at all.

This is actually a very common source of the analytics showing 0 users problem, because developers install analytics on a new project, click around the app from their own browser (where they probably also have an ad blocker), and the only session that shows up has one pageview and immediately bounced, which gets filtered out in some default views. The analytics installed zero users diagnosis often ends here once you add router event listeners.

A Content Security Policy (CSP) is a set of HTTP headers your server sends to the browser, telling it which domains are allowed to load scripts, make fetch requests, set cookies, and so on. CSP headers are a legitimate security feature, and if you are using a strict CSP (which you should be), any script not explicitly allowlisted gets silently blocked by the browser before it ever runs.

The word "silently" is the key: a CSP block does not produce a failed network request in the way that a 404 does. The script never loads at all. From your analytics platform's perspective, you simply don't exist. From your browser's perspective, the script was prevented from running. This is exactly what you want from a security standpoint, but it means analytics is dead if you forgot to update your CSP when you added the SDK.

Unlike ad blocker blocks, CSP violations do produce a visible error in the browser console, and this is one reason the DevTools console check at the top of this article is so valuable. The error will read something like "Refused to load the script 'https://cdn.analytics-provider.com/sdk.js' because it violates the following Content Security Policy directive: script-src 'self'." That error message tells you the exact domain you need to allowlist.

Most analytics SDKs are designed to fail gracefully, which sounds like a good thing until you realize what "fail gracefully" means in practice: they swallow errors, continue executing without throwing, and do not tell you that initialization failed. You call analytics.init('wrong-api-key-here'), the SDK accepts the call without complaint, and then every subsequent analytics.track() call fires into a void. No console errors. No network requests. No data.

The most common causes are a mismatched API key (you copied the key from the wrong project, or you copied the test key instead of the production key), options passed in the wrong order or with a wrong property name (the SDK ignores unknown options silently), or track() and identify() calls being made before init() has finished executing, which can happen in async component trees where execution order isn't guaranteed.

This one looks exactly like an ad blocker: complete silence, no network requests, no errors in console, no data in analytics. The difference is that it affects all browsers equally, including clean profiles with no extensions. If your fresh-browser test from reason 2 also shows zero users, and the console is clean, initialization is a strong candidate.

If your application uses SSR through Next.js, Nuxt, Remix, SvelteKit, or any other framework that executes JavaScript on the server, there is a class of bug that trips up even experienced developers: analytics code that runs during server rendering tries to access browser APIs (window, document, navigator) that don't exist in a Node.js environment. The result is either a thrown error that breaks your build, or more commonly, a silent failure where the SDK initializes as a no-op on the server and never actually tracks anything.

This is especially sneaky when you import the analytics library at the top of a file that gets server-rendered. The import succeeds, the SDK loads its module, but when it tries to set up its internal state (which typically involves reading from window.localStorage or accessing document.cookie), it fails silently because those APIs return undefined on the server. Every event call after that point is a no-op.

The tell is that your SSR logs on the server look fine, but the browser never sends analytics requests. A console log inside analytics.init() prints on the server but not in the browser, because the init call is in server-side code, not client-side code.

Development, staging, and production environments almost always have separate analytics projects, because you don't want your own testing activity polluting your production metrics. That means your codebase has at least two analytics API keys or project IDs: one for the dev/staging environment and one for production. The analytics installed zero users problem often turns out to be this: your production deployment is still using the dev key, so real user traffic is going into a dev project you never open.

This happens easily. You set up the SDK during local development, hardcode the dev key to get it working, then deploy to production and forget to update the environment variable. Or you copy a .env.example file that has placeholder values, and one of those placeholders is the analytics key from your dev project. The production app runs, events fire, everything looks fine in DevTools, but the data lands in the wrong bucket.

A related variant is having analytics pointing to the right project but the wrong data view or workspace within a project. Mixpanel has projects inside organisations. Segment has sources and destinations. It is worth confirming the full chain from "where the SDK sends events" to "where you are looking in the dashboard" is actually connected end-to-end, not just partially.