Query variables

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.

Set up variables in solution

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.

  1. Define a global variable to count safety net hits. Call it safetyNetCounter, and set the initial value to 0
    define safetynet counter

  2. Edit the solution's safety net (It's the flow "Safetynet" in the folder "Safetynet" and add this On Top script: safetyNetCounter++
    flow script to count safetynet hits

  3. Define a flow variable safetyNetActive and initialize it to true.
    define flow variable

  4. In the solution's global scripts section at End Dialog add this script: safetyNetCounter = safetyNetCounter
    end dialogue script
  5. Publish the solution: we show this in detail in this section

Generate session logs

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 which the safetynet does not occur
  • only one input runs into the safetynet
  • several inputs run into the safetynet

In our section on generating session logs we show you the necessary steps in more detail.

Query flow variables

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:

  • Since safetyNetActive is a flow variable, it has the prefix fv:b, meanng a flow variable of type Boolean.
  • We use a transaction and event prefix to access the variable: t.e or some variation like t1.e2, etc.
  • The user input and the setting of the flow variable occur in different events, so we refer to e1 and e2. The input is associated with the request event, whereas the variable is set later, after the safetynet flow is triggered.

Query transaction variables

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.

Query safety net inputs

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:

  • To reference this variable we use the prefix sv:n, meaning a session variable of type integer. We also look for the variable within a transaction and event.
  • We need an additional constraint, that the counter has to be greater than zero. This is because the variable is logged each time it changes, including the first time it is created and initialized. The occurrence of the variable (initialized to 0) is not associated with a safetynet event, meaning we do not want to view those transactions.
  • It is important to differentiate which events in the transaction we are looking for. The user input and the safetynet variable are found in separate events, not the same one.

Query count thresholds

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..

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:

d s.sv:n:safetyNetCounter

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?