Use relative dates in queries

If you've just published your bot with some new content or improvements to existing content, you may want to check only the newest sessions, to be sure everything is working as expected. In this scenario we don't care about older sessions because the content and changes are not represented there. You can always add a time contraint to a query to have it apply only to sessions on a particular day. This query, for example, shows session transcripts that occurred during a particular time frame (January 15-31, 2020). The query uses the catd date transformer which we described earlier

la s.beginTime as timestamp, t.id, t.e1.userInput as userInput, t.e2.answerText as botResponse: 
 catd(model="date") s.beginTime as date,
 date == in {"2020-01-15".."2020-01-31"}

You might save the query as well, but you would need to modify it with the new date each time you run it. There is a way to avoid that. TQL can query backwards from the current time, without the use of an absolute date. It's a perfect way to call up only the latest sessions to verify that new content or changes are working properly, while at the same time ignoring older sessions generated before the publish. You may, for example, want to run such a query after returning from vacation, to examine sessions that occurred while you were absent. The next sections show different variations of this kind of relative constraint.

Looking at a Particular Week

In this section we'll walk through various queries centered on different weeks.

Ongoing week

This query looks at the sessions of the ongoing week

la s.beginTime as timestamp, t.id as transactionId, t.e1.userInput as userInput, t.e2.answerText as botResponse: 
    s.beginTime == in {"now/w"} 
    limit 200

At first glance, the time syntax of this query might appear unclear. It means, taking now as the starting point, look at the sessions occurring in that week. Note that we added a limit of 200 results. This is entirely optional, but you may want to add a limit if you are more interested in trends, and don't need to see the entire results. A full query might also deliver too much data, and take much longer to run. Remember also, that the ongoing week is not yet complete, so the result, by similar traffic, may not be comparable to past weeks.

Comparing different weeks in the past

You can use a series of relative queries to compare two different weeks with each other. Let's have a look at the frequency of safetynet inputs of the last week and of the week before last. If you published improvements in the past week, this could give an idea of the impact.

To count last week's safetynet occurrences you can run the following query:

ca t.id as transactionId: 
    t.e1.fname ~= ".*[s|S]afetynet.*",
    s.beginTime == in {"now-1w/w"}

You can read this as: Count safetynet transactions in the week of sessions previous to this week. The query delivers a single count of how many times the safety net was active in that time period.

The counterpart to that query, to count the safety net of the week before last would be as follows:

ca t.id as transactionId: 
    t.e1.fname ~= ".*[s|S]afetynet.*",
    s.beginTime == in {"now-2w/w"}

If you wish to compute percentages you would also need to count the total number of sessions during the week by removing the safetynet constraint. This is information that would be interesting to display in an analytics dashboard, for example.

Looking at a Particular Month

It is important to have an indication of real bot usage. With this we mean sessions in which the user asked at least one question. Teneo logs everything, even sessions in which nothing happened, e.g. the user called the bot, but did not follow up with a question. Even cases where the user called the bot and hit enter several times, without asking anything. We want to filter out these kinds of non-sessions. With the query below we can generate a clean statistic of conversations, leaving out the noise.

ca s.id as sessionId: 
    t.e.userInput != "",
    s.beginTime == in {"now/M"}

While this variation shows the sessions of the previous whole month:

ca s.id as sessionId: 
    t.e.userInput != "", 
    s.beginTime == in {"now-1M/M"}

If your bot is driven by button-inputs that translate to parameters instead of an input text, you will need to design a different query.

Querying the Last Hour(s)

You can also run a query to find the latest sessions that ran. For example, if you've just published something, and tested it on the live bot, you may want to verify particulars about the newest conversations. Or at least verify that sessions are still occurring normally. You can call up the sessions of the ongoing hour this way:

la s.beginTime as timestamp, t.id as transactionId, t.e1.userInput as userInput, t.e2.answerText as botResponse: 
    s.beginTime == in {"now-0h/h"}

Sessions that ran in the previous hour are shown with this query:

la s.beginTime as timestamp, t.id as transactionId, t.e1.userInput as userInput, t.e2.answerText as botResponse: 
    s.beginTime == in {"now-1h/h"}

Additional Queries

After going through these queries you probably noticed that the first part of the constraint, the part left of the backslash "/" contains the time reference of what you want to query. You can specify "now" but also an offset to now (into the past). This offset is optional and can be of the following types:

  • s: seconds
  • m: minutes
  • h: hours
  • d: days
  • w: weeks
  • M: months
  • Y: years

If you write "now" by itself, there is no offset and the query refers to the current point in time. Otherwise you can subtract units of time to place the time in a different hour, day, week, etc.

The second part of the constraint that follows the backslash "/" tells which amount of data to extract. Go to the point in time specified in the first part of the constraint, and then extract the day, week, month, etc. in which that point in time lies.

Was this page helpful?