Track Login Success Rate in Adobe Analytics

Adobe Analytics can calculate a login success rate from two custom events. The important work is deciding when those events fire and checking that successes and failures enter the same measurement.

This guide answers four questions:

1. What counts as an attempt and a completed login?
2. How should you send the events without a page view?
3. How do you build and validate the rate in Analysis Workspace?
4. Which collection gaps can make the result misleading?

For definitions of events, link calls and dimensions, start with the Adobe login error tracking guide.

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

Get Whitepaper

For the method-level example below, count a user-initiated authentication attempt before its outcome is known. A retry is another attempt. A login page impression belongs in a separate metric.

Automatically starting a passkey request on page load or app launch does not necessarily establish intent. Track initiation separately and document which observable action qualifies as engagement. Conditional UI and native prompts expose different signals; do not assume the same rule works everywhere.

Count success after backend verification and the authenticated state your product requires. Receiving a credential from navigator.credentials.get() is an intermediate result. A successful first factor is also intermediate if MFA is still required.

Keep method-level and journey-level rates separate. If a user tries a passkey, falls back to a password and gets in, the passkey attempt failed while the overall journey succeeded. Define the journey start, end and retry window before comparing the two.

In Admin → Report Suites, choose your test suite and open Edit Settings → Conversion → Success Events. Create three unused Counter events. These numbers are examples; do not overwrite existing mappings.

Source: Adobe's configuration example. Use the login names above in your own suite. © Adobe; MIT license.

Configure eVar10 for Login Method and eVar11 for Entry Point. In this example both use Hit expiration, and both are sent on every attempt and outcome. This avoids attributing a later password success to an earlier passkey attempt. Use an approved error-code dimension such as eVar20 for failures.

Do not use once-per-visit event recording for a per-attempt rate: one visit can contain several attempts. Prevent duplicate emission in the application or use a deliberately designed event-serialization scheme.

Use an already configured AppMeasurement instance and follow your site's consent rules. Per-call overrides keep this example from leaving event values on the shared instance.

function trackLogin(event, method, entryPoint, errorCode) {
    const names = {
        event1: "Login Attempt",
        event2: "Login Success",
        event3: "Login Failure",
    };
    if (!names[event]) return;
    try {
        s.tl(true, "o", names[event], {
            events: event,
            eVar10: method,
            eVar11: entryPoint,
            eVar20: errorCode || "none",
            linkTrackVars: "events,eVar10,eVar11,eVar20",
            linkTrackEvents: event,
        });
    } catch {
        // Analytics must not interrupt authentication.
    }
}

Adobe's s.tl() reference documents the custom link type and variable overrides. If your implementation assigns values directly to s instead, manage their lifecycle explicitly; clearVars() clears event and dimension values but not every configuration property.

The alternative below uses the Web SDK's direct Analytics mapping. The configured datastream must enable Adobe Analytics and select the intended report suite. Replace the example URL with an approved URL without query parameters.

function trackLogin(event, method, entryPoint, errorCode) {
    const names = {
        event1: "Login Attempt",
        event2: "Login Success",
        event3: "Login Failure",
    };
    if (!names[event]) return;
    try {
        void Promise.resolve(
            alloy("sendEvent", {
                data: {
                    __adobe: {
                        analytics: {
                            linkName: names[event],
                            linkType: "o",
                            linkURL: "https://example.com/login",
                            events: event,
                            eVar10: method,
                            eVar11: entryPoint,
                            eVar20: errorCode || "none",
                        },
                    },
                },
            }),
        ).catch(() => {});
    } catch {
        // Analytics must not interrupt authentication.
    }
}

Choose one sender, rather than firing both examples. If Adobe Tags owns collection, the application can announce a semantic event through a Direct Call Rule and let the rule map the fields. Keep a single owner for each tracking hit.

This example covers an explicitly initiated passkey attempt. finishAuthentication is an application-provided adapter: it must serialize the assertion using your authentication library, send it to your backend and resolve only after verification and session creation. It must reject on failure. It is not an Adobe API or a replacement for a WebAuthn server library.

async function loginWithPasskey(publicKeyOptions, finishAuthentication) {
    // publicKeyOptions is already decoded by your authentication library.
    trackLogin("event1", "passkey", "checkout");
    let credential;
    try {
        credential = await navigator.credentials.get({
            publicKey: publicKeyOptions,
        });
        if (!credential) throw new Error("credential_missing");
    } catch (error) {
        const name = error instanceof Error ? error.name : "UnknownError";
        const allowed = ["NotAllowedError", "AbortError", "SecurityError"];
        const code = allowed.includes(name) ? name : "client_authentication_error";
        trackLogin("event3", "passkey", "checkout", code);
        throw error;
    }
 
    let session;
    try {
        session = await finishAuthentication(credential);
    } catch (error) {
        trackLogin("event3", "passkey", "checkout", "verification_or_session_failed");
        throw error;
    }
 
    trackLogin("event2", "passkey", "checkout");
    return session;
}

A request still pending when the page closes may have no terminal event. Keep such attempts in the defined population and treat them according to your observation window. Telemetry delivery is best-effort; compare collection health before interpreting discrepancies as product failures.

Create a calculated metric with Login Success divided by Login Attempt. Set the format to Percent and choose the required decimal precision.

Login Success Rate = event2 / event1

The calculated metric builder. Source: Adobe Analytics documentation (MIT licence).

Adobe's example uses different metrics. Apply the same division structure to Login Success and Login Attempt.

Break down both components by Login Method or Entry Point. Check that the same labels are sent at both ends. Display attempts beside the percentage so a small sample does not look like a reliable trend.

For journey-level reporting, count a completed journey once and use journey starts as the denominator. Do not divide journey successes by method attempts.

If failed attempts are never recorded, the denominator is incomplete. If success fires when the browser returns a credential, backend rejections can enter the numerator. Test both paths.

Illustrative numbers: 80 successes among 100 recorded attempts gives 80%. If 20 additional unsuccessful attempts were omitted, the complete rate would be 80/120, or 66.7%.

If your attempt event already fired on page load, that visit is not absent from the denominator. The problem is then a different definition: page conversion rather than method-attempt success.

Separate automatic initiation from observable engagement. Do not interpret capability detection as proof that a suggestion was shown. Keep retries and fallback in the journey so a failed method can coexist with a completed login.

Timing and environment can help investigate NotAllowedError, but no universal duration threshold proves whether a user cancelled or a credential was unavailable. Preserve unknown causes.

Enrollment may be measured on the frontend while authentication outcomes arrive from the backend. Verify correlation, population and success definitions before combining them. Native app and web APIs also expose different signals.

Standard Analysis Workspace does not combine different report suites into one calculated metric. Use a suitable consolidated collection design or an appropriate joined dataset; Customer Journey Analytics is a separate option to evaluate. Putting two suites next to each other does not reconcile their definitions.

Compare first-time devices, returning devices and fallback paths separately where you have reliable dimensions. A high rate for returning users does not establish that new-device login works well.

To evaluate a rollout, inspect whole-journey completion and duration alongside method success. Cohort differences alone do not prove the new method caused an improvement; use an appropriate experiment or account for selection effects.

A status transition can identify visits with evidence of a login, but it cannot supply a missing attempt denominator. Do not use Occurrences from a sequential segment as a count of logins: it counts matching hits.

The guide to reporting without a login event explains a clearly labelled visit-level proxy and its limits.

Run a successful login, a browser-side failure, a backend rejection and a retry in a test environment. Each attempt should produce one start and no more than one final outcome. A passkey failure followed by password success should remain distinguishable from passkey success.

Check payloads, the report suite, processing delay and date boundaries. Investigate duplicates or dropped telemetry before explaining a change in the rate. Compare results with backend records where consistent correlation is available.

An Adobe implementation can answer these questions with appropriate data. The ongoing work is maintaining a consistent journey model across methods and platforms.

Some customers keep Adobe Analytics and add Corbado Observe for authentication diagnosis: method breakdowns, fallback paths and event histories for affected users. Observe sends pseudonymous telemetry alongside the existing login stack. It helps investigate ambiguous outcomes with context; it cannot read information the platform withholds.

Explore Observe with a real failure or reporting discrepancy from your team.

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 →

Create events for attempts and successes, then divide successes by attempts in a calculated metric formatted as Percent. Use the same unit, population and reporting window for both.

After the backend verifies the assertion and establishes the intended authenticated session. The browser returning a credential is an intermediate result.

Yes. Use AppMeasurement custom link tracking or the Web SDK with an explicit Analytics mapping. Configure the event in the destination report suite and verify its delivery.

Not reliably from successful-login evidence alone. Status transitions can identify qualifying visits, but they do not measure all attempts or failed journeys.

Document that decision separately from user-initiated attempts. Prompt initiation does not necessarily establish intent, and web and native platforms may provide different evidence of engagement.