A funnel that “leaks” 40% between add-to-basket and checkout is presented, in most product rooms, as a conversion problem. Sometimes it is. Often it is two events firing for the same tap, a guest path that never hits the named step, or a webview that does not share a user id with the native shell. Leakage, in those cases, is not a behaviour. It is a filing error.
Before we let anyone brief design on a leak, we ask three questions. Does the step exist on every surface, including the widget and the email deep link? Is the event a user verb or a screen appearance? Can you find ten raw rows that look like a completed job but never enter the next step? If the answer to the third is yes, you do not have a UX problem yet. You have a join problem.
The grocery case we still talk about had a proud five-step checkout. Two of the steps were the same add, named differently by two squads. Collapsing them made conversion look worse and the ops meeting shorter. That is the direction we prefer.
Funnels are allowed to exist. They are not allowed to be the only object in the room. A completed order with a time, a payment state, and a limitation note (“logged-out add is invisible on iOS 17 webview”) will outlast a coloured triangle. If you need the triangle for a slide, draw it after the rows are honest.
Session Reconstruction exists because some leaks are real: rage, confusion, a disabled button. We look at those after the event names have stopped lying. Doing it the other way around produces very confident films of the wrong people.