Anonymous feedback still beats silence. You learn that something hurts. You do not learn who it hurts, on which plan, or whether that person paid you last month.
For SaaS products with accounts, unidentified messages create a tax on every triage session: chase emails, guess which workspace they meant, ping sales for context, or close the note as “not enough info.”
Signed identity closes that gap without turning your widget into a login form.
What “identified feedback” means
Identified feedback means the message arrives with verified attributes your backend already trusts — typically a stable user id, email, and display name — attached by your server, not typed by the visitor.
That distinction matters. Anyone can type ceo@bigcorp.com into a form. Only your app can mint a token that proves the session belongs to that account.
Why a signed JWT
A short-lived JWT signed with your project secret is a practical pattern:
- Your backend already knows the logged-in user
- You mint a compact token with claims (user id, email, name, optional metadata)
- The embed receives it (for example via
data-auth-token) - Gatherly verifies the signature and shows the identity in the inbox
Your secret never ships to the browser as a writable credential for forging identities. The browser only holds a signed assertion your servers produced.
What you unlock in the inbox
Once identity is verified, triage gets sharper:
- Account context — see which customer spoke without a back-and-forth
- Continuity — multiple reports from the same user collapse into one story
- Prioritization — weight messages from active paid workspaces differently from free trials
- Follow-up — reply with confidence that you are talking to the right person
- Security hygiene — reduce spoofed “I’m the admin” noise
This is especially valuable for multi-seat B2B products where “someone at Acme” is not enough.
What not to put in the token
Keep claims minimal and operational:
- Include: stable user id, email, name, avatar URL if useful
- Avoid: passwords, session cookies, raw API keys, large blobs of PII you do not need in the inbox
- Prefer short expiry and reminting on session refresh
Treat the token like any other signed credential: rotate secrets carefully, and never embed the project secret in frontend source.
Implementation shape
At a high level:
- User signs into your product
- Your server signs an identity JWT with your Gatherly project secret
- Your page loads the Gatherly embed and passes the token
- Feedback and chats from that session attach to the verified identity
The exact claim names and install snippets live in the docs — start with user authentication and the JavaScript API if you need programmatic control.
Anonymous still has a place
Public marketing sites, docs, and logged-out funnels should still accept anonymous notes. Not every visitor has an account. The win is progressive identity: anonymous when you must, identified when you can.
The product habit that follows
Once names show up next to messages, teams stop treating the inbox like a suggestion box and start treating it like a customer conversation log. That habit — reading real users with real context every week — is worth more than any single feature request.
If you already have the embed installed, adding identity is usually the highest-leverage upgrade you can make to feedback quality. The user authentication guide walks through the token flow end to end.