Track Login and Form Errors in Adobe Analytics

A useful error report tells you what failed and where to investigate. Start with the errors your application already exposes: an invalid input, an unavailable identity service or a rejected authentication request. Send the event and its context to Adobe, then verify the report against a known test case.

The harder question is whether the report explains the whole login. A rejected password, an unanswered OTP challenge and a failed passkey request leave different evidence. Some produce explicit errors. Others leave an unfinished sequence or an outcome with an uncertain cause.

This guide answers five questions:

1. Which Adobe events and dimensions should you configure?
2. How do you send an error without generating a page view?
3. How do you validate the data and keep reports readable?
4. What can you conclude from incomplete login journeys?
5. When does adding Corbado Observe help?

Authentication Analytics Whitepaper. Practical guidance, rollout patterns and KPIs for passkey programs.

Get Whitepaper

A hit is a transmission of analytics data. With AppMeasurement, s.t() sends a page-view hit and s.tl() sends a link-tracking hit. A custom link can represent a caught login error even when no link was clicked. With the Web SDK, use sendEvent and the appropriate Analytics mapping instead.

Adobe documents custom link tracking separately from automatic download and exit-link tracking. Define the login signals explicitly; installing page tracking does not define them for you.

Adobe calls a custom metric a success event, even when it counts errors. Choose its type according to the value you need to record.

A calculated metric combines metrics already collected, such as errors divided by submissions. It does not require another tracking hit.

A dimension describes the event. In an error report, it might identify the error code or the flow step. Custom values can be sent through eVars or props.

For the examples below, use Hit expiration for the error dimensions and send them on each error hit. This keeps an earlier error from receiving credit for later events.

A report suite is the reporting destination. Confirm the correct suite before configuring or testing events. A high-cardinality dimension has many distinct values, often because raw messages contain timestamps or request identifiers. Keep codes predictable; section 7 shows why.

Adobe's Low-Traffic bucket groups dimension values when cardinality limits are reached. The documented default is two million unique values per dimension, report suite and calendar month, with configuration options and exceptions. It is not a simple rule that every value after the threshold disappears. Stable codes reduce the problem before you reach that limit.

Choose categories your team can act on without claiming more than the evidence supports.

Only label an outcome as a user cancellation when a reliable signal supports that conclusion. An ambiguous error or missing OTP submission is not enough.

In Admin → Report Suites, select your test suite. Open Edit Settings → Conversion → Success Events, choose an unused event and give it a clear name such as Login Error. Set its type to Counter and save. The examples use event10; replace it if that slot already has another purpose.

Source: Adobe's Success Events documentation. This is Adobe's example screen, not a Corbado test account. © Adobe; MIT license.

Open Edit Settings → Conversion → Conversion Variables. Assign unused eVars to the fields below. Set expiration to Hit, use Most Recent allocation and save. Document the mapping so the application and analytics teams use the same slots.

Source: Adobe's eVar documentation. The screenshot shows example variables; use the error fields defined above. © Adobe; MIT license.

Use one collection approach per event. These examples assume an already configured Adobe library, the correct report suite and your site's consent rules. Do not place credentials, tokens or raw user input into analytics fields.

function reportLoginError() {
    try {
        s.tl(true, "o", "Login Error", {
            events: "event10",
            eVar20: "idp_unavailable",
            eVar21: "system",
            eVar22: "password_submit",
            linkTrackVars: "events,eVar20,eVar21,eVar22",
            linkTrackEvents: "event10",
        });
    } catch {
        // A telemetry problem must not interrupt the login or recovery UI.
    }
}

The fourth argument supplies overrides for this call. The event must be in events; the variable filter must include events and the eVars; the event filter must include event10. See Adobe's link-tracking reference. Do not duplicate this hit in a tag-manager rule.

function reportLoginError() {
    try {
        void Promise.resolve(
            alloy("sendEvent", {
                data: {
                    __adobe: {
                        analytics: {
                            linkName: "Login Error",
                            linkType: "o",
                            linkURL: "https://example.com/login",
                            events: "event10",
                            eVar20: "idp_unavailable",
                            eVar21: "system",
                            eVar22: "password_submit",
                        },
                    },
                },
            }),
        ).catch(() => {});
    } catch {
        // Keep telemetry failure separate from authentication failure.
    }
}

Replace the example URL with your approved, query-free login URL. The configured datastream must have the Adobe Analytics service enabled and point to your report suite. This example uses the direct Analytics data mapping; it does not also send the same fields through XDM.

Trigger a controlled failure in your test environment. Inspect the outgoing payload with browser developer tools or Adobe's debugger. Confirm the event number, error code, class and flow step. Then check the intended report suite after processing.

Repeat the check with a successful login and verify that it does not carry the earlier error. Test retries too: one failed submission should not generate a hit from both application code and Adobe Tags.

Define a form start at a meaningful interaction and a completion at the intended successful outcome. Count each once per form journey. For an authentication flow, successful browser credential retrieval is only an intermediate step; backend verification and the intended authenticated state must follow.

Subtracting completions from starts is meaningful only when both refer to the same population and observation window. Handle retries, duplicate events and journeys still in progress before labelling the remainder as abandonment. A separate abandonment hit is optional for that calculation and can be lost when a page closes.

For field-level diagnostics, record approved field names or step labels, never their entered values. Keep unanswered OTP challenges separate from explicit errors.

Use idp_unavailable or otp_expired rather than the full error message. Embedding a timestamp or request ID creates another dimension item for every occurrence and makes grouping harder.

Maintain a small mapping from code to description and owner. Adobe classifications can add readable labels to collected codes. Do not send personal information merely to make the report easier to read.

A submission can fail validation on several fields. Decide whether the metric counts affected fields, rejected submissions or failed journeys. If using an Adobe list variable for multiple codes, verify how credit is allocated; adding breakdown rows does not necessarily produce a unique journey count.

For passkeys, capture the application-visible lifecycle of the WebAuthn request. A resolved request returns a credential for verification. A rejected request exposes an error. Both can be sent to Adobe even when nothing changes on the page.

Illustrative event sequence. The added track shows instrumented application events, not a recording of browser or phone interfaces.

Keep NotAllowedError as the observed result. Use duration, device context and subsequent actions to investigate possible explanations. A short duration alone does not prove a bug or a cancellation. Browser capability checks also do not prove that a passkey suggestion appeared.

The WebAuthn specification limits what an application can learn about some unsuccessful requests. That boundary applies to every analytics and observability vendor.

An implementation may record enrollment interactions in the browser but login outcomes on the server. Compare the definitions and available correlation keys before combining the streams. Two complete datasets can still describe different stages or populations.

For OTP, keep request, resend, submission and verification separate. A missing submission is an incomplete journey; delivery failure requires additional evidence. For automatic passkey prompts, distinguish prompt initiation from demonstrated login intent. Web and native platforms may expose different signals.

Reproduce a failure, verify collection and compare the frontend record with the backend result where correlation is available. Check consent, blocked requests, duplicate instrumentation and reporting windows. Do not attribute every discrepancy to authentication friction.

For the denominator and retry rules, see login success rate in Adobe Analytics.

Your team can build custom login reporting in Adobe. It then owns the event definitions, mapping, journey model and ongoing validation. Corbado Observe provides a dedicated workflow for investigating authentication alongside your existing login stack.

Some customers keep Adobe Analytics as their foundation and add Observe for detailed authentication analysis. Evaluate the additional value against a real question: which users fall back, where OTP journeys stall or which browser segment changed after an update.

Observe connects available events into journeys, supports method and device breakdowns and provides event histories for support investigations. That history is telemetry, not a video of the browser's biometric interface. Ambiguous causes still need evidence; a specialised view does not remove platform limits.

Explore Corbado Observe or discuss your login measurement with us.

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 →

Yes. Use an AppMeasurement custom link hit or a mapped Web SDK event. Send the configured error metric and dimensions, then verify the payload and report suite.

Use stable codes instead. Raw messages may contain personal data or unique identifiers and can fragment the report into many distinct values. Keep readable descriptions in a controlled lookup.

Yes. Your application can capture an exposed WebAuthn error and send it to Adobe. The error may not identify the exact cause, and events that were never collected cannot be reconstructed by a report.

No. It means no submission was recorded within the chosen observation window. Delivery failure, delay and user abandonment are different possible explanations.

Observe can run alongside Adobe Analytics and your existing identity provider. It adds a dedicated authentication journey view; assess its collection coverage and diagnostic workflow against your current implementation.