Explore session statistics
Once a bot has been launched, there is a large amount of information that we could access and that may be useful to us. For example, how long are the conversations? Which questions are users asking most frequently?
This section describes some ways that you can query volume of usage, whether for the entire bot or for particular flows in your bot. There are countless variations of the kinds of information you can query. Here we'll go over a few of the possibilities, and leave it to you to explore more of what you can do.
One of the basic queries you'll need is to check the amount of traffic your bot receives. We previously looked at using date transformers in a query to deliver a detailed report of bot usage per day, broken down by hour. We'll revisit that to set up this more general query for the amount of traffic per day:
1d date: catd(model="date") s.beginTime date date 2
This query displays the date and the number of sessions that occurred on that day.
There may be some noise in this, though, because we don't know whether users actually engaged with the bot. They may have started a session and never followed up with an actual question, for example, just by navigating to the website; the bot greets visitors and encourages them to ask a question, and this counts as the first transaction. Until we get a subsequent transaction with an actual user input, we may not be interested in that session. The following query shows the sessions that had at least one question after the session began. The query excludes sessions in which the user did not respond to the greeting and sessions in which the user only hit enter, sending an empty input.
1d date: catd(model="date") s.beginTime date, t.e.userInput!="" date 2
The query results will look something like this, depending on usage:
The results of the second query will likely show fewer actual sessions, but these are the sessions that will be the most interesting to examine because it's in these that users engaged with the bot by asking questions.
We measure the length of a session by the number of transactions (interactions). Are users having long conversations with your bot, or do they ask a single question, receive the answer, then end the exchange? Keep in mind that short conversations are not necessarily a sign of poor quality. If users quickly receive an answer to something that was blocking them, then continue with whatever they were doing, it's quite a good sign. Try this query to find out the distribution of session length:
1d s.transactionCount interactionCount interactionCount 2
This distribution shows you a list of the number of transactions, followed by a count of how many sessions contained exactly that number of transactions.
If you wish to examine sessions of a certain length, you can call up the session IDs as follows. in this case, we are looking at sessions with two transactions containing one actual question.
1la s.id: s.transactionCount == 2, t.e.userInput !="" 2
Alternatively, you may want to list those sessions in their entirety (the questions and answers), such as with this query, for all chats with four transactions or less:
1la t.id, t.e1.userInput userInput, t.e2.answerText botResponse: s.transactionCount < 5 2
Or try the same query with an additional refinement of omitting the first transaction, which only shows the bot's greeting:
1la t.id, t.e1.userInput userInput, t.e2.answerText botResponse: s.transactionCount < 5, t.index != 0 2
There are many variations to these queries that you can use to explore the kinds of sessions your bot had. Feel free to experiment!
Another interesting piece of information you may want to know about your bot is what questions come up most frequently, i.e. what the main intents users try to resolve when using the bot. Try this query to view the top flows that users triggered with their questions.
1d t.e.fname : 2 t.e.pathType=="flow-trigger" 3 count 4
Using the Longberry Baristas solution, you may see a result like this:
If you want to take this further, you can check the high volume flows to see if they are over-triggering. A query to display the user input that triggered the flow is all you need:
1lu t.e1.userInput: t.e2.fname == "Name of your flow here" 2