Authentication Drop-Off Rate

Authentication Drop-Off Rate is the share of authentication attempts where a user starts the login journey but does not reach a completed authenticated state. It captures silent abandonment caused by friction, confusion, delays or broken steps, even when no explicit error is shown.

Typical benchmarks vary by product and audience, but teams often use these reference ranges as a starting point.

We measure Authentication Drop-Off Rate from the moment an authentication attempt is started, for example when the user starts a method to the moment the attempt is completed, meaning the user reaches the intended authenticated state. Measurement boundary: we count within a single auth attempt identifier and we treat the first terminal completion event as the end of the attempt.

flowchart LR
    OA(("Offer<br/>Auth"))
    OM(("Offer<br/>Method"))
    SM(("Start<br/>Method"))
    SuM(("Success<br/>Method"))
    SuA(("Success<br/>Auth"))

    OA --> OM --> SM --> SuM --> SuA

    OA -. "ENGAGEMENT RATE" .-> SM
    OM -. "METHOD CONVERSION" .-> SM
    SM -. "METHOD SUCCESS RATE" .-> SuM
    SM -. "AUTH SUCCESS RATE" .-> SuA

Get the Authentication Analytics Whitepaper

Analyze your Authentication Performance with Real Numbers

10 KPIs that connect authentication performance to revenue. Track adoption, friction & conversion impact.

Download the Authentication Analytics Whitepaper

Work email *

Name *

Company *

Job title *

Get Whitepaper

For Authentication Drop-Off Rate, the unit of analysis is an auth attempt. We count each attempt once, even if the user retries steps inside that same attempt.

Auth Attempts started is the number of distinct attempts that emitted a start event. Auth Attempts Completed is the number of those attempts that emitted a completion event within the same attempt scope and time window.

We count attempts that started but did not complete. This includes user exits, timeouts and flows that end without a completion event. We do not count attempts that never emitted a start event and we do not double count multi step retries within the same attempt.

We count distinct attempts that emitted a start event, such as a method start or first credential submission, based on your instrumentation. We do not include page views with no start signal and we exclude clearly duplicated start events when the same attempt is retried due to client refresh.

We use Authentication Drop-Off Rate to find where intent turns into abandonment, then remove friction while keeping the security bar intact.

We can improve the following business outcomes:

• Higher successful sign ins that reach the intended authenticated state, diagnose high abandonment at password or code entry, add passkeys and streamline input and autofill, validate with a sustained drop and stable completion volume.
• Lower user drop off during authentication, diagnose spikes by device or app version, fix latency and rendering issues, validate with improved mobile drop off and unchanged traffic mix.
• Lower support contacts caused by authentication issues, diagnose concentration in reset and challenge steps, simplify recovery and reduce unnecessary challenges, validate with fewer help tickets and fewer repeat attempts per user.
• Better operational cost through fewer retries, diagnose excessive repeated starts per attempt, tighten state handling and reduce resend loops, validate with fewer attempts per successful completion.

• Intent and selection bias. Users who click sign in are not equally motivated across entry points, so overall changes can reflect intent shifts, not experience changes.
• Missing telemetry or inconsistent logging. If completion events fail to fire on some clients, drop off will look worse than reality. If start events are logged too early, drop off will look inflated.
• Mix shifts across segments. A shift toward higher friction methods, more mobile traffic, or more new users can raise the rate even if each segment is stable.
• Time window choices. Short windows over count slow completions as drop off. Long windows can hide timeouts that matter.

Report the overall number, then break it down by auth method, device type, entry point, last observed step, and client version. Add alerting on step level spikes, since that is where fixes are usually clearest.