User flow analysis

User flow analysis is the practice of measuring how users move through the screens and actions inside a product and where they fall away between them. Rather than looking at a single completion number, it follows the route: how many users land on a screen, how many take the next action, how many reach the screen after that, and how the population thins at each step. If 5,000 users open the create-project screen, 3,000 name the project, and 900 invite a teammate, the flow analysis exposes that the steepest drop sits between naming and inviting, not where you assumed.

It matters because a single headline conversion rate or completion figure tells you that something is wrong without telling you where. Flow analysis localises the leak inside the product. It separates a flow that loses people evenly from one that is healthy until a single broken screen, and those two situations call for completely different fixes. The same logic applies to an onboarding sequence, a checkout, a settings change, or any multi-step task in the interface.

The most useful version of this analysis follows the real paths rather than the idealised one. Users go back, skip steps, take a side route through search, and leave through exits you did not plan for. Measuring the actual flow, including the unexpected routes, is what turns flow analysis from a tidy wireframe into a diagnostic that connects to feature adoption rate and retention.

There is no single equation for an entire flow, because a flow is a chain of screens. You measure it by computing the completion rate at each transition and the cumulative drop-off across the whole path. The core unit is the step completion rate: users advancing to the next screen divided by users who reached the current one.

1. 1

   Define the screens and actions

   List the ordered steps that make up the flow, from entry to the action you care about. Keep the definition stable, because changing step boundaries mid-measurement makes period-over-period comparison meaningless.

2. 2

   Count distinct users at each step

   For every screen or action, count the distinct users who reached it. Use distinct counts rather than raw events, so one person revisiting a screen does not inflate that step.

3. 3

   Calculate step completion rates

   For each transition, divide the count advancing to the next step by the count reaching the current step. This is where the leak shows itself: the lowest step completion is the weakest link in the chain.

4. 4

   Track cumulative drop-off

   Multiply the step completions together to get the share of starters who finish the flow. This shows how a few moderate drops compound into a large overall loss across a long flow.

A worked example: 5,000 users open the create-project screen, 3,000 name the project, 900 invite a teammate, and 600 complete setup. The step completions are 60 percent, 30 percent, and 67 percent. The 30 percent from naming to inviting is the weakest transition, so that is where a one-point improvement returns the most. The cumulative path completion is 12 percent, which is what compounds across every step. Flow analysis stops you from polishing the 67 percent screen that already works while the 30 percent screen bleeds.

A metric tree maps the flow onto its sequence of transitions and then decomposes each transition into the friction points that govern it. The headline outcome, end-to-end flow completion, sits at the root. The first level is the set of screen-to-screen transitions, because the product of those transitions is the whole flow.

Each transition then breaks into the specific reasons people fail to advance. The name-to-invite branch, for example, decomposes into unclear next step, permission friction, and a side route through search that pulls people out of the flow. This is the level where an intervention becomes concrete: you are no longer trying to fix the flow, you are fixing the button that 40 percent of people never find.

KPI Tree gives each transition a RACI owner, so the onboarding squad is accountable for the early setup steps while the collaboration team owns the invite step. When a step completion drops, the platform pushes the change to the owner of that specific transition rather than to a generic product dashboard nobody owns. The verified impact loop then confirms whether the change to that screen actually lifted downstream completion, so a local win is not mistaken for a flow-wide one.

Benchmarks for in-product flows depend heavily on the type of task, the user context, and how much effort the step demands. The ranges below give realistic step completion expectations for common product flows, useful as a sanity check rather than a target to chase.

Treat these as bands, not goals. The more important comparison is your own trend over time and the gap between adjacent steps. A single transition far below the others is the signal, regardless of how the absolute number compares to an average. Segmenting the flow by device, plan, or new versus returning users often reveals that one group drags the whole flow down.

Improving a flow starts with finding the weakest transition and understanding why people leave that screen specifically, rather than spreading effort evenly across a flow that is mostly healthy. The discipline is to fix one leak, verify the downstream effect, then move to the next.

KPI Tree connects each transition to the team that owns it and to the downstream outcome it feeds. Onboarding owns the early setup screens, the core product team owns the main action, and the collaboration team owns the invite step. When a step completion drops, the accountable owner of that transition is notified directly, and the verified impact loop checks whether their fix flowed through to final completion, so you can tell a genuine flow improvement from a leak that simply relocated.

1. 1

   Measuring totals instead of transitions

   Watching only the end-to-end completion rate tells you that the flow is leaking but never where. The diagnostic value lives entirely in the step-to-step completions.

2. 2

   Mapping the ideal path, not the real one

   Users go back, skip steps, and leave through exits you did not plan for. Analysing only the path you designed misses the screens where people actually drop.

3. 3

   Counting events instead of distinct users

   Using event counts lets a single person revisiting a screen inflate that step and distort the completion rate. Count distinct users at every step.

4. 4

   Optimising a screen that already works

   Improving a strong transition while a weak one bleeds wastes effort. Always start with the lowest step completion, because it constrains everything downstream.

5. 5

   Changing step definitions mid-stream

   Redrawing where one step ends and the next begins breaks every comparison. Fix the step boundaries before measuring, and keep them stable across releases.