Every recording is tied to your account (RECORDING_OWNER_ID) and your client app's API key — but neither of those tells you
which of your own users produced a given session. Picto.identify fills that gap: it attaches your own app's identifier for whoever is using it right now, as a real, searchable field on the dashboard.
Setting it#
Picto.identify('user_9f8a2c');
Call it as soon as you know who the user is — right after login is the common case. A session that starts before you call
identify simply uploads with no end-user id at all; a later call overwrites the earlier value, the same way
setTag does.
identify takes whatever value makes sense in your own system — a database id, a UUID, an email, anything stable and unique to that user. Picto stores it as-is; it isn't validated or looked up against anything.
How this is different from tags#
Tags are free-form key/value data nested inside a session's metadata
— great for things like an experiment variant, but not something the dashboard can efficiently filter or search on directly.
identify is a dedicated, top-level field instead: it's sent on the recording itself and
on every exception, frozen frame, and frustration event that session produces, so you can find everything tied to one user across every signal, not just the recording list.
What gets uploaded#
You don't need to do anything extra to make this show up — once you've called identify, every upload the SDK already makes (the recording itself, captured exceptions, frozen frames, rage/dead/error taps) includes it automatically:
Picto.identify('user_9f8a2c');
// ... later, when the session ends:
await Picto.endSessionAndUpload();
Privacy note#
Whatever you pass to identify is stored and shown in your dashboard as plain text. Don't pass anything you wouldn't want a teammate with dashboard access to see — an internal database id is usually a safer choice than, say, a raw email address.