Which Tool Category reports Authentication Success Rate

1. Six Tool Categories claim the Authentication Success Rate#

"Which tool reports our authentication success rate?" sounds like a procurement question with one answer. In most enterprises it has six, one per category of tool already in the stack. Each of them reports something different under the same name.

That is why the numbers never match. Analytics says 94 percent, the identity provider says 98 percent, the support queue says something else entirely and every party is reading its own instrument correctly.

1.1 What this article covers#

Section 2 pins the metric down tightly enough to hold a tool against it. Section 3 goes through the six categories one at a time and section 4 puts them side by side in a matrix. Section 5 turns all of that into five questions you can ask in a vendor demo, where two minutes of answers tell you more about the measurement point than any feature list.

2. What an Authentication Success Rate requires from a Tool#

The metric is simple: successful authentications divided by authentication attempts. The difficult part sits in the word "attempt".

Five things have to be true before a tool can report the rate honestly:

1. The attempt is counted before the outcome is known. An attempt recorded on the page after a successful login leaves failures out of the denominator and the rate can only look good.
2. The measurement point is the login itself, not the page around it. The decisive moments happen in the browser's own prompts, which are not part of your page. A tool that watches pages is watching the room the login happened in.
3. The method is a dimension. Passkey, password, OTP and social login fail in completely different ways. An aggregate rate across all of them moves for reasons nobody can attribute.
4. Failures carry a reason. A count of failures is a smoke alarm. A breakdown by cause is a diagnosis.
5. A single journey survives across devices. Cross-device flows start on a laptop and finish on a phone, which often loads nothing at all.

Hold each category against those five points.

The tools disagree because each one looks at a different part of the journey once it is installed and configured normally. Some categories can be extended past their own bar and section 4 covers what that costs:

3. What each of the six Categories sees#

One category per subsection, each held against the five points above. This is a buying view, not a data model. For how these sources are stitched together once you own several of them, the authentication analytics playbook covers that side.

3.1 Web Analytics#

Tools such as Adobe Analytics and Google Analytics 4 measure pages, screens and the events you send them and they are the right home for how a user reached the login and what the session produced afterwards. The limit is structural rather than a question of quality: they report what a tag sends them and a login that fails inside the browser sends nothing. Why Adobe Analytics cannot debug login failures works through the Adobe case, tracking logins in Google Analytics 4 the GA4 one.

Answers: traffic to the login, conversion after it, page-level drop-off. Misses: anything that fails without rendering, navigating or clicking.

3.2 Product Analytics#

Tools such as Amplitude and Mixpanel are event-first instead of page-first, which fits the problem better in principle. A well-instrumented login flow does produce a usable funnel here. The limit is the same one a level higher up: they only know the events your engineers defined. A cancelled Face ID prompt becomes an event only if somebody wrapped the authentication call. Once that is done, the hard part is already behind you.

Answers: funnels over the events you defined, cohorts, retention after signup. Misses: whatever was never instrumented, which is usually the failure path.

3.3 Digital Experience and Session Replay#

Tools such as Quantum Metric, Glassbox, Contentsquare and FullStory reconstruct what the user experienced: rage clicks, struggle detection, form field friction, replay of the session. On a password form that works well. On a passkey login a replay rebuilds your page from what was in the document, while the passkey prompt, the autofill dropdown and the Face ID sheet are drawn by the browser and the operating system on top of it. The moment the login failed is the one frame the recording does not contain.

Answers: friction in your own form elements, hesitation, error messages you rendered. Misses: everything drawn outside the document, which is where authentication now happens.

3.4 Application Monitoring and RUM#

Tools such as Datadog, New Relic and Sentry see the request, the error, the latency and the stack trace. If your login endpoint is slow or throwing, this is where you find out first. What they cover is the server side plus the JavaScript errors nobody caught. A user who dismisses a Face ID sheet does produce an error, usually NotAllowedError, but your own code catches it, so it never counts as unhandled. No request leaves the browser either. Seen from an APM tool, that login never happened.

Answers: availability, latency, server errors, unhandled client exceptions. Misses: user-side abandonment, which produces neither a request nor an error.

3.5 Identity Providers and CIAM#

The dashboards inside Auth0, Okta, Microsoft Entra ID, Ping and similar platforms report what reached their API: authentications, failures by reason code, MFA challenges, risk decisions. That is authoritative for everything server side and it is the number your security team will quote. Two gaps remain. An attempt that never became a request is invisible and most failures on the user's device never become one. The reporting is also organised by tenant and policy instead of by step in the flow, so drop-off inside a multi-step login has to be pieced together from log lines.

Answers: what happened once the request arrived, by reason code. Misses: the attempt that never became a request and the shape of the funnel.

3.6 Authentication Observability#

The youngest category, defined by where it measures: inside the login itself. It wraps the navigator.credentials calls, records what the browser was capable of beforehand, times the call, keeps the outcome and stitches the steps back together across devices. The same measurement point applies to the methods that have nothing to do with passkeys: a password submitted, a one-time code requested and then submitted or not, a step-up MFA challenge answered or abandoned. Each is a step with an entry, an exit and a duration, which is what makes a rate out of it. Its limits belong in the same paragraph. It knows nothing about your marketing attribution, it does not own page-level analytics and it cannot read a reason the browser refuses to give out, only work that reason out from the signals around the call. Corbado Observe sits in this category and authentication observability describes it in full.

Answers: attempts including the invisible ones, method breakdown, error attribution, per-user reconstruction. Misses: everything outside the authentication flow, deliberately.

4. Capability Matrix by Category#

The six categories held against the five requirements above.

"Only if hand-built" carries a lot of weight in that table. The first two rows can technically get there. It takes a JavaScript layer around every authentication call, rules in the tag manager, a schema, the configuration in the analytics tool and someone to maintain all of it whenever browser behaviour changes. That is a component your team owns, not a setting somebody enables.

5. Five Questions to ask an Analytics Vendor#

These five sort the tools faster than any feature list, because they ask where the measurement happens.

1. Where exactly is the attempt counted? If the answer involves a page or a screen, every failure inside the browser is missing from the denominator.
2. Show me a cancelled passkey login in the product. Not on a slide. As a row in a report, in a demo account.
3. The browser returns the same error for cancel, timeout and no passkey. How do you tell them apart? A vendor who claims to read the reason out of the error is describing something the specification does not allow. The credible answer works it out from timing, from what the browser was capable of and from what the user did next.
4. A support ticket says "I cannot log in". What can I see about that one user? If the answer is a segment instead of that person's session, handling tickets stays guesswork.
5. A user starts on desktop and finishes on a phone. What do you record? Most page-based tracking ends the conversation here, as it should.

6. Which Category owns which Login Question#

None of this is a replacement argument. Enterprises run several of these categories at once for good reasons. What matters is which category owns which question, not which one owns the stack.

Reconciling the analytics number with the identity provider number is the cheapest first step and it needs no new contract. Be precise about what it buys you. It exposes definition and population mismatches between the two systems and it exposes attempts the page saw that never reached the identity provider. It does not expose the failures that are missing from both counts. Those need an attempt recorded at the ceremony.

7. How Corbado can help#

Only one row in the matrix above measures where the authentication happens. Corbado Observe is the authentication observability layer that fills it. It is a client-side integration next to the login you already run, it works with any identity provider and any authentication method and it sends UUID-only telemetry with no PII, so it adds a row to the stack instead of replacing one.

• Success rate per method: passkey, password and OTP side by side instead of one aggregate that moves for reasons nobody can attribute.
• Attempts counted at the login itself: cancels, timeouts and aborts through lost focus land in the funnel instead of disappearing from both sides of the fraction.
• Opaque errors given a reason: NotAllowedError broken down by call duration, by client capability and by what the user did next, on the error page.
• One user, end to end: the support ticket question above, answered with a reconstructed session including events, errors and device context.
• On the flows you already run: password, SMS and email OTP, social login and step-up MFA are measured from day one, so the row gets filled in whether or not a passkey rollout is on your plan.

Everything else in your stack keeps its own column.

8. Conclusion: pick by Measurement Point, not by Feature List#

Every category on this list reports something real. They disagree because they measure at different points on the same journey. That disagreement is information rather than an error.

Decide which point you need before comparing feature lists. For how users arrive and what they do afterwards, web analytics already answers it. For whether the authentication itself worked and why it did not, the measurement has to sit inside the login. Only one category does that. The authentication analytics playbook has the metric definitions and passkey analytics covers the passkey-specific metrics in more depth.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

Which tools can report an authentication success rate?#

Six categories touch the question. Web analytics and product analytics report a page-level or event-level version of it, digital experience and session replay tools show the interaction around it, application monitoring reports the server side, identity providers report what reached their API and authentication observability tools measure the ceremony in the browser. Only the last two see authentication directly and they see different halves of it.

Why do my analytics and my identity provider report different login numbers?#

Because they count in different places. Analytics counts what the page observed, the identity provider counts what reached its API. The two use different populations and definitions. That alone makes the reconciliation worth the afternoon. What the difference does not reveal is the failure that happened in between, such as a cancelled biometric prompt or a passkey ceremony that times out, because that failure is absent from both counts. It becomes visible only once an attempt is recorded at the ceremony itself, before the outcome is known.

Can session replay show why a login failed?#

Not for the client-side cases. Replay tools reconstruct the DOM, while the passkey prompt, the autofill dropdown and the biometric sheet are browser and operating system interface elements drawn outside the document. They never appear in a replay, so the moment the login actually failed is the one frame the recording does not contain.

Does an identity provider dashboard cover authentication analytics?#

It covers everything that reached the identity provider, which makes it authoritative for what happened server side. It cannot see an attempt that never produced a request. Most client-side authentication failures never produce one. It also reports per tenant instead of per funnel step, so drop-off inside a multi-step flow has to be reconstructed from log lines.

What should I ask a vendor about authentication analytics?#

Ask where the attempt is counted, whether a cancelled passkey ceremony appears anywhere in the product, how errors are attributed when the browser returns a single opaque code, whether one user's login history can be reconstructed for a support ticket and what happens to a cross-device flow that finishes on another device. The answers separate page instrumentation from ceremony instrumentation quickly.