Skip to main content
Decisions capture explicit choice points in an authentication journey. Use decisions to track:
  • User choices, for example selecting passkey, password, or social-google
  • System choices, for example policy or backend logic selecting an auth path automatically
Unlike subflows, decisions are not auto-discovered. You define them by sending decision events from your integration.

1. Why decisions matter

Without decision events, complex authentication funnels can be hard to interpret because branch points are only implied by downstream events. With decision tracking, you make branch points explicit, which helps you:
  • Understand where users hesitate or switch methods repeatedly
  • Analyze system-driven routing behavior (for example post-identifier routing)
  • Filter and segment funnels by concrete choice outcomes
  • Measure prompt-style interactions such as “accept” vs “dismiss”

2. Decision model

A decision in Corbado Observe has:
  • A stable decisionName (for example login-method or passkey-enrollment)
  • A list of offered options at the decision point
  • An optional chosen value (explicitDecisionValue) when the decision resolves
Common properties:
  • The same decision can occur multiple times in one flow
  • Available options can change between attempts
  • Decision outcomes can be user-driven or system-driven

3. Decision lifecycle events

Use these Corbado Observe SDK events:
Event methodWhen to sendRequired fields
authDecisionStarted()A decision point becomes visible/activedecisionName, options
authDecisionFinished()A concrete decision outcome is knowndecisionName, options
Set explicitDecisionValue in authDecisionFinished() whenever you know the selected option and want explicit outcome analytics.

4. Track decisions in your integration

Use authDecisionStarted() when choices are shown or become available, and authDecisionFinished() when a final option is selected.
Corbado Observe SDK installation and setup are explained in Getting started.
import { init, getTracker } from "@corbado/observe";

init({
  projectId: "<ProjectID>",
  apiBaseUrl: "<APIBaseURL>",
});

// User sees available auth method choices
getTracker().authDecisionStarted({
  decisionName: "login-method",
  options: ["passkey", "password", "social-google"],
});

// Later, user chooses password
getTracker().authDecisionFinished({
  decisionName: "login-method",
  options: ["passkey", "password", "social-google"],
  explicitDecisionValue: "password",
});
  • Track every important branch point with one consistent decisionName
  • Send authDecisionStarted() whenever options are shown
  • Send authDecisionFinished() as soon as the outcome is known
  • Include all currently offered options in both events for clear context
  • Re-send decision events if users revisit the same choice point
Keep decisionName values short, stable, and implementation-agnostic. Avoid naming that changes with experiments or UI wording.

6. Next steps

  • Continue with Flows to model complete journeys.
  • Continue with Subflows to map concrete auth steps.