## Objectives

This section is about your conversational data. When you have been through the section, you will:

- Know how to access the conversation logs from inside Studio
- Understand what Teneo Query Language (TQL) is
- Know how to run a pre-built query against the logs to extract specific data
- Know how to view the logs of an entire session
- Know how big a session log file commonly is and how to design for a lean session log size

Objectives - Leverage your Conversational Data - Advanced

Objectives

The conversational data that is generated by the users of your bot is a valuable source of information for improvement, but can also provide you with valuable business insights.    

Business insights are normally set up to be extracted with [Augmenters](/data/analyze-log-data/augmenters) in combination with [Metadata](/data/analyze-log-data/metadata) and they can then be displayed in normal reporting tools such as [Microsoft Power BI](/resources/data-connectors/microsoft-power-bi) for easy consumption by stakeholders within your business.

You can access your bot's data in the Log Data tab in Teneo Studio. In this tab, you can find the conversational logs as soon as a session ends, which allows for fast analytics of conversations. The Log Data tab features functionality to query the data repository using the Teneo Query Language (TQL) and to step inside sessions (conversations) to inspect the details of the conversation. Additionally, it also features functionality to export the data which you can use to import to other BI tools which may already be deployed within the organization.

Watch the video for a high-level introduction to the Log Data tab and how the sessions are logged.

![Vimeo - Analyze Log Data](//videos.ctfassets.net/2vbtnveccz5s/3fVeX24QLv3umTUQwr7GmF/b2dc054b97efdc8bc15cffdee3add9f1/the_log_data_tab_explained__1080p__1_.mp4)

Analyze Log Data

Access your conversational data

Teneo Query Language (TQL) allows you to write custom queries and retrieve results that can be used to improve your solution. TQL queries run over a session’s transactions events. For example, they could be used to identify all inputs from the end-user that ended up in the safety net or investigate how often people visit a newly created flow that could be important to your business.

## Teneo Query Language

TQL queries are written in the Query tab and executed using the 'Run Query' button or the short-cut command Ctrl-c. The main Log Data Source window allows for multiple tabs to be opened but be aware, Studio does not cache these tabs. If you close your main LDS window without saving the queries, they will be lost. Shared queries can be found in the __Shared Queries__ tab and your recent run queries can be found in the tab __Recent Queries__. Both are located to the left in the main LDS window.

![query results 75](//images.ctfassets.net/2vbtnveccz5s/pCu1amt0PCQznNrNNaEOz/3df5a9e640d3ec38c030826df80e0fe1/query_results_75.png)

A TQL query consists of a command, one or more selection, and (optionally) a set of constraints and ordering.

*   Command dictates how the selection will be displayed.
*   Selection is what you want to investigate, such as session IDs, user inputs, or the chat bot’s response. Note that selection can consist of multiple items.
*   Constraints are optional and are written with a __:__ after the selection; this is used for making the selection stricter.

In the image below, the command would be d, distribute and the selection would be t.e.userInput and should be read as distribute the transaction events ‘userInput’. This query will return all the user inputs.

![Basic Query Annotated](//images.ctfassets.net/2vbtnveccz5s/7xfHKUAAIsuGxaR3fkhqpl/7b8eac6ef9b36f9c5f72739cdf59f7aa/basic_query_annotated.png?classes=w40)

Constraints can be added to make the selection more strict. The annotated query below should be read as: Distribute the transaction events 'userInputs' where the transaction event 'userInput' is not empty and order the returned results from most to least.

![Basic Query with constraint](//images.ctfassets.net/2vbtnveccz5s/56ge1NVYkMIypusKYrBXkR/1082034d8463776c68df83e59be849c9/basic_query_constraint.png?classes=w70)

!!! Note that you can order a command and a selection; the constraint is not required.

In the following example, we will construct a query that will return the number of different coffees that have been purchased, and then order this list to see which coffee has been purchased the most.



Here is the query we will use:
```tql
d t.e.fv:s:orderedCoffeeType : t.e.fv:s:orderedCoffeeType != "" order by count desc
```

With this query, we are looking at how many times the flow variable `orderedCoffeeType` has been populated. In the first part of the query - the selection - we are using `d`, short for 'distribute', to display a table. `t` stands for 'transaction' and contains user input and the bot's response. `e` stands for 'event'; events can be found inside transactions. After event, we specify the flow variable named `orderedCoffeeType` using `fv:s:orderedCoffeeType`. After the colon, we add a constraint to remove cases where the variable is empty. Finally, we order the results by count in descending order.

![tql example most ordered coffees 75](//images.ctfassets.net/2vbtnveccz5s/7pIx5bNqLCYOgscx7EHFLz/3a2a26ba9357f11ae808c0a96f3f2fd1/tql_example_most_ordered_coffees_75.png)

If we want to use this query again, we can share it so that it's available for our teammates working in the same Studio environment. With the query tab open, we can hit 'Share' in the ribbon bar and give the query a name.

![shared queries](//images.ctfassets.net/2vbtnveccz5s/6TJLxd6sXOBfemwt101xs3/d5491db9317d8aece0c7a3ce347a69fb/shared_queries.png)

Once we hit 'Save', we can see our shared query in the Shared Queries list.

![saved shared queries](//images.ctfassets.net/2vbtnveccz5s/2HkOn6huzPEayFLxvSIdjG/72782bdadd603c9c189a19d87be7e302/saved_shared_queries.png)

The [TQL cookbook](/data/reference/tql-cookbook) contains pre-built TQL queries with an explanatory text. If you are interested in diving into TQL, take a look at the [TQL reference](/data/reference/tql-reference-guide) page which goes deeper into all aspects of TQL.

## Pre-built queries

Besides the cookbook, here are some pre-defined TQL queries which you can copy and add to your LDS.

### List number of sessions by day

```tql
d date: catd(model="date") s.beginTime as date order by date desc
```

**Example result**

| date | count |
| --- | --- |
| "2019-12-16" | "67" |
| "2019-12-15" | "4" |
| "2019-12-14" | "19" |
| "2019-12-13" | "91" |
| "2019-12-12" | "70" |

### List number of transactions by day

```tql
d date: catd(model="date") t.time as date order by date desc
```

**Example result**

| date | count |
| --- | --- |
| "2019-12-16" | "891" |
| "2019-12-15" | "4" |
| "2019-12-14" | "133" |
| "2019-12-13" | "1610" |
| "2019-12-12" | "503" |

### Flows triggered by day

```tql
d date, t.e.folder as folderPath, t.e.fname as flowName: catd(model="date") t.time as date, t.e.pathType == "flow-trigger" order by date desc
```

**Example result**

| date | folderPath | flowName | count |
| --- | --- | --- | --- |
| "2019-12-16" | "/Greeting Message" | "Greeting message" | "65" |
| "2019-12-16" | "/Dialogue/Connecting Phrases/Acknowledgement" | "The user expresses agreement" | "2" |
| "2019-12-16" | "/Dialogue/Connecting Phrases/Acknowledgement" | "The user shows encouragement to the conversation" | "2" |
| "2019-12-16" | "/Dialogue/Connecting Phrases/Acknowledgement" | "The user says Yes" | "12" |
| "2019-12-16" | "/Dialogue/Conversational/Conversation" | "The user comments on the weather" | "2" |
| "2019-12-16" | "/Dialogue/Conversational/Conversation" | "The user wants to know the time" | "12" |
| "2019-12-16" | "/Dialogue/Connecting Phrases/Social" | "The user is telling his name" | "38" |

### List conversations

```tql
listAll s.id as sessionId, s.beginTime as beginTime, t.e1.userInput as userInput, t.e3.answerText as response, t.e2.fname as flowName, t.e2.folder as folderName, t.index as transactionIndex, t.time as transactionTime : exists t.e1.userInput, t.e1-{type=="response"}>t.e3, t.e2<{pathType == in {"raise-flow", "continue-flow", "resume-flow"}}-t.e3 order by s.beginTime asc, t.time asc
```

**Example result**  
(Some values have been shortened for brevity.)

| sessionId | beginTime | userInput | response | flowName | folderName | tIndex | tTime | 
|------------------------------------|-------------------------|-----------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|------------------------------------------------|--------------------|-------------------------|
| "117...E80" | "12/16/2019 9:44:33 PM" | "" | "Hello\! My name is Sara\." | "Greeting message" | "/Greeting Message" | "0" | "12/16/2019 9:44:33 PM" | 
| "117...E80" | "12/16/2019 9:44:33 PM" | "How are you doing?" | "Thanks for asking\. I'm having a great time\." | "The user asks, How are you? How was your day" | "/Dialogue/Connecting Phrases/Greetings" | "1" | "12/16/2019 9:44:46 PM" | 
| "117...E80" | "12/16/2019 9:44:33 PM" | "Okay\. Bye bye\." | "Goodbye\! See you again soon, I hope\." | "The user says Goodbye" | "/Goodbye Message" | "2" | "12/16/2019 9:44:53 PM" | 
| "420...94B" | "12/16/2019 9:44:57 PM" | "" | "Hi\! My name is Sara\." | "Greeting message" | "/Greeting Message" | "0" | "12/16/2019 9:44:57 PM" | 
| "420...94B" | "12/16/2019 9:44:57 PM" | "What time is it?" | "My watch says it's 10:45 PM\." | "The user wants to know the time" | "/Dialogue/Conversational/ Conversation" | "1" | "12/16/2019 9:45:09 PM" | 
| "420...94B" | "12/16/2019 9:44:57 PM" | "fantastic" | "Glad to hear that\!" | "The user says Good, Great, or Excellent" | "/Dialogue/Connecting Phrases/ Acknowledgement" | "2" | "12/16/2019 9:45:17 PM" | 
| "420...94B" | "12/16/2019 9:44:57 PM" | "Goodbye\." | "Goodbye\! See you again soon, I hope\." | "The user says Goodbye" | "/Goodbye Message" | "3" | "12/16/2019 9:45:23 PM" |

Running custom queries

Use queries to extract data from your conversational logs

The Session Viewer tab allows you to step inside of a conversation and inspect everything that took place during it. The Session Viewer has multiple use cases; you can use it to quickly see requests and responses and to inspect the events that occurred during a transaction. For example, you can analyze a session and build a query around any identified problems, then do more quantitative research on your stored sessions to see if this is a reoccurring problem using the Query tab, or vice versa.

## Step inside a conversation

To step inside a conversation, open a session view tab and press Run Query. If you are looking for a specific session you can use a session constraint, for example `s.id == "sessionId"` (just replace the string, __sessionId__, with a real session ID). You can also use the Order function to limit the results, get sessions, see transactions, etc.

The returned results will be displayed in the session list. The list provides general information about the session.

 ![LDS 75](//images.ctfassets.net/2vbtnveccz5s/193fiwiJxt2cnubCEPYsVw/315f36e77dcf772288ea818d2bd1489a/LDS_75.png)

A session consists of transactions, which in turn consist of events. A transaction is a request that is sent to the engine (bot) and a subsequent response from the engine. An event is what the engine did between processing the input and generating the output. You can expand and collapse a transaction to see its events, and you can expand and collapse an event to see its properties.

We can run all kinds of TQL queries to find sessions and then explore those sessions further in the session viewer tab. For example, let's run the following query to see some non-empty user inputs and corresponding bot replies, along with their session ID:

```tql
la s.id, t.e.userInput, t.e2.answerText:  t.e.userInput != ""
```

![tql query non empty inputs 75](//images.ctfassets.net/2vbtnveccz5s/4r7cP8CLqpcqqcReJN2T1f/bffa87226e234d227be57669743994b3/tql_query_non_empty_inputs_75.png)

If we want to take a closer look at any of these sessions, we can copy the session ID from the first column and open a new session viewer tab. To explore the session details, we can run the following query in the session viewer tab:
```tql
s.id == "[session ID]"
```

We can then click on the session to see its details.

![session details example 75](//images.ctfassets.net/2vbtnveccz5s/6Bupi0n7coZ0A77udf8u08/1ac5732e2d4d7db29d2ee9608ff77fc2/session_details_example_75.png)



## Filter

It is possible to refine the displayed data by using the ‘Find’ and ‘Filter’ buttons; however, it is not possible to filter or find values:

*   Find keeps all events visible, and navigates you to view the next instance of what you have selected.
*   Filter removes all events that are not in the selected property list and navigates you to the first one.

Analyzing sessions

The Session Viewer

Before you use Teneo Query Language to analyze your bot's sessions make sure that: 

* The bot is published.
* Inputs has been sent to the published bot. 

Conversations you had in [Tryout](/article/optimize/refine-your-bot/how-to/how-to-use-try-out) in Studio do not show up in the [Log Data Source](/data/analyze-log-data) and are not queryable; you need real data to use TQL. If your bot meets the prerequisites, you can skip this section. Otherwise, we walk you through the steps to get you to the point where you can start using TQL.

## Publish your bot 
Teneo Query Language needs data to work with. Once your solution has been published, users can interact with it. You can read more about publishing your bot in [this section](/engine/getting-started/publish-your-solution). Follow the steps there to publish the Longberry Baristas solution. If you've already published this solution you can continue with the next section.

## Generate a session log
1. Open the bot via the URL shown in the Publish view.     
2. Complete a conversation with an order or some small talk, whichever you like.    
3. End the conversation by clicking the button __End Session__ (Close the chat for Teneo Web Chat).        

The final step assures that the session ends immediately. This in turn allows the session to become immediately available to Teneo Query Language queries.

!!! If you forgot to end the session in this way, the session will still become available to Teneo Query Language queries after a default timeout period of ten minutes.

Generate Session Logs

Generate session logs

When users interact with your published bot, session logs are generated. In these set of steps we want to show you how to, 
* have a test chat with your bot    
* locate the session in the LDS session viewer for a closer look at what happened   

!!!!! The retention time for data in the Log Data Source (LDS) is 12 weeks by default for sandbox environments. This can be adjusted in the Teneo Manager. 

In the Session Viewer you can inspect the questions and answers as well as view information about the user input's path through the solution to a response.

## Find the latest session
1. Navigate to Optimization and select the tab 'Log Data'.    
2. Open the 'LDS' window (select the option Open under Manage Source).      
3. Click the button __New Session Viewer Tab__.   
4. Under __Order By__ select the options __Start Date__ and __Descending__.    
5. Click the __Run Query__ button.     
6. Double click the topmost session in the query results to view the details of the session.    

![TQL - Find latest session ](//videos.ctfassets.net/2vbtnveccz5s/2CQ71wVy05Gg8FojWnB9wa/99e97b77ed4a3d97cf7545c1a34f38c0/How_to_Locate_and_view_a_session_75.mp4)

!!! Note: if you haven't yet [published your bot](/engine/getting-started/publish-your-solution) you will not find a 'Log Data Source' listed under Optimization. In case you have published your bot, and no one has chatted with it, the LDS will exist but be empty. Please refer to the section on [how to generate session logs](/data/teneo-query-language/how-to/generate-session-logs).    

## Locate a particular session
You may want to examine a particular session you discover while running queries against the LDS. In general, your query should display the 'session ID', which you can then copy and use in a more detailed query focused on that session, as well as for locating the session directly in the session viewer for a more detailed examination. We will show you how to do that in these sections.

### Display general session information
The following steps show you how to run a query that returns a list of all sessions along with some associated information.

1. Open the Longberry Baristas solution.    
2. Click on the 'Solution' tab, located in the top left corner. Navigate to 'Optimization' and select the tab 'Log Data'.    
3. Open the LDS window (select the option Open under Manage Source).    
4. Run a query to display sessions:  ``la s.beginTime as beginTime, s.id as sessionId, s.transactionCount as numberOfInputs order by beginTime``.    
5. Select a session that looks interesting (due to start time or length) and copy out the session ID.    

### Run a query to display a transcript of the session
Now that we have a session to explore, we can run a query to show a simple transcript of that session (inputs and outputs). Try this:

```tql
la t.id, t.time, t.e1.userInput, t.e2.answerText: s.id == "<copy your session ID here>"
```

Now you should see a report of each transaction, along with the user input and bot response, for an easy reading of what happened. 

![1-query 75](//images.ctfassets.net/2vbtnveccz5s/hcrUGwC2jnQ70j5QjsjDP/08a8431205b01cbf4f4e244482e26523/1-query_75.png)

### Find a session in the session viewer
Sometimes you may want additional detailed information about the session, such as which listeners were active, which variables were set, etc. Perhaps you want to verify that something new that you built is working as expected. In this case, you can view a detailed report of the session, including all events of each of the individual transactions, in the session viewer.

1. Open the session viewer by clicking the button __New Session Viewer Tab__.
2. Enter a query:  ``s.id == "<paste in the session ID here>"``.
4. Click into the session via the result.

![TQL - Session Viewer](//images.ctfassets.net/2vbtnveccz5s/2SIVa5TCzKDHIxvY1QYO2J/2dd3b33ecbdddd6c9c951e168daad152/2-sessions_viewer_75.png)

From this view, you can expand or hide transaction and event details. Viewing the session in such detail can also be helpful when constructing queries you need to discover more sessions in which something particular happened, e.g. a variable changing while a particular flow is active, etc.


Locate and view a session

View a session log

Teneo Query Language is a versatile tool that can help you maintain and improve your system. In this section, we'll walk through some strategies for exposing weak points in a bot's repertoire

## View inputs to the Safetynet

The query to view user inputs that hit the [Safetynet](/studio/conversations/concepts/safetynet) could look like this:

```tql
lu t.e1.userInput: t.e2.fname ~= ".*[s|S]afetynet.*"
```

This query will print all unique user inputs for which the name of the subsequently triggered flow contains the string 'Safetynet'. This is the default name for the Safetynet in Teneo solutions using the Teneo Dialogue Resources. If you're using a Safetynet with a different name, be sure to adjust the query accordingly.

The results will typically include two types of input:

1.  Questions not yet in the solution's domain. In this case, you can decide whether to add new content to the solution to include these questions.
2.  Variants of questions that the solution should answer, but that were not assigned to the correct [intent](/studio/flows/concepts/triggers). In this case of the solution, you can adjust your training data in the relevant flows, or expand the condition to recognize the same sentence.

!f you want to view inputs to other flows, you can rewrite the query above using the exact name of the particular flow: `lu t.e1.userInput: t.e2.fname == "Name of your flow here"`

## View flows preceding the Safetynet

If a user input hits the Safetynet, you may want to go one step further and zoom out to get the bigger picture of what happened. A useful query for this is to list the flow and output that preceded the Safetynet input. Maybe the bot's answer was unclear, causing the user to ask a follow-up question for clarification. Or perhaps users did not like the answer they got and reacted with a complaint. In any case, these inputs can help to point out parts of your solution where you may want to take action, either by improving the bot's response or perhaps by adding a follow-up response in an individual flow.

A query that gives you this information can look like this:

```tql
lu t1.id as "Session ID", t1.e1.fname as "Preceding Flow", t1.e2.answerText as "Preceding Bot Response", t2.e1.userInput as "Unrecognized User Input" :
    t1.index == t2.index - 1,
    t1.e1.fname !~ ".*[s|S]afetynet.*",
    t2.e2.fname ~= ".*[s|S]afetynet.*"
```

Let's break down what this query does.

1.  The command and selection __lu t1.id as "Session ID", t1.e1.fname as "Preceding Flow", t1.e2.answerText as "Preceding Bot Response", t2.e1.userInput as "Unrecognized User Input"__ tells TQL to generate a report with the following information: transaction ID's, flow names, and responses for all transactions that we found. The header column should include the labels as given, e.g. "Preceding Flow", etc.
2.  The constraint __t1.index == t2.index - 1__ tells TQL to only include pairs of transactions that are immediately consecutive. T1, the first transaction, should happen immediately before T2, the second transaction. We can force this by referencing the indices of the two transactions. The index of T1 should be 1 less than the index of T2.
3.  The constraint __t1.e.fname !~ ".*[s|S]afetynet.*"__ is optional. It specifies that we want to ignore all transaction pairs in which the Safetynet response itself preceded a second response of the Safetynet; we chose to omit these transactions as they could just be noise, but if you want to see them anyway, you can leave the constraint out of the query.
4.  The final constraint __t2.e2.fname ~= ".*[s|S]afetynet.*"__ makes sure that the second transaction is one in which the Safetynet was triggered.

After running the query your results will look like something like this:

![TQL - Preceding Flow](//images.ctfassets.net/2vbtnveccz5s/59wniuQsjTMlYOwVEf9p9L/40fc6ffc79e52efa30a31af813a0205b/1-preceding_flows_75.png)

## A note on events

You may have noticed that we refer to items from different events in the query above.

In the first transaction we look at:

*   t1.e1.fname
*   t1.e2.answerText

In the second transaction we look at:

*   t2.e1.userInput
*   t2.e2.fname

There is an important reason for this. Consider the first case, where we are querying t1: here, we are first accessing the raised flow (with fname) and then the response (answerText). These two are from the same transaction, but different events. The same goes for the second case, where we query the user input, which is associated with the request event, followed by the name of the triggered flow, which is recorded in one of the later path events. If you are writing a query that you know should get results, and it returns nothing, make sure that you are referring to the correct events.


Troubleshoot the Safetynet

What fell into your Safetynet flow?

# 
Designing our bot to have an effective data footprint is a good idea from many perspectives. It lets us query the conversational log data much faster, puts a number of good practices into focus, and it makes us conscious of what we're storing in the conversational log data, which helps from a privacy perspective.

![Frame 16](//images.ctfassets.net/2vbtnveccz5s/4tNm2CBdKQ5Tj7HGlVmaRF/64f2e54dfc4b27d208baf43a1f97e5c7/Frame_16.png?classes=w40)

## Designed for Conversational Data

[Teneo Inquire](/data/analyze-log-data) — which is the analytics and data part of the Teneo platform — along with all of Teneo, is built to perform well on conversational data. Teneo is not designed to store large chunks of binary data or large and unique JSON structures.

Typical conversational data sessions in the Teneo platform are normally in the range of __50 kb__ to __400 kb__. Very large sessions, e.g. really long sessions with many turns of dialog, can be slightly larger at __400 kb__ to __800 kb__.

!!!  Teneo has a limit of __1 mb per session__. 

Teneo Inquire scales typical conversational data well with traffic, meaning it scales well in regards to API calls per session.

Teneo Inquire scales less well with data outside of its purpose, including:

* Conversational log data, which includes a large number of non-conversational data, such as big JSON payloads or large binary objects.
* Very large conversational log data sessions which are outside of the normal spans. This is often an indicator that the bot includes large chunks of non-conversational data.

## Solution data footprint is key

An effective solution data footprint is a key indicator of a well-designed bot. It also greatly impacts the performance of Teneo Inquire, which affects how fast we can query our conversational log data and how quickly Teneo Studio is able to give us feedback in e.g. the [Optimization section](/article/optimize/optimize-classes/review-inputs).

## Estimating the session size
The size of a session can be estimated from the size of the dialog history converted into a string. You can therefore estimate the session size in kb by using the following example snippet
```groovy
int sessionSize = (int) (engineAccess.dialogHistory.toString().getBytes().size() / 1000)
println("Session size ${sessionSize} kb")
```

This gives you a sense of how large your session logs are.

!!!!! This is recommended to be placed as a [End dialog](/article/build/scripting/concepts/scripts?all=&filter=script#global-scripts_session_end-dialog) global script and not anywhere else to reduce data footprint. 

### Store session size in Variables
Each session size can be retrieved and stored in a global variable, the script to retrieve this varies depending on if you want to access it to for your Development (Dev) and Quality Assurance / Staging (QA), or Production (Prod) environment. 

!!! Note that session size is given in kb.

Here is how to do that: 
1. Navigate to your solution backstage, followed up with 'Globals' and Variables. 
2. Create a new Global Variable called `sessionSize` and give it the value `0`.
3. Save and navigate over to 'Scripts'.
4. Add a new 'End dialog' script and use the following snippet:

Only in Tryout, Development (Dev) and Quality Assurance / Staging (QA)
```groovy
def releaseEnvironment = engineAccess.getProperty('servletContextParameters.release_environment')
if("production" != releaseEnvironment) {
    sessionSize = (int) (engineAccess.dialogHistory.toString().getBytes().size() / 1000)
}
```

For Production (Prod) - and all environments
```groovy
sessionSize = (int) (engineAccess.dialogHistory.toString().getBytes().size() / 1000)
```

!!! Please be aware that the changes will not be live until you [Publish your solution](/article/deploy/getting-started/publish-your-solution). 

### Retrieve Session size with TQL
You can then retrieve the session sizes with Teneo Query Language (TQL) using one of the following queries: 

| Query | Description |
| ----- |  ---------- |
| `la avg s.sv:n:sessionSize` | Get an average view of the sessions |
| `la s.sv:n:sessionSize as 'sessionSize' order by sessionSize desc` | List all the sessions in decreasing order |
| `la s.id, s.sv:n:sessionSize : s.sv:n:sessionSize >= 500` | List all sessions with over 0.5 mb size |
| `ca s.sv:n:sessionSize : s.sv:n:sessionSize >= 500` | Count the number of sessions with over 0.5 mb size |

## Good practices

Here are some good practices when working on your Data Footprint.

### Solution design

* Avoid sending in large 'blobs' or strings representing objects of data as these are very costly. Instead, use [integrations](/studio/scripting/concepts/integration-manager) to call web services when you need to retrieve this data.

### Teneo Inquire

* Use [Adorners](/data/analyze-log-data/augmenters#adorners)! Adorners can be used to copy variables from event level to session level, which means that they will be faster to query for. You can read more about Adorners in the [documentation](https://documentation.artificial-solutions.com/latest/#/user-guide/teneo-log-data-manager/augmenters?id=adorners) and [here](/data/analyze-log-data/augmenters#adorners) in the Developers pages.
* Use [Aggregators](/data/analyze-log-data/augmenters#aggregators)! Aggregators are used to aggregate data, for example the amount of traffic towards the bots' key flows. These are incredibly fast to query against, and can be used to power dashboards. You can read more about Aggregators in the [documentation](https://documentation.artificial-solutions.com/latest/#/user-guide/teneo-log-data-manager/augmenters?id=aggregators) and [here](/data/analyze-log-data/augmenters#aggregators) in the Developers pages.
* Use [Sample](/data/reference/tql-reference-guide#sample)! When your bot is successful and your datasets grow larger, TQL queries will take longer to run. To quickly design queries, you can use the `sample` command to ask Teneo to run your query over a small subset of sessions and return results. Read more about sampling in the [TQL Reference](https://documentation.artificial-solutions.com/latest/#/reference/teneo-programming/tql-manual?id=sample).
  * You can also use `limit`, but if the number of hits is small or if a mistake is made in the TQL query, you may end up waiting a long time for no results. Read more about limit in the [TQL Reference](https://documentation.artificial-solutions.com/latest/#/reference/teneo-programming/tql-manual?id=limit) and in the [TQL Reference Guide](/data/reference/tql-reference-guide#sample) in the Developers pages.
* When you are working on reporting and analytics, it's a good idea to work on your [Teneo Query Language](/article/analyze/reference/tql-syntax-overview) queries in Teneo Studio as you have much more support there. However, it is recommended to use the Teneo Inquire Client to run long-running queries.
  * Teneo Studio also gives you the possibility of [sharing queries](/data/analyze-log-data/running-custom-queries), which is a perfect way to save commonly used queries.
  * You can publish queries, which are then easy to retrieve using the Teneo Inquire Client.
* Do not wait to set up efficient reporting - do it already in __sprint 1__ and extend it as you go. This will make sure things are done right from the beginning.

## Further reading

Further reading can be found in the [Forum](https://community.teneo.ai/), where you can ask questions to a Teneo Developer.

* [Reducing Your Session Data Footprint](https://community.teneo.ai/t/reducing-your-session-data-footprint/217)
* [Obscuring Structured Data in Logs](https://community.teneo.ai/t/obscuring-structured-data-in-logs/279)
* [Anonymize user data with Pre-logging Scripts](/article/build/scripting/how-to/anonymize-user-data)


Data footprint

Pay attention to your Data Footprint!

## Reference Materials & Resources: 

### Reference materials:
- Teneo Query Language:
  - [Data Hierarchy](/article/analyze/teneo-query-language/data-hierarchy/property)
  - [Query Syntax](/article/analyze/teneo-query-language/query-syntax/command)
- [TQL Syntax Overview](/article/analyze/reference/tql-syntax-overview)
- [TQL Reference Guide](/article/analyze/reference/tql-reference-guide)
- [TQL Cookbook](/article/analyze/reference/tql-cookbook)

### Resources:
- [Data Connectors](/resource/data-connectors)


Leverage your Conversational Data

Objectives

Next page