Why do users leave your app?

It can tell you where, and that is genuinely useful. It cannot tell you why, and the reason is structural rather than a shortcoming of any particular tool.

Analytics counts events. An event is a thing that happened. So a screen nobody arrived at leaves nothing behind to count, and a rule that turned somebody away before they could submit a form is not an event either. The product has no record of the thing that stopped them, because the thing that stopped them was the absence of an outcome.

Your code has the other half. It states what each screen asks for, which fields are required, what has to be true before somebody is allowed through, and which screens exist at all. Put the two together and the question becomes answerable: this many people got here, this many got through, and here is what the screen demanded of the ones who did not.

Four come up again and again, and each one leaves a different trace.

It asks too early. A form wants a phone number, a company name or a card before somebody has seen anything worth giving it for. The trace is a screen with a healthy number of arrivals and a poor number of departures onward.

It refuses without saying so. A password rule, a country check, an email domain the code rejects. The person is not told what is wrong, so they try twice and leave. The rule is in your code, in plain sight, and it has never been counted against the people it turned away.

It is a dead end. A screen with nothing to press that moves the person forward, or an error state with no way back. Nobody designs these; they accumulate.

They never found it.The screen that would have convinced them exists and nothing in the product links to it. This one is invisible to any tool that only watches traffic, because a screen nobody visited leaves nothing to record.

The mechanical version is short. Take the screens somebody passes through in order. Compare how many people reached each one with how many reached the next. The largest fall is the screen to look at first.

Two cautions, because this is where people go wrong. Comparing two visitor counts over the same week is not the same as following one person from screen to screen, and it should not be described as though it were. And below roughly sixty people a percentage implies a precision the sample cannot support, so count individuals instead: six people is six people.

Then read the code of that screen. What does it ask for, what is required, what rule can refuse somebody, and what can they press to get out.

This is the half that gets missed, and it is worth stating plainly: a tool that only watches traffic cannot report a screen nobody visited. There is no event for a thing that did not occur.

So the pricing page nothing links to, the feature you shipped that no route arrives at, the onboarding step that became unreachable when somebody changed a redirect: none of those appear in an analytics dashboard as a problem. They appear as nothing at all, which reads exactly like a screen that is fine.

Reading the code finds them, because the code is where the absence of a link is visible. One caveat worth holding onto: something you shipped this morning has no visitors because it is new, not because it is dead.

Change one thing, and give it long enough to say something. A fall is not automatically a fault: a screen that loses people may be quietly turning away the uninterested, and removing it can flood the next screen with visitors who leave a minute later.

So treat any change as a question with a test attached rather than a fix with a predicted result. Anyone who tells you a particular change will recover a particular number of customers is guessing, and has dressed the guess up as arithmetic.

If you want this done for you rather than by hand, that is what userdrift is: it reads your code, draws your product as a map, and puts your own visitor numbers on every screen.