Users

Every identified and anonymous end user seen in an environment, traced back to their sessions.

Agent > Users lists every end user arcy.js has seen in the selected environment, whether identified with identify() or anonymous. It's a diagnostic view: confirming identify() is actually reaching ARCY, and looking up one specific user's attributes and sessions.

The list

Each row shows:

User: the name if one arrived, otherwise the raw userId, with an Anonymous badge for a visitor who never identified. The email sits under the name when the user_email attribute has arrived, and the raw userId sits there when it hasn't.
Last seen: relative time, or "Never".
Sessions: total session count.
Origin(s): which verified origins this user's sessions have come from.

Switch between Live and Test key tiers with the tabs above the table. The list is scoped to whichever environment you have selected.

Searching, sorting and paging

Search with the box next to the tier tabs. It matches the user id, the name, and the email, so you can paste in whichever one you have.
Sort by clicking User, Last seen or Sessions. Clicking again reverses the order, and a third click returns to the default of most recently seen first.
Page with the controls under the table. It says which rows of how many you are looking at, and you can show 10, 25, 50 or 100 rows at a time.

Search, sort and paging all run on the server, so they cover every matching user rather than only the rows currently on screen. Any change that narrows or reorders the list returns you to page 1.

Where the name and email come from

Both are ordinary attributes you send with identify():

arcy.identify("user_123", {
  user_first_name: "Ada",
  user_last_name: "Lovelace",
  user_email: "ada@example.com",
})

The name is two attributes, not one. A full name in a single field can be printed and nothing else, so a greeting that says "Hi Ada" would be impossible to write. Send one half or both: the list joins whatever arrives.

Send none of them and ARCY has nothing to show but the userId, which is why an install that has not sent them reads as a page of opaque ids. See Attributes for the full built-in list.

Filtering by attribute

Narrow the list with the filter builder, built from the attributes declared under Attributes. Filters combine with the search box.

If the list is empty with no filters active, nobody has identified yet: "Once identify() fires from your app, end users will show up here." With filters active and no matches, the empty state prompts you to remove one to widen the search.

The detail page

Click a row to open that user's own page. Identity and attributes sit side by side in one row, with the sessions table underneath. It shows:

The header: name, email, the organization they belong to (linking to its own page), the raw user id, first seen, last seen, and how many sessions the selected key tier holds.
Attributes: everything identify() has sent for this user, labelled with the display name from your attribute registry and formatted by its data type. Hover a label to see the code name you would use in Liquid or a flow condition. Name, email and organization id are not repeated here: they are already in the header.
Sessions: the origin, the entry route (the page the session started on, with identifiers scrubbed, so /orders/12345 reads as /orders/:id), when it started, and the identity-verification outcome. Every column sorts, and the table pages ten rows at a time.

The Live/Test switch above the session table applies to the whole page, which is why the sessions themselves carry no key tier column.

There's no conversation-history view on this page; attributes and sessions are what's shown.