The Analytics page gives you a high-level view of how your widget is being used: conversation volume over the last 30 days, unique wallet connections, and knowledge base size.
Key metrics
Conversations
Total support sessions, all time. Counted from when the user sends their first message.
Connected wallets
Unique wallet addresses that have connected during widget sessions. A measure of distinct engaged users.
Knowledge base
How many pages you have indexed across your documentation sources. Pasted text counts as one source.
Active chains
How many of the supported chains you currently have enabled.
The conversation chart
The main chart shows daily conversation volume over the past 30 days. Look for:
- Spikes following announcements or protocol events: users seeking clarity on changes
- Drops that might indicate the widget isn't loading or has been inadvertently paused
- Growth trends as your protocol scales and more users find the assistant
- Day-of-week patterns in when your community is most active
Note
Analytics data is updated in real-time. The conversation count on the Overview page always reflects the current all-time total.
Pilot insights
Above the shortfall lists, Analytics turns the conversations into five things you can act on. All of them are counts, never percentages: a rate off a handful of conversations is a number you cannot defend, so while the sample is small the page says so.
What your docs did not answer
The questions, in the tester's own words, where the documentation search found nothing or matched only weakly. This is a task list for whoever writes your docs, and each one links to the conversation.
What testers kept coming back to
The phrases that appear across more than one conversation, ranked. Their words, not ours, so you see what the beta was actually about.
Where problems were found
Bugs and feedback ranked by the page the tester was on when it happened, recorded at the time. Most support tools never know this.
How conversations ended
Answered, hit the message limit, no reply, or marked unhelpful. There is deliberately no 'resolved': someone who got what they needed and someone who gave up look identical in the record.
What answers rested on
Verified against a live read, from your documentation, or unverified. Taken as the worst case in each conversation, because one unverifiable answer among good ones is the one worth seeing.
Where it fell short
Below the insights, Analytics shows the conversations that did not go well: the ones a user marked unhelpful, the ones that needed a human, and the ones that ended in negative sentiment without ever escalating. That last group is the one you would otherwise never see, because those users do not complain, they just leave.
Knowledge gaps versus data gaps
A weak answer caused by missing documentation and one caused by a failed chain read look identical in a transcript, but the fixes have different owners. Failed reads are recorded against each answer, so the two are listed separately. Adding documentation will not fix an indexer outage.
What is not tracked yet
Resolution rate and average conversation length are not measured. Deflection rate, the share of conversations that never needed a human, is on the roadmap.