Why Adobe Analytics cannot debug Login Failures

1. Adobe Analytics reports what a Tag sends, not what the Browser did#

Adobe Analytics measures what happens after a login. Why a login did not happen is a different question. For the logins that now run inside the browser itself, passkeys above all, Adobe has no data to answer it with. Sections 3 and 4 make that case in detail and section 5 prices up what closing the gap inside Adobe would cost.

The reason is not a weakness of the product. Adobe reports what a tag sends it. A login that fails on the user's own device sends nothing at all. A cancelled Face ID prompt, a password manager overlay covering the form, a passkey offered in the browser's autofill dropdown and ignored: none of them produce a page load, a click or a link call. In an Adobe funnel they look exactly like somebody closing the tab. Classic password logins are the easier case here, because a rejected password usually still renders something, which is why this article is mostly about the client-side methods where nothing renders at all.

Two things are worth saying before the passkey examples start, because they decide whether this article is about your stack. The first is that the gap is client-side rather than passkey-specific: a one-time code requested and never submitted, a user who leaves for their SMS inbox and does not come back, a step-up MFA challenge that stalls, all produce the same silence in a page tag. The second is that the passkey cases are simply where the silence is total, which makes them the clearest way to show the mechanism. If you have no passkeys in production, sections 4 to 7 still apply to the flows you run today.

1.1 What this article covers#

The four authentication failure types that never reach a tag, what they do to your login success rate, what it takes to instrument them inside Adobe and which questions belong in which tool.

2. What Adobe Analytics does well for Login Funnels#

Adobe is a strong product and enterprise analytics teams know it well, so it is worth being precise about where the limit sits.

Fallout and Flow visualizations handle funnels properly. Adobe's own documentation names "a purchase or registration process" as a use case, there is no limit on the number of touchpoints and you can mix dimensions, metrics and segments freely as steps. Calculated Metrics handle rates in a single definition: divide one event by another, format as percent, done. Customer Journey Analytics goes further and supports person-level analysis when stitching is configured.

So the problem is not that Adobe cannot build a login funnel. It sits one layer below the report.

Adobe reports what a tag gives it. A passkey login gives a tag nothing.

3. Four Login Failures that never reach a Tag#

The four cases below are not four versions of the same thing. The first is a reason a login fails, the second is what that failure looks like in your code, the third is a passkey offer the user never acts on and the fourth is a login that moves to another device. One login can run into all four.

Held against what the tag recorded, all four sit in the same gap. The tag sees the login page load and it sees whatever hit comes next, if there is one at all. What separated the two is missing:

3.1 Focus Loss cancels the Passkey Ceremony#

One piece of vocabulary first, because the rest of this section needs it. The ceremony is the part of a passkey login that the browser runs: your page makes a call, the browser shows the Face ID or Windows Hello prompt and hands back either a credential or an error. Everything in between belongs to the browser, not to your page.

And it is fragile. The Web Authentication API cancels a running create() or get() call as soon as the browser window loses focus. MDN states this directly: the calls "are canceled if the browser window loses focus while the call is pending", for security reasons.

A user who switches to their password manager app to look something up has just aborted their own passkey login. No error page renders, no link is clicked, nothing navigates. There is no hit.

3.2 NotAllowedError hides Cancel, Timeout and no Credential#

When a passkey login fails, the browser almost always returns the same error: NotAllowedError. The W3C specification uses it for three completely different situations. The user cancelled. The ceremony ran out of time. Or there was no passkey on the device to begin with.

That is deliberate. If the browser said "you have no credential here" instead of "you cancelled", any website could quietly test whether a visitor has a passkey registered. The W3C looked at adding separate NoCredentialsError and UserCancelledError codes in issue #2062 in April 2024 and closed it without them.

More tools do not fix this. We have analysed production passkey deployments that run five separate observability platforms side by side, covering web analytics, real user monitoring, session replay, feature flagging and device fingerprinting. Every failed ceremony reaches all five as the same string: the operation either timed out or was not allowed, NotAllowedError.

The consequence applies to every vendor including us: no tool can read the reason out of the error object. What a tool can do is work the reason out from what surrounded the call. Was passkey autofill available and active on this device? What did the browser report it was capable of? How long did the call run before it failed, given that half a second looks like somebody cancelling and five minutes looks like a timeout? And which path did the user take next?

All of that has to be collected while the login is running. Afterwards it no longer exists. It was never in the page to begin with.

3.3 Passkey Autofill leaves no Trace on the Page#

Passkey autofill, or conditional mediation, behaves unlike any other login interaction. Your page starts a get() call that then simply waits. Nothing appears until the user taps an input field marked autocomplete="username webauthn". At that point the browser offers the passkey in its own dropdown.

That dropdown is drawn by the browser, on top of your page rather than in it. No element appears in the document, no click handler fires, no form is submitted and nothing navigates.

Activity Map makes this concrete. It tracks links with an href, form submits, buttons and elements carrying an s_objectID or a tl() call. A passkey dropdown is none of those, because it is not part of your page at all.

So the central question in a passkey rollout, whether the user was offered a passkey and ignored it, has no answer in the page. Session replay runs into the same wall: a replay rebuilds the document and none of this ever touched the document.

3.4 Cross-Device Logins lose the Middle of the Journey#

In a cross-device login the user starts on a desktop and finishes on their phone. The desktop shows a QR code, the two devices check over Bluetooth that they are in the same room and the passkey itself stays on the phone.

The phone never loads your page. It fires no tag and Adobe never gives it a visitor ID. The result does come back to the desktop, because the phone only stands in as the authenticator and never opens a session of its own, so a success event can fire there. What does not come back is the middle: what the phone showed, how long the user hesitated, whether they scanned at all. Adobe sees two desktop hits with a gap in between. That gap could be anything.

4. Four Ways the Login Success Rate goes wrong#

Most enterprise teams define login success rate as successful logins divided by login attempts. In Adobe that is one Calculated Metric and building it takes about five minutes.

Three things go wrong before you get there and the metric shows none of them.

First, the events may not exist. The Adobe Experience League community sees the question regularly: how to report on logins when nobody ever implemented a login event. The accepted answer is a sequential segment that infers a login from a state change, counted with the Occurrences metric. It works. It also means your login number is reconstructed from a variable that describes the page, which is not the same as measuring an authentication.

Second, the numerator and the denominator may live in different report suites. Web, native app and transactional email are frequently instrumented separately. Adobe is explicit about what that costs: "Data from multiple report suites cannot be combined in tables, segments or calculated metrics (summed, divided, etc)." Two report suites can sit side by side in one Workspace project, but one cannot be divided by the other. That is where the second dashboard and the manual arithmetic come from. No amount of skill on the analytics team removes it.

Third, the failures may be missing from both sides of the fraction. Picture a user who opens the login page, gets a passkey prompt, ignores it until it times out and closes the tab. That was a login attempt. Whether your metric knows about it depends on where the events fire.

If the attempt event fires on a page load, the tag learned nothing about the prompt and nothing about the timeout, so the success rate does not move. If somebody wrapped the navigator.credentials call and sent an event on the rejection, the failure shows up. Check which of the two you have before you accept the gap as unavoidable. And note how long this can take: the specification recommends a timeout of five to ten minutes, production deployments often set three, so a prompt can sit unanswered for minutes before anything counts as a failure at all.

The third case is easier to see as a fraction:

A fourth trap has nothing to do with passkeys. One team we work with found their analytics counted a user as successfully logged in even when that user dropped out mid-journey, because the success event fired on a page load before the journey was complete. The aggregate looked healthy. The funnel underneath it was not.

None of these is a reporting bug. Each one is a gap in what gets collected. No report can warn you about data it never received. The same pattern shows up in tracking logins with Google Analytics 4, a different tool with the same blind spot.

5. What it takes to instrument all of this in Adobe#

All of it is possible. It is just not a configuration task. The table below is what the work actually consists of.

Step 5 is where the conversation usually stops in enterprise environments. Adobe Analytics is licensed by server call volume, so tracking every step of a login is a budget question rather than a sprint ticket.

Step 6 is where it stops in engineering. Nobody ever finishes this project. It turns into a component the team has to maintain.

6. Which Login Question belongs in which Tool#

The question is not which tool replaces which. It is which tool owns which question. Adobe itself documents specialised tools running alongside Adobe Analytics, including its own Customer Journey Analytics use-case documentation for third-party session replay data. More than one analytics layer is Adobe's documented practice, not a workaround.

Corbado Observe sits in the second column. It does not replace Adobe Analytics, it does not replace your identity provider and it has no interest in your page-level tracking. It instruments the authentication ceremony and reports what happened inside it, the ground covered in authentication observability.

7. Five Checks if you already run Adobe Analytics#

A passkey rollout is not the trigger for this. The gap is client-side rather than passkey-specific and it applies to your SMS, OTP and MFA flows today.

1. Check whether a login event exists at all. If your login reporting is built on a sequential segment over a login-status variable, the logins are inferred rather than measured.
2. Check your denominator. Find out what the implementation counts as a login attempt and when the event fires. An event on a page load measures an outcome, not an attempt.
3. Check your success definition. Confirm whether a user who drops out mid-journey still counts as logged in. This is the most common definitional problem we see.
4. Check whether your login data sits in one report suite. If web and app are separate, no calculated metric will give you one number.
5. Reconcile your analytics numbers with your identity provider's. Attempts the page recorded that never reached the identity provider failed in between. That is a list you can act on. Attempts that appear in neither system were never observable from the page. That class only surfaces once something instruments the ceremony.

8. How Corbado can help#

The four failure types above have one thing in common: they happen inside the browser's own authentication interface, where a page tag has nothing to observe. Corbado Observe is the authentication observability layer that instruments the ceremony. It is a client-side integration next to the login you already run, it works with any identity provider and it sends UUID-only telemetry with no PII, so it sits next to Adobe Analytics instead of replacing it.

• The ceremony as a measured step: every navigator.credentials call with its timing, its outcome and the client capabilities that preceded it, reconstructed as a funnel instead of inferred from page loads.
• Failures separated by what they mean: the identical NotAllowedError that reaches every tool gets split by how long the call ran, by whether the client could offer a passkey at all and by what the user did next, so an error spike after an OS update reads as a pattern instead of noise in a support queue.
• Conditional UI leaves a trace after all: a passkey offered in the autofill dropdown and never touched produces no DOM event, no click, no navigation. It does produce a step with a completion rate in the subflow view.
• One user, end to end: when a ticket says "I cannot log in", replay that exact session with events, errors and device context instead of asking the user to reproduce it.
• Every method, not just the new one: password, SMS and email OTP, social login and step-up MFA run through the same funnel, so the flows you have in production today are readable before any passkey ships.

Adobe keeps the questions in the top half of that table. Observe answers the ones underneath.

9. Conclusion: instrument the Ceremony, not the Page#

Adobe Analytics answers a narrower question than its reports suggest: of the login attempts the page could observe, how many produced a success the page could observe. Everything that fails inside the browser's own authentication interface falls outside that sentence.

That is no reason to remove Adobe. It is a reason to stop expecting it to explain client-side authentication and to measure the ceremony where it happens. For the metric definitions first, start with authentication drop-off rate and the authentication analytics playbook.

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#

Can Adobe Analytics track login errors and authentication failures?#

Adobe Analytics can track any error you explicitly send it through a custom link call or a Web SDK event. It cannot track errors that never surface as a page event, which includes most WebAuthn failures, cancelled biometric prompts and passkey autofill offers the user ignored. Adobe also documents that custom links are never tracked automatically, so every one of these signals has to be instrumented by hand before it can appear in a report.

Why does my login success rate in Adobe Analytics look too high?#

Usually because failed attempts never fired an event. If your attempt event fires on a page load instead of around the authentication call, a user who cancels a biometric prompt or lets a passkey ceremony time out is missing from the numerator and from the denominator, so the rate does not move while the funnel underneath it gets worse. The second common cause is a success event that fires on a page load before the login journey is actually complete, which counts users as logged in even though they dropped out mid-flow.

Why do I need two dashboards to calculate login success rate in Adobe Analytics?#

Because Adobe cannot combine data from multiple report suites in a table, segment or calculated metric. If web logins and app logins are instrumented in separate report suites, Analysis Workspace can show both suites side by side in one project but cannot divide one by the other, so the final division has to happen outside Adobe.

Can Customer Journey Analytics analyse login and registration drop-off?#

Yes, if the events exist in the dataset. Customer Journey Analytics supports person-level analysis when stitching is configured, with documented limits such as single-level rekeying only, one namespace per ID field and stitching stopping for a shared device above 50,000 user switches. The constraint is rarely the query. It is that the authentication events were never captured.

Does session replay solve client-side authentication blind spots?#

No. The reason is structural rather than a question of quality. 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, which is why session replay cannot answer whether a passkey was offered and ignored.