1. Compare journeys and cohorts
Open Funnel to follow the decisions, attempts, retries and method switches inside a flow. Select the flow and filter by application, touchpoint, environment or configured custom tags. Cohort comparisons help locate where journeys differ, including platform authenticators versus security keys. Keep the metric’s population in view:- Flow outcome: whether the whole journey completed, was skipped or remained incomplete.
- Attempt outcome: what happened in one method attempt, even if the flow later completed through another method.
- Engagement: whether the classified path contains a qualifying subflow, nested flow or resolved decision. It does not require completion or deliberate user interaction. See Engagement for the rules, including input evidence and Conditional UI.
Inspect time spent at a step
Use the hourglass button on a funnel step to open Time spent. Time in this step measures completed attempts from step start to completion, split by completion method. Time to get here measures from flow start until the step begins, including incomplete attempts and retries that reached that position. These populations differ from the whole-flow time on the funnel card. The dialog keeps the funnel’s filters and uses at most the most recent 14 days of its selected range. Read the sample rate, scaled counts and excluded-attempt notes beside the distribution. Steps above one million attempts require a shorter range or narrower filters. A failed request is not a measured zero.Follow a change over time
Use the funnel’s history and trend views to inspect node, edge and method metrics across daily or hourly buckets. Compare a period with a weekday-aligned earlier period, or compare cohorts within a period. Keep your interval, filters and denominator consistent across both sides. Hourly history selection is limited to 21 days and depends on the hourly data retained by your project. The period comparison separates rate changes from increased or decreased traffic and routes active for only part of a period. Open a traffic item to inspect its history before treating it as a conversion problem. The like-for-like completion change excludes flows through routes flagged for those traffic changes; compare it with the overall change to see how the traffic mix affects the result. A period containing an unfinished or future day is marked Provisional. Counts and rates include observations received for the selected period and can change. Daily traffic-support and start/stop checks use completed calendar days in the project timezone; a completed day does not guarantee that all late events have arrived. A clicked rate change can remain visible as observed evidence even when it fails the automatic finding filters. Check its denominator and the displayed reason, then use View trend to investigate. Absence from automatic suggestions does not establish that no change occurred. Change suggestions distinguish a cohort’s own movement from its gap against a comparison group. A persistent gap deserves investigation even when it has not recently grown. Rankings identify where outcomes are affected; they do not establish causation. When AI is enabled and a usable connection is configured for your project, Explain changes summarizes the visible Find changes rows. Use its references to inspect the underlying evidence; the summary does not establish causation. If the summary fails, retry it. The measured rows remain available, and the control can disappear if AI becomes unavailable for the project. Expanded and hidden funnel nodes are retained in shared URL state. Hiding a node changes the view, not the underlying counts. Share the console URL to preserve the selected view and filters for colleagues with project access.Record context with annotations
Use Settings → Annotations to record context needed to read your project’s data. Choose Event for a release or configuration change, Period for a span such as an outage or experiment, Setup for how the integration works, Interpretation for reading guidance and Constraint for restrictions an analysis must respect. Follow-up records open work with a done condition; closing it requires a result note. Enter dates in the project timezone and choose the precision you actually know. Events and periods can carry an effect, reading guidance and Show on charts. Chart views include visible events and periods touching their selected range; undated context and follow-ups do not become chart markers. Platform annotations apply across projects, appear in UTC and are read-only to project members. Use an annotation’s History to inspect changes and Memory document to download the Markdown context used by agents. Keep measured problems and their lifecycle in findings, and use annotations for the context needed to interpret them.2. Investigate errors
Open Error Overview to inspect grouped errors and their environment correlations. Correlations can include browsers and versions, native app attributes and configured tags. A truncated result is not the complete population; retain the console’s truncation warning when interpreting the largest returned cells. Compare errors across experiment variants in Experiment Analysis. Its table aligns each error across variants and supports severity and presence filters, rate-difference ranking and frequency ranking. A dash means no flows recorded that error in the variant. Error detail depends on the flavours embedded in that project’s variant series; older data may lack that detail. Experiment conclusions depend on the recorded exposure and available sample. Allocation diagnostics help find mismatched exposure, but do not prove that visitors were randomly assigned. Treat observed differences as evidence to investigate alongside your experiment design. For a concrete attempt, use User Search. Follow the journey, then expand its technical events to inspect what the integration supplied. Verify your integration explains this workflow.3. Read a finding
Open Findings for Corbado-authored explanations of authentication problems. Customers see published findings. Corbado manages their content and evidence; internal drafts and notes are restricted to staff. Open a finding’s drawer to review:- Explanation and action: what happens, how to reproduce it and whether a fix or workaround is available. How to fix can offer up to three options, with descriptions, an optional recommendation and a prompt you can review and copy for your coding agent. The remedy badge can also say “Nothing to fix”; an unset remedy has not been assessed. Use the Remedy filter to narrow the list.
- Who is affected: the measured segment, its failure rate and the comparison group. Check the group labels before interpreting the difference.
- What we checked: supported, ruled-out and open hypotheses with their evidence.
- Impact: an authored impact statement takes precedence over the computed analysis. Read its value, unit, population, time window and supporting evidence; it may describe completion loss, time or another impact. No impact reported includes the author’s reason and does not establish a measured zero. When no authored statement is present, the computed analysis shows affected users and estimated lost completions, with the measured window, segment and flow types.
- Computed impact limits: lost completions can be logins, signups, enrollments or other flows; read the measured types and any per-type split before interpreting the total. Affected users are counted across the whole affected group even when completion analysis is sampled. Lost-completion estimates from a sample of the most recent flows are extrapolated to the whole affected population and assume that sample is representative. Older snapshots without a population count may show a lower bound instead.
- Timeline: the recorded changes, evidence and status updates.