You may need a historical report from an implementation that never tracked login completion. Or the authentication team may need a release before it can add an event. In those cases, existing login-status data can provide a limited proxy.
This is not a reason to avoid implementing login events. A state change cannot recover failed attempts or establish exactly when authentication completed.
This guide answers three questions:

Authentication Analytics Whitepaper. Practical guidance, rollout patterns and KPIs for passkey programs.
You need a dimension that records a meaningful logged-out state and a later logged-in state. Confirm how it was populated during the period you want to analyse.
| Check | Why it matters |
|---|---|
| Both states are recorded | A logged-in value alone may describe an existing session |
| Values describe current state | Persisted or stale values can suggest a transition that was never recorded |
| States share a suitable visit or identity scope | Different identities cannot simply be read as one person's sequence |
| Tracking coverage is understood | Missing hits can hide transitions |
If these conditions do not hold, explain the data gap. A more complicated segment does not restore missing evidence.
In the segment builder, use a Visit container with an ordered sequence: Login Status
equals no, then Login Status equals yes. Use the actual dimension and values from your
implementation. Keep the sequence within the visit and use Include Everyone for the
qualifying visit population.
The Then operator between two checkpoints. Source: Adobe Analytics documentation (MIT licence).
This Adobe example illustrates the Then operator with different conditions. Replace them with your login-status states and verify the visit scope. The screenshot is not a completed login segment.
Adobe's sequential-segment documentation explains the sequence and inclusion controls. Do not add a one-hit restriction unless your implementation actually records the transition in that pattern.
Apply the segment to Visits. Call the metric Visits with an observed login-state transition. A qualifying visit counts once even if it contains multiple logins.
For visit-level reach, divide these qualifying visits by total visits in the same reporting population. This is not authentication success rate: the denominator contains visits rather than login attempts.
For an audience view, use Unique Visitors with the same segment and explain that it reflects Adobe's visitor identity, not necessarily distinct people. Do not sum daily unique visitors to obtain monthly unique visitors.
Occurrences counts qualifying hits. Consider the observed states no → no → no → yes:
there is one transition but several hits. Changing the segment to Only Before Sequence
changes which hits are included; it does not turn those hits into transition events.
That is why a sequential segment combined with Occurrences should not be presented as the number of logins. It may look close on a particular site and still diverge when navigation or tracking changes.
If the business needs transition counts rather than qualifying visits, analyse an appropriate hit-level export. Order events using available identity and timestamp fields, define visit boundaries and handle missing values, duplicate hits and persisted state. Count documented state changes, then validate against a period with reliable authentication records.
Even that produces reconstructed transitions. A refreshed session or silent sign-in may change state without an explicit user login. Failed attempts leave no successful transition to count.
Implement an attempt event before the outcome is known and a success event after verification and the intended authenticated state. Track retries and fallback according to a documented unit: method attempts or whole journeys.
The Adobe login success-rate guide includes configuration and code examples. Use the error-tracking guide to capture rejected inputs and authentication failures.
Keep the old proxy and the new event metric distinct during the transition. A visible difference is useful evidence of changed measurement; do not rename the historical proxy to imply it used the new definition all along.
A reported logged-in state says little about how the user got there. They may have retried an OTP or abandoned a passkey attempt before using a password. Explicitly recorded method and journey events can explain those paths.
Some customers keep Adobe Analytics as their foundation and use Corbado Observe alongside it for authentication analysis. Observe provides a dedicated journey view from the telemetry it collects. It does not retroactively recover events missing from a historical Adobe dataset.
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 →
If reliable login-status data exists, you can identify visits with an observed logged-out to logged-in transition. Label this as a visit-level proxy, not an exact count of logins.
Not as a login counter. The inclusion option selects part of a matching sequence's data, while Occurrences counts qualifying hits. One login can contribute several hits.
No. Successful state changes do not provide the full population of attempts, including failures and unfinished journeys.
Apply the qualifying-visit segment to Unique Visitors for the required period. Explain the identity scope and do not treat browser visitor identifiers as a guaranteed count of people.
Related Articles
Table of Contents