Read left to right: the sessions and flows stay separate. Only the successful phone login establishes an authenticated user reference.
1. What each reference means
A session can contain several flows, and a flow can contain several method attempts. Switching from passkey to password can remain within one login flow. The Observe session ID is a tracking reference, separate from your application’s authenticated session and from your user ID.
Your user ID and the submitted identifier can be different values. For example, your database may use a UUID while customers enter an email. Both values can be stored in clear text or as pseudonymized hashes, chosen per project according to your data policy: the user ID your integration sends, the identifier entered by the user, or both. Hashing changes only the representation. It does not verify who submitted a value, and a hashed identifier and a hashed user ID are linked in the same way as clear ones.
A flow or attempt count is not a count of distinct people. One person can produce several flows, and several people can try the same account identifier. Interpret counts using the entity and filters of the view you are reading.
2. From a submission to a user link
Observe records identifiers on individual submissions of the provide-identifier step. A typo followed by a correction remains two observations. Rejected submissions remain searchable, but do not establish a user link. When your authentication system identifies a user, user enrichment attaches its reference to the flow. Connecting a submitted identifier to that user requires evidence that the authentication actually verified the identifier-to-user relationship. Only a submission supported by qualifying evidence contributes to the identifier-to-user link. Earlier typos and unrelated identifiers remain observations. A user can have several identifiers, and a shared or reassigned identifier can have links to more than one user.3. Three scenarios, three different conclusions
Can we tell whether both devices belong to Alice?
Before the phone’s successful password retry in the timeline, both devices have submitted the same email and encountered a failed authentication attempt. Searching the email already finds both flows. The shared email does not prove that Alice used either device. One person retrying, two people using a shared account and an attacker entering someone else’s email can all produce this pattern. Distinguishing genuine failures from malicious activity requires additional security signals.Can a search for Alice find those failed attempts?
Once authentication verifies the connection betweenalice@example.com and user_42, searching that user with identifier expansion can include the failed laptop flow. The same applies when the connection was established by an earlier login. Each result explains that it matched through the linked identifier.
Search expansion makes related attempts discoverable. It does not reassign the laptop flow to Alice or turn it into authenticated activity by Alice. Earlier attempts remain reachable only when their identifiers were captured and the relevant data is still retained.
Does every identifier in a successful flow belong to its final user?
Someone enters Alice’s email, switches methods and successfully authenticates with Bob’s passkey. The flow has an authenticated user reference for Bob, while the email submission remains an observation about Alice’s identifier.
The flow records both facts: Alice's email was submitted, and Bob authenticated. Those facts do not establish that the email belongs to Bob.
4. Find and interpret an attempt
Open Debugging → User Search in the management console.1
Start with the reference you know
Search by the submitted email, phone number or username when investigating a login that failed. Search by your user ID when starting from an account in your own system. Use the identifier type and clear or hashed format configured for your project.
2
Choose whether to include related attempts
A user search returns that user’s own flows. Identifier expansion also finds attempts containing identifiers linked to that user. Review shared or historical links when interpreting the results.
3
Read the match reason, then the journey
Check whether a result matched its user reference, a submitted identifier or an expanded identifier link. Inspect the submitted values, method changes and authentication outcome before drawing conclusions about the user. A direct value match across identifier and user-ID fields also needs this context.
5. Capture coverage and missing results
- Configured capture: Autocapture identifier capture is configured explicitly for your login. Custom events supply the identifier on the provide-identifier step. Binding an input for interaction tracking does not by itself capture its value.
- Consistent representation: Ingestion and search must use the same type, normalization and hash format. A customer-specific salted hash cannot be reconstructed from an email alone. Supply the stored representation or search through an established user link.
- No submitted identifier: A failed Conditional UI attempt has no typed identifier to search. It can become reachable through a user link established by a later successful login. A prefilled identifier or deep link also needs explicit forwarding when there is no provide-identifier submission.
- Collection start: Search covers identifiers captured after the feature is enabled for your integration. Earlier raw events without an identifier cannot be backfilled from their interaction metadata.
- Retention: Results depend on the submissions and links still available under your retention configuration. A missing result does not prove that no attempt occurred.