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 new content and changes are not represented there. You can always add a time constraint 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 (between January 15, 2024 and January 31, 2024). The query uses the catd date transformer that we described earlier.

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

We might save the query as well, but we would need to modify it with the new date each time we run it. There is a way to avoid that. TQL can query backwards from the current time, without the use of an absolute date. This way, we can 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. 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:

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

What the time syntax in this query does is take the current time as the starting point and consider the sessions occurring in the current week. Note that we added a limit of 200 results; this is entirely optional, but you may want to add some type of limit if you are more interested in trends, and do not need to see the entire results. A full query might also deliver too much data, and take much longer to run.

Remember, 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 us take 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 you an idea of the impact.

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

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

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 Safetynet was active during that time period.

The query to count the Safetynet hits in the week before last would then be as follows:

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

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 Google charts or Microsoft Power BI, for example.

Looking at a Particular Month

It is important to have an indication of real bot usage, i.e. 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 are recorded. 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.

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

This query shows the sessions of the previous whole month:

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

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 with the following query:

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

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

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

Additional Queries

After going through these queries, you probably noticed that the first part of the constraint, the part to the left of the "/" 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

Note that minutes are represented with a lowercase m and months with an uppercase M.

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 (the one following the "/") specifies how much data to extract. Starting at the point in time specified in the first part of the constraint, this second part then causes the day, week, month, etc. in which that point in time lies to be extracted.

Keep in mind that if you use relative dates in your queries in the Log Data Source, you should remove the time constraint in the Date Range Selector to avoid having potentially mismatching time ranges.