What analytics cannot tell you

Because there is nothing to count. Analytics is built from events, and an event is a record that something occurred. A screen nobody visited produces no event, so in the data it is indistinguishable from a screen that does not exist at all.

This is not a gap any tool can close by trying harder. It is what counting things means. You can improve the dashboard, sample less, buy the expensive tier, and a screen with no visitors will still be absent rather than reported.

It matters because unreachable screens are common and expensive. Somebody changes a redirect and a whole onboarding step stops being linked. A feature ships and nothing in the navigation points at it. The team believes it is live. The traffic says nothing, because there is nothing to say.

What a screen asked for. You can see that four in ten people left the sign-up form. You cannot see that it demanded a phone number and a company name, because the demand is not an event.

Who was refused. A password rule, an email domain check, a country restriction. Somebody tried, the code said no, they left. Unless a developer thought to record that specific failure, it happened invisibly.

What people can press but never do. A button that exists in your product and has never once been used. Analytics can only compare presses against other presses; it has no list of the things that were pressable.

What changed, and what it did to people. A deployment is not an event in your product. So the connection between the thing you shipped on Tuesday and the fall that began on Tuesday is one somebody has to make by hand, from memory.

In the source code, every time. The code is a complete statement of what was meant to happen: which screens exist, what links to what, what each form requires, which rules can refuse somebody, and what changed between one version and the next.

That is the useful way to think about the two halves. Your code is what you meant. Your analytics is what happened. Neither is the whole picture, and the interesting things are almost always where they disagree: a screen your code says is reachable and your traffic says nobody reached, or a button that exists in the source and has never been pressed.

No, and it would be a silly conclusion to draw. Everything in the "what happened" half is real and you cannot get it any other way. Counting visitors is the first thing any product should do and it takes about a minute.

The point is narrower: it is one of two halves, and the missing half is not a smaller or more advanced version of the same thing. It is a different source entirely, and it is one you already have sitting in a repository.

Putting the two together is what userdrift does. It reads your code, draws your product as a map, and puts the visitor numbers you already collect on every screen. It reads your app and never changes it.