Skip to main content
Start with a question, such as why one browser completes fewer logins or whether a recent change increased retries. Choose the project, dates and relevant filters before comparing results. Pages available in your project depend on its configuration and your console access.

​
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: observed interaction. A field receiving focus or a prefilled value alone does not establish engagement; a completed Conditional UI ceremony does. Input completion can distinguish manual, pasted, autofilled and prefilled values without treating those labels as proof of a particular provider.
Login Overview and Funnel can use different outcome selections. Check whether skipped journeys are included before comparing completion percentages. In Login Overview, the journey outcome control applies to the journey view; it is not a filter for every section.

​
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. 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. 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.

​
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, status 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 how to fix it.
  • 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: affected users and estimated lost completions, with the measured window and any sampling qualification. Population estimates assume the sampled flows are representative.
  • Timeline: the recorded changes, evidence and status updates.
The drawer URL can be shared with colleagues who have access. An explanation remains distinct from the events and measurements supporting it. Reported ignored dimensions are outside that analysis’s filters and should not be treated as part of the measured segment.

​
Follow an incident

The incident status check compares recent error occurrences per attempt in the affected segment with its baseline. The baseline can be the same hours before the incident or the stored comparison group; read the displayed method. An ongoing or elevated rate indicates a measured problem. “Not enough traffic right now” does not establish recovery, and an unknown status means the check lacks the required evidence. Quiet periods alone are not proof that an incident ended.

​
4. Configure alerts and subscriptions

Use Alerting to configure login-success-rate or flow-volume rules and their contact points. Choose the grouping, sample gate, thresholds, pending period and no-data behavior for the question you want to monitor. No data and an evaluation error are distinct from measured zero or a normal result. Login-success-rate rules evaluate finalized hours after the project’s hourly calculation lag. Flow-volume rules account for classification lag. Their results therefore describe eligible data windows, rather than an unfinished running hour. The rule’s Statistics tab summarizes normal, pending, firing, no-data and error states in project-timezone buckets; it refreshes separately from individual evaluations. Contact points support email, webhooks and PagerDuty. Use the contact point’s test before relying on it, and review its delivery hours. A successful test verifies the delivery path; it does not validate the rule’s thresholds or data coverage. API values remain numeric; use the supplied formatting metadata and webhook unit when interpreting percentages versus counts. Page subscriptions send scheduled views. Pause a subscription to stop scheduled dispatch while retaining its configuration; test delivery remains available.

​
5. Refresh and interpret availability

Analytics pages keep their loaded results until an explicit refresh. A calculation completing does not automatically reload an open page. If browser time-series caching is enabled for your project, General settings expose Calculation Optimization with a local opt-out and cache clearing. This setting applies to your browser; it does not change server calculations. Keep required-query failures visible when investigating. Retry the failed section instead of treating missing data as zero activity. Empty projects and unavailable series need data or project configuration before they can produce meaningful comparisons. Continue with exports when you need the same data in your own platform.