Person profiles
Click a name anywhere in Usero and land on one profile: identity and traits from identify(), MRR, every piece of feedback they sent across every source, their session replays, and the merged pull requests their requests turned into.
A requester in most feedback tools is a string on a ticket. You can read what they said this time, but not what they hit last month, what else they asked for, or whether anything they wanted ever shipped.
Analytics products solved this years ago with the person page: one hub per identified user with everything they did. Feedback tools mostly did not. The context lives scattered: their bug report in the inbox, their survey answer on a form, their session replay in another list, and the fix you shipped for them recorded nowhere at all. So before replying to a request you open four tabs, and the question that should take one click, is this person a paying customer with a history of hitting this wall, takes a spreadsheet.
How it works
Disclosure: I build Usero, so weigh that. Usero already links feedback from every source (widget, surveys, board posts, app reviews) and session replays to a Person through the identify() call and email reconciliation. The profile page reads it all back in one place: identity, traits and MRR in the header, their feedback list, their replays, and a "Shipped because they asked" section listing the merged pull requests that answered their requests, using the same join that powers requester notifications on the changelog. Names on feedback detail and the sessions list are links, so the page is one click from where you meet a requester. Every link checks that its target exists before rendering, and an empty section says why it is empty in one line.
Identity, traits from identify(), MRR, first and last seen, and how many pieces of feedback they have sent from which sources. The three-second read before you reply to anyone.
The feedback list and the session replay list sit on the same page, so what they said and what they experienced stop living in separate tools.
The profile lists the merged pull requests that exist because this person asked, each paired with the request it answered. Feedback tools count what came in; this shows what went out.
A link renders only when its target exists. A person with no replays gets a one-line explanation, not a button that silently does nothing.
The honest objection
Less, honestly. Anonymous feedback has no person to hang a profile on, so profiles exist for users your app identifies or who leave an email that reconciles to a person. If most of your feedback is anonymous, the inbox and clusters stay the primary views, and profiles light up as your identified share grows. There is no synthetic stitching of anonymous visitors into people.
FAQ
Automatically. When your app calls identify(), or when feedback arrives with an email that matches an existing person, Usero maintains a Person record. The profile page reads that record plus everything linked to it. There is nothing to set up beyond the identify() call you likely already make.
Identity (name, email, external user id), the traits your app sent, MRR if you pass the mrr trait, first and last seen, their feedback across all sources, their session replays, and the merged pull requests linked to their requests.
Their feedback links to AI clusters, clusters link to pull requests, and merged PRs make the list, each paired with the specific request of theirs it answered. It is the same join Usero uses to email requesters when a changelog entry ships.
Click the requester name on any feedback detail page or the person chip on a session replay row. There is no separate people directory yet; profiles are reached from the places a person already shows up.
A browsable people index, company-level rollups, and profile filtering by trait. The current slice is the per-person page and its entry links.
Free tier. No credit card. Two-minute install. The AI opens the PR, you merge it.
Keep reading