Introducing Analytics Scanner: A Tool for Validating Analytics Tracking

Introducing Analytics Scanner

We just launched Analytics Scanner. It is a tool for validating how analytics behaves on a real website. You point it at a domain, it crawls a set of pages, and you get a concrete view of what actually happens during navigation.

Check it out at https://analytics-scanner.com.

Why we built it

We built this mainly to stop doing the same validation work over and over again.

If you work across multiple sites or multiple releases, a lot of time goes into answering basic operational questions. Are page views firing once or twice. Are conversions still sending. Did a router change break history tracking. Did a consent update delay initialization. Did someone add a second GA4 property without telling anyone.

All of this is verifiable, but the workflow is manual. You click around. You open DevTools. You watch the Network tab. You use DebugView. You open Tag Assistant. You repeat this across environments and across clients. Even when nothing is broken, you still have to go through the same sequence to confirm that.

That does not scale well, and it is easy to miss things when the validation itself depends on what pages you happened to click and what you happened to notice.

What it does in practice

Under the hood, the scanner runs a real browser and navigates the site the way a user would. It follows internal links, handles SPA routing, and waits between actions so deferred scripts and consent flows have time to initialize.

As it navigates, it records the analytics traffic emitted by the page and groups it by route and platform. That gives you a direct view of what fires on initial load versus on client-side navigations, which events repeat, and which pages never send anything at all.

On top of the raw traffic, the scanner surfaces issues it can infer from what it observes. Duplicate page view events on the same route. Missing page views where navigation clearly occurred. Inconsistent tracking IDs across pages. Requests that fail or error at the network level.

This is the kind of stuff you normally discover indirectly by staring at numbers in GA4 or by stepping through sessions in DevTools. Here it shows up directly in the output because it is derived from the same network layer you would be inspecting by hand.

V1

This is a first version. Right now the focus is on crawling, capturing requests, and flagging the obvious failure modes that show up in real implementations.

At this stage, the scanner observes what happens in the browser and reports on what it sees. It does not try to interpret business intent or enforce a tracking plan. It just works from network behavior.

From here, the direction is mostly additive. More platforms. Better consent handling. Deeper ecommerce signals. More issue types based on the same underlying data.