Count Logins in Adobe Analytics without a Login Event

1. Counting Logins in Adobe Analytics when nobody instrumented one#

Somebody asks how many logins you had yesterday, last month and over the last 30 days. You open your Adobe Analytics report suite and there is no login event to report on. What you do have is a page name, a URL and a variable that records whether the visitor was logged in when each hit was sent, usually an eVar, Adobe's name for a dimension whose value can carry over from one hit to the next.

That is enough to work with. The question comes up often enough in the Adobe Experience League community that it has a settled answer. The thread with the accepted solution is the one this article follows: rebuild the login from the status variable using a sequential segment. It works. The number it produces still has to be read carefully once it lands in a board deck.

1.1 What this article covers#

Section 3 builds the segment, click by click. Sections 4 to 6 are about reading the result: what it counts, what it misses and when to stop inferring and build a real login event instead. Section 7 says where that event belongs once you do.

2. Why the Login Event is missing#

Almost nobody decides against a login event. It goes missing for structural reasons.

• Login moved into a modal. No navigation, no page view, so a page-based implementation never sees it.
• Authentication sits with a different team. The identity provider owns the flow, analytics owns the page and nobody owns the seam between them.
• Login lives on a different domain. A redirect to an identity provider hosted on another host leaves the analytics implementation behind.
• The implementation predates the requirement. Login status was added for personalization or for segmentation, never for counting.

The result is the same in each case. You have a state, not an event.

3. Infer the Login from a Logged-In Status Change#

Even when nobody tracked the login itself, the change of state is still visible in the data. A hit where the user is logged out, followed by a hit where the same user is logged in, has a login somewhere in between. That is what the segment below looks for.

3.1 Prerequisites#

You need a variable that carries the logged-in state on every hit, usually an eVar or a prop set to yes or no. If it is only set on some pages, everything below turns into noise. Check the coverage first: an Occurrences report broken down by page shows you where the variable is missing.

3.2 Build the sequential Segment with the Then Operator#

In the segment builder, use a Visit container with a Hit level sequence and the Then operator, which Adobe documents as "one segment condition occurs, followed by another":

In the builder the two checkpoints sit above and below the Then row and the timing constraint hangs off that row, set to hits, not to the weeks shown here:

The Then operator between two checkpoints. Source: Adobe Analytics documentation (MIT licence).

Set the container to Only Before Sequence. Adobe defines that option as including "all data before a sequence and the first data of the sequence itself".

That last setting does two things. It stops the segment from returning the whole logged-in remainder of the visit, which is the reason it appears in the accepted community answer at all. It also means the hits you get back are not the login itself, so the result approximates a login count instead of defining one.

Jennifer Dungan, the Adobe Champion who published this structure, said the same in that thread. She compared it against a real login event on her own site and got close numbers, not identical ones. Do that comparison yourself before the figure goes into a report: against a login event in a neighbouring report suite, against an export from your identity provider or against a single day you can count by hand.

3.3 Report the Segment with the Occurrences Metric#

Run the segment with the Occurrences metric. Adobe defines it as the number of hits where a given dimension was set or persisted and it counts page views, link tracking hits and data source imports alike.

Page Views is the wrong choice here. If any step of your flow reports through s.tl() instead of a page view, that step disappears from the number without a warning. Tracking login success rate in Adobe Analytics describes the same mistake.

3.4 Daily, monthly and rolling 30 Days#

Once the segment exists, the time dimensions handle the rest. Put the segment on a Workspace panel, add Occurrences as the metric and use a Day, Month or rolling date range. A rolling 30-day view is a date range component, not a second segment.

For unique logins, apply the same segment with Unique Visitors. Read section 5 before anyone treats that as a count of people.

4. What an inferred Login Count includes and leaves out#

The number is a reconstruction, built from a variable that describes the page. That is a useful thing to have and it is not the same as measuring an authentication.

Three things come with the method:

1. It counts successes only. The state change is the proof. A user who tries four times and gets in on the fifth produces one match, exactly like a user who got in immediately.
2. It depends on variable coverage. A page in the flow that does not set the login status can hide a transition or invent one. eVar persistence makes that worse, because a persisting value can carry yes into a later visit where nothing was ever set.
3. It is bounded by the visit. A session that starts logged in, because a cookie survived, has no no hit to open the sequence. Those logins are not in the number at all.

5. Define "unique" before anyone reports the Number#

Unique Visitors on this segment counts browsers, not accounts. One person on a laptop, a phone and a work machine counts three times. A tablet shared by a family counts once. Adobe cannot tell the difference unless your implementation sets a hashed customer ID and you report on that instead.

Outside the analytics team, "unique logins" reads like "users". Write the definition next to the number in the dashboard. One line stops the figure being compared against an account count from the identity provider, which measures something else entirely.

6. Three Signals that it is Time to instrument the Event#

Build the workaround, then stop defending it once one of these shows up:

• Somebody asks for a success rate. There is none to build. A failed login changes no state, so the failures are simply not in the data and there is nothing to divide by. Successes per visit is all that remains and that measures reach, not success.
• Somebody asks why logins dropped. The segment can tell you that fewer people got through. The reason sits in the part of the flow the page never saw.
• Login spans web and native app. If the two live in separate report suites, Adobe is explicit that data from multiple report suites "cannot be combined in tables, segments or calculated metrics (summed, divided, etc)".

The fix at that point is an attempt event and a success event firing through link tracking. It takes an afternoon and track login success rate in Adobe Analytics has it step by step.

7. Why a Login Event on a Page Load has the same Blind Spot#

Before you plan the implementation, one thing is worth knowing, because it decides where the event belongs.

An attempt event that fires on a page load inherits the blind spot of the inferred number. It needs a page to load and a lot of logins never load one:

• Password login in a single-page app. The form posts in the background, the wrong password comes back as a JSON response and the same view re-renders with an error message. No navigation, no page view, no attempt in the data.
• A one-time code typed into a modal. The code, the retry and the expiry all happen inside the same overlay, on the same URL.
• A redirect to an identity provider. If the password is rejected on the provider's own domain, that hit belongs to their report suite, not to yours. All you see is a visitor who left and came back.
• A passkey ceremony. A Face ID prompt the user dismisses, a login that runs out of time, a call cancelled because the window lost focus, a passkey offered in the autofill dropdown and ignored. The browser draws all of it outside your page.

So fire the attempt event where the attempt actually happens: in the submit handler for a password or a code and around the navigator.credentials call for a passkey. Then the attempt is counted and every failure that comes back as an error is counted with it. Only the ignored autofill offer stays outside, because it never produces an error to catch. Leave the event on the page load instead and the success rate keeps looking fine while the funnel underneath it does not. Why Adobe Analytics cannot debug login failures has the full list.

8. How Corbado can help#

You only need an inferred login count because nobody ever instrumented the login as an event. Corbado Observe is the authentication observability layer that does instrument it, including the parts that never reach a page tag. It runs client-side next to the login you already have, works with any identity provider and sends UUID-only telemetry with no PII, so it answers the authentication questions while Adobe keeps the page-level ones.

• Attempts, not just arrivals: every authentication is counted where it starts, so a failed login is a data point instead of an absence, with the funnel showing where it stopped.
• No segment to maintain: logins arrive as events with method, device, browser and outcome attached, so both the reconstruction and the eVar coverage problem disappear.
• Methods side by side: password, OTP and passkey compared directly, which an inferred count cannot do because the state change looks identical for all three.
• One user, end to end: when support gets "I cannot log in", replay that session with events, errors and device context instead of asking the user to reproduce it.
• No rollout required first: the flows you run today, password, SMS and email OTP, social login and step-up MFA, are the ones it reads on day one, so the inferred count can be retired without waiting for a passkey project.

Adobe keeps reporting on the pages around the login. Observe reports on the login.

9. Conclusion: a good Workaround with a known Ceiling#

The sequential segment is the right answer to the question as asked. Build it, use Occurrences, set Only Before Sequence and write the definition of "unique" next to the number.

Then be clear about the ceiling. It counts successes, it depends on a variable that was never meant to count anything and it cannot say why a login did not happen. Once that becomes the question, a smarter segment will not help. An event fired around the authentication call will. The authentication analytics playbook has the wider metric set and login success rate has the definition to agree on first.

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#

How do I report on logins in Adobe Analytics without a login event?#

Build a hit-level sequential segment inside a Visit container that matches a hit where the logged-in status is no, followed after one hit by a hit where the status is yes, with a second condition requiring the status to be yes. Set the container to Only Before Sequence and report it with the Occurrences metric. It infers a login from the state change instead of measuring an authentication, so it counts successes only and it approximates the count rather than defining it. Validate it against a number you already trust before anyone reports it.

Why does the segment need Only Before Sequence?#

Adobe documents Only Before Sequence as including all data before a sequence and the first data of the sequence itself. Without it the segment returns the whole logged-in tail of the visit, which inflates any hit-based metric built on top of it. With it the returned hits are still not the login hit itself, so the result stays an approximation and never becomes a definition.

Which metric should I use with a login segment?#

Occurrences. Adobe defines it as the number of hits where a given dimension was set or persisted, counting page views, link tracking hits and data source imports alike. Page Views would miss any login that happens through a link tracking call. Visits would answer a different question.

Can an inferred login number show failed logins?#

No. A failed login produces no state change, so it produces nothing for the segment to match. The only rate you can build on an inferred login count is successes over visits, which is a reach metric, not a success rate. Login success rate needs an attempt event that fires before the outcome is known.

How do I count unique logins in Adobe Analytics?#

Decide what unique means before you build anything. Unique Visitors on the segment counts people who logged in at least once in the period, keyed on the analytics identity instead of the account. A user on three devices counts three times and a shared device counts once, so the number answers a device question instead of an account question unless your implementation sets a hashed customer ID.