TQL helps you to examine what went on during a session by allowing you to query the contents of variables at all levels: whether global variables, flow variabes or at the session level. Each session log contains a complete record of where and how each of the solution variables is set.
Here we want to walk you through different variable queries you can perform using TQL. If you've already published your solution and wish to query your own variables, you can skip the steps to set up the solution and generate session logs.
Let's take the Longberry Baristas solution and add some variables to document when the safety net becomes active during a conversation. We want a flow variable and a global variable. In the case of our global variable, we want to query it at the transaction level as well as at the session level. When we told you about session properties and attributes we mentioned the use case for querying variables at the session level. After following the steps below, you'll be able to try this and other queries yourself.
Define a global variable to count safety net hits. Call it
safetyNetCounter, and set the initial value to 0
Edit the solution's safety net (It's the flow "Safetynet" in the folder "Safetynet" and add this On Top script:
Define a flow variable safetyNetActive and initialize it to true.
safetyNetCounter = safetyNetCounter
Now that the solution is published, we'll need to generate some sessions by chatting with the bot. If you already have session logs, you can skip this step. Since we're counting safety net hits, try to create a number of different variations of safetynet occurrences:
In our section on generating session logs we show you the necessary steps in more detail.
Each time the safetynet flow becomes active the Boolean flow variable safetyNetActive is created and initialized to true. This query employs a constraint based on that variable to show all transactions in which the user input ran into the safety net:
la t.id, t.e1.userInput as userInput: t.e2.fv:b:safetyNetActive == true order by userInput
There are a few things to note in the query:
We defined a global variable above called safetyNetCounter. In this section we'll walk through various queries you can use to find out how the safetynet was used in your bot's session.
First of all, let's try a query that duplicates the result we saw above using the safetynet flow variable to locate safetynet transactions. We want to see the transaction ID and the user input when the safetynet triggered:
la t.id, t.e1.userInput as userInput: t.e2.sv:n:safetyNetCounter > 0 order by userInput
Here are some important details about the query:
Our variable counts the number of times the safetynet became active, meaning we can try some queries to zoom in on particular sessions based on frequency of safetynet activity. Here you have to think carefully, because there are some subtle nuances to writing the necessary constraints.
Let's say we want to find all the sessions in which the safetynet was not active at all. If we use this query, we will get some unexpected results, namely that it finds all sessions, inclusing those in which the safetynet was active:
la s.id: t.e2.sv:n:safetyNetCounter == 0
This is because we are looking at snapshots of the counter in individual transactions. Every session starts out with the counter at 0, meaning there is always a transaction that meets that constraint. This is why the query finds every session. The query does not consider what happens later to the counter. It may increase, or may not. We can however formulate the constraint in such way as to find sessions in which safetynet usage exceeds a certain threshold.
la s.id: t.e2.sv:n:safetyNetCounter > 0
The query above shows us queries in which the safetynet was active at least once.
This query finds sessions in which the safetynet was triggered 3 or more times.
la s.id: t.e2.sv:n:safetyNetCounter >= 3
What if we want to find sessions in which the safetynet was active exactlly n times? This is where we reach the limit of what we can query at the transaction level. In the next section we'll show you how you can query variables at the session level..
If you recall the code we added at end dialog, we assigned the counter variable to itself. The reason we did this is to cause the variable to be logged at the session level as a session property. Variables that change during the end dialog script are not associated with a particular transaction but with the session. Now we can easily write queries to show, for example, sessions in which the safetynet was never triggered, or triggered a certain amount of times.
la s.id: s.sv:n:safetyNetCounter == 0
Note that we use the same prefix sv:n but this time, associating the variable with the session, and not a transaction/event.
To find sessions in which the safetynet triggered exactly 3 times:
la s.id: s.sv:n:safetyNetCounter == 3
But we can also query for sessions that exceeded or did not exceed a particular threshold, for example, here we want sessions in which the safetynet triggered less than three times:
la s.id: s.sv:n:safetyNetCounter < 3
And this finds sessions in which the safetynet triggered more than three times:
la s.id: s.sv:n:safetyNetCounter > 3
We don't have to worry about any unintended side effects of the query, because at the session level, we are dealing with one precise value.
You may simply want to generate a report of safetynet behavior for all your session. Here you could try:
la s.id, s.sv:n:safetyNetCounter
This is a distribution query that gives us a feeling of overall safetynet occurrences:
Safetynet activity is an important key performance indicator in bots. Over time, as more content is added to the bot, and improvements are made to existing knowledge, we would expect the safetynet to trigger less frequently. Using queries like this, we can find out if that is the case.
Was this page helpful?