Traditionally, product analysts built funnels based on SQL queries with sequential filtering of events by timestamp within a single session. This approach formed during the web analytics era, where interactions were tied to a single browser and cookies, and the user journey was assumed to be strictly linear. Classic tools like Google Analytics 360 or Yandex.Metrica were designed with the architecture of monotonicity in the funnel, where each subsequent step must follow within the timeframe of the previous one. However, with the evolution of mobile ecosystems and omnichannel interactions, this method began to yield distorted results, ignoring the phenomenon of "delayed decision-making" and switching between devices during a single targeted action.
In modern SaaS products, the funnel ceases to be a one-way pipe. A user may initiate checkout on a smartphone, delay the action, return two days later from a desktop to compare rates, and complete the payment the following week from a tablet after an email reminder. The standard drop-off rate, calculated as the difference between steps within a 30-minute session, will capture a "drop" at the very first break, even though the actual conversion will occur later. This provokes false conclusions about a "bottleneck" and initiates pointless A/B tests aimed at optimizing the wrong step. The analyst's task is to separate true drop-offs from delayed conversions and ensure end-to-end user identification regardless of the interaction surface.
It is necessary to implement user-centric funnel analysis based on probabilistic device matching (probabilistic device graph) and survival analysis to model the time between steps. Instead of a rigid SQL funnel, a Sankey diagram is used, built on a state graph, where nodes represent product screens and edges represent weighted transitions considering the time-decay component. For end-to-end identification, deterministic matching is applied based on authentication, supplemented by probabilistic linking based on behavioral fingerprints (action frequency, scroll patterns, geolocation) with a confidence threshold of 95%. The critical drop-off is determined not by the maximum drop-off but by the largest decrease in hazard rate in the Cox proportional hazards model, which allows for the consideration of censored data (users who have not yet converted but have not completely left). For visualization, Path Analysis in Amplitude or custom Notebooks in Mixpanel with the "holding constant" mode is used — fixing the cohort at the intent level rather than the timestamp of the first event.
In a B2C online course marketplace product, an unexplained drop in conversion was observed at the "payment method selection" step after the checkout redesign. Classic analysis showed a 40% drop-off within an hour, and the product team rushed to revert the changes, deeming the interface unsuccessful.
The first option considered was to build a strict SQL funnel with a 30-minute session window and a strict sequence of events. Pros: simplicity of implementation and high computation speed on ClickHouse. Cons: the method completely ignored mobile-to-desktop transitions and the behavioral trait of delaying purchases until “payday”, capturing a false drop in conversion.
The second option was to implement Google Analytics 4 with Google Signals enabled for standard cross-device tracking. Pros: ready-made infrastructure and built-in integration with advertising cabinets. Cons: aggressive data sampling with high traffic and inability to reliably connect sessions for anonymous traffic, which is critical for our product with a high proportion of guest visits.
The third option was a custom solution based on dbt and Python, where we built a state-machine funnel: each user received a state (browsing, comparing, checkout_started, payment_pending, completed), and transitions were analyzed using the Kaplan-Meier estimator segmented by devices and acquisition channels. Pros: the ability to set an adaptive conversion window (7-14-30 days) and precise identification of the step where real loss of interest occurs rather than just a time lag. Cons: high data engineering requirements and the need for manual validation of the quality of probabilistic linking through a feedback loop.
The third option was chosen as the product had a complex multi-device funnel with a long decision-making cycle. We found that 60% of "lost" users at the payment step returned within 72 hours from another device and completed their purchase. The real bottleneck was not the checkout interface, but the lack of an option to "defer payment and remind via email", which we quickly implemented.
The final result: prediction accuracy of conversion increased from 62% to 89%, and false positive signals regarding "problematic steps" decreased by 70%. This allowed the product team to focus on real growth points instead of struggling with non-existent UX issues.
How to correctly set the time window for the funnel in situations where the product has an irregular usage pattern (for example, once a month), so as not to lose valid converters, but also not to blur the analysis due to overly long tails?
Answer: Here it is critical to apply an active observation window based on percentiles of time between steps for users who actually converted, rather than a fixed calendar interval. It is necessary to build a time-to-conversion distribution and choose the 90th or 95th percentile as the cutoff point for defining successful conversion, while the rest should be considered censored data. It is important to use right-censoring in survival analysis because a user who has not converted within 30 days but returns on the 31st should not be considered lost during the analysis of the first 30 days. It is also essential to segment windows by different intent cohorts: for a trial user, the window may be 7 days; for an enterprise lead — 90 days; otherwise, the metrics will be incomparable.
Why does the standard approach to counting conversion "unique visitors / step completion" distort results in product funnels with retry opportunities, and how can this be accounted for?
Answer: This metric suffers from survivorship bias, as it only accounts for those who reached the step, ignoring those who attempted but encountered an error and left. In SaaS products with complex onboarding, a user may attempt to upload a document three times, face a technical error, and only succeed on the fourth attempt. The standard funnel will count this as 4 visits to the step and 1 conversion, obscuring the real UX problem. It is necessary to switch to an attempt-based funnel, where the unit of analysis is not the session but intent-attempt — a targeted attempt to reach a goal. It is necessary to implement an event_id to group retry attempts and analyze the completion rate per attempt, as well as the error rate between attempts. This will distinguish friction in the interface from random technical failures in the infrastructure.
What methods allow you to separate accidental drop-off from informed churn at intermediate steps of the funnel when you do not have explicit user intent data?
Answer: The key indicator is the analysis of micro-conversions and engagement depth before leaving. If a user spent less than 3 seconds on the step (the dwell time criterion) and did not perform any scroll or interaction events, this is an accidental drop-off that should be excluded from the friction analysis through heuristic filtering or clustering (for example, K-means on the feature vector: time_on_step, number_of_clicks, scroll_depth). Informed churn is characterized by comparative analysis patterns: viewing alternative rates, reading FAQ about refunds, hovering over the close window icon. It is necessary to build a propensity model of churn trained on the behavior of users who explicitly canceled their subscriptions and apply it to current drop-offs to weigh the severity of the loss. It is also important to use qualitative data triangulation: sampling sessions with heatmaps (for example, Hotjar or FullStory) to validate quantitative hypotheses about the nature of churn.