---
url: 'https://www.corbado.com/kpi/login-success-rate'
title: 'Login Success Rate'
description: 'Share of login method attempts that result in a successful authenticated session, measured from the moment a user starts a method.'
lang: 'en'
---

# Login Success Rate

## What is the Login Success Rate?

**Login Success Rate** (from starting a method) measures how often a user who starts a
specific login method ultimately reaches the intended authenticated state. It tells us
whether the method works end to end once a user commits to it, which makes it a strong
signal of reliability and usability inside the method flow.

> **Key facts on Login Success Rate (from starting a method)**
> 
> - **What it captures**: The probability of reaching an authenticated session after a
>   method start
> - **Primary use**: Detect method failures and friction that happen after the user begins
> - **Interpretation**: Closer to 100% is better, sudden drops usually indicate a regression
>   or an upstream dependency issue

## Where does the Login Success Rate fit in the login funnel?

We measure **Login Success Rate** from the moment a user starts a specific method to the
moment we create an authenticated session for that same attempt. Measurement boundary:
start at the first server or client event that confirms a method attempt began, end at the
first event that confirms an authenticated session was issued.

```mermaid
flowchart LR
    OM((Offer
Method))
    SM((Start
Method))
    CH((Method
Steps))
    SA((Authenticated
Session))

    OM --> SM --> CH --> SA

    SM -. "LOGIN SUCCESS RATE" .-> SA
```

## How to calculate the Login Success Rate?

We calculate **Login Success Rate** per method attempt. We count an attempt once, at the
moment the method is started. If a user retries, that creates a new attempt.

> $$\text{LSR}=\frac{\text{Logins succeeded after Method Start}}{\text{Method Attempts started}}$$

`Logins Succeeded after Method Start` is the number of method attempts that end in an
authenticated session. `Method Attempts Started` is the number of method attempts that
actually began.

### Numerator: Logins Succeeded after Method Start

Count an attempt in the numerator when we log a definitive success event like
`Auth Session Issued` that is linked to the same attempt id as the
`Method Attempt Started` event.

Do not count attempts that only reach an intermediate state, like code sent, challenge
shown or device enrolled, if an authenticated session is not issued for that attempt.

### Denominator: Method Attempts Started

Count an attempt in the denominator when we log `Method Attempt Started` for a specific
method. This should happen when the user has taken an action that commits them to the
method flow, not when the method is merely displayed.

Do not count passive impressions, preselected methods with no user action, or attempts
missing an attempt id that prevents joining start to outcome.

### How to use Login Success Rate to improve outcomes

We use **Login Success Rate (from starting a method)** to find where method flows fail
after commitment, then remove friction or fix reliability issues.

We can improve the following business outcomes:

- **Higher successful sign ins that reach the intended authenticated state**
    - Diagnose: drops concentrated in one method or one platform
    - Change: fix client regressions, server validation bugs, or third party outages
      impacting that method
    - Validate: the KPI recovers for the impacted segment without an increase in retries
      per user
- **Lower user drop off during authentication**
    - Diagnose: failures cluster at specific step types like code entry or push approval
    - Change: reduce step count, improve message delivery speed, tighten error handling
      and recovery screens
    - Validate: improved KPI plus fewer abandoned attempts for the same cohort
- **Lower support contacts caused by authentication issues**
    - Diagnose: KPI declines aligned with increases in user reported lockouts or non
      delivery
    - Change: improve deliverability controls, clearer user messaging, safer rate limits,
      better self serve recovery inside the method
    - Validate: KPI improves and support contact rate falls for affected categories
- **Lower fraud and abuse exposure that comes from weak or bypassed authentication**
    - Diagnose: KPI rises because challenges are skipped, not because users succeed
      legitimately
    - Change: enforce step integrity, harden decisioning, verify bindings between attempt
      and session issuance
    - Validate: KPI stays healthy while fraud signals and chargeback like outcomes do not
      worsen

### Blindspots and common pitfalls of Login Success Rate

- **Intent and selection bias**: users who start a method are already a filtered group. If
  we change which users reach the start event, the KPI can move even if the method did
  not.
- **Missing telemetry or inconsistent logging**: if `Method Attempt Started` fires on some
  platforms but not others, or if success events are not linked by attempt id, the KPI
  becomes inflated or deflated in ways that look like product change.
- **Mix shifts across segments**: a shift toward easier devices, better networks, lower
  risk users, or a different method mix can increase the KPI while some segments degrade.
- **Duplicate success events**: if `Auth Session Issued` is emitted more than once per
  attempt, the numerator can exceed reality unless we dedupe by attempt id.