FreeThe +45-page Authentication Analytics Whitepaper — measuring real login journeysDownload
Back to Overview

Report Login Activity in Adobe Analytics without a Login Event

Use login-status transitions to report qualifying visits in Adobe Analytics, understand the limits and add explicit login events.

Vincent Delitz
Vincent Delitz

Created: August 13, 2026

Updated: September 10, 2026

Report Login Activity in Adobe Analytics without a Login Event
Key Facts
  • Missing login instrumentation is a legacy-data problem. Add explicit events for future measurement when you can.
  • A recorded status change can identify visits with login evidence. It is not a count of authentication attempts.
  • Occurrences counts hits, not login transitions. A sequential segment can contain several hits for one login.
  • Label the proxy clearly. Use “Visits with an observed login-state transition” rather than “Logins”.

1. What you can report when a login event is missing#

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:

  1. Which existing data can indicate that a login happened?
  2. How can you report qualifying visits without overstating the result?
  3. When do you need explicit events or hit-level reconstruction?
WhitepaperAuthenticationAnalytics Icon

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

Get Whitepaper

2. Check whether the historical data supports a proxy#

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.

CheckWhy it matters
Both states are recordedA logged-in value alone may describe an existing session
Values describe current statePersisted or stale values can suggest a transition that was never recorded
States share a suitable visit or identity scopeDifferent identities cannot simply be read as one person's sequence
Tracking coverage is understoodMissing hits can hide transitions

If these conditions do not hold, explain the data gap. A more complicated segment does not restore missing evidence.

3. Report visits with an observed login-state transition#

3.1 Build a sequential segment#

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.

3.2 Use Visits and name the result precisely#

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.

3.3 Why Occurrences is not a login counter#

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.

4. Decide whether you need hit-level reconstruction#

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.

5. Add explicit events for future measurement#

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.

6. When additional authentication context helps#

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

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 I report logins in Adobe Analytics without a login event?#

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.

Should I use Only Before Sequence with Occurrences?#

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.

Can I calculate authentication success rate from login-state transitions?#

No. Successful state changes do not provide the full population of attempts, including failures and unfinished journeys.

How should I report unique users with login evidence?#

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.

See what's really happening in your passkey rollout.

Book a Demo

Share this article


LinkedInTwitterFacebook