Understanding Explore datasets

Your Zendesk data is split into different datasets. Each dataset contains metrics and attributes that you can use to build queries and generate reports. You must select a specific dataset before you can query your data with Zendesk Explore.

For help choosing and managing datasets, see Working with datasets.

For help creating queries, see Creating queries.

Tip: Do you need help finding the metrics and attributes you need to measure your success and make smart business decisions? If so, take a look at our Customer Service Metrics that Matter guide.

Use this article to help choose the right dataset for your reports and to learn more advanced information about how datasets store your business information. This article contains the following topics:

• Choosing the right dataset
• Understanding dataset structure

Choosing the right dataset

Datasets are available for the following products. Choose a product to read more about each dataset and discover the metrics and attributes you can use with them:

• Support datasets
  • Tickets: Key ticket metrics like number of tickets, ticket activity, and ticket type.
  • Ticket updates: Information about updates made to tickets during their lifetime.
  • Backlog history: Information about your unsolved tickets at the end of a given date.
  • SLAs: Information about your Service Level Agreement (SLA) performance.
• Talk datasets:
  • Calls: Information about your call center and agent activity.
• Chat datasets:
  • Chat engagement: Information about your customer engagement using Chat.
• Guide datasets
  • Answer Bot: Information about the effectiveness of your Answer Bot use.
  • Knowledge Capture: Information to help you understand the efficiency of selecting articles to deflect support tickets.
  • Team Publishing: (Guide Enterprise only) Information to help you understand your team activity in Guide including when articles are created, published, edited and more.
  • Knowledge base: Information to help you understand how often your help center articles are being viewed, which articles are being voted up or down, and more.

Understanding dataset structure

Explore datasets contain all of the available information for your product, or product features. In order to query your data efficiently and avoid duplicate or inconsistent data, Explore groups your data into multiple data tables. You can think of a data table as a kind of "box" in which your data is stored. Each data table is not isolated, they are joined to one another by connection points special attributes that act as unique identifiers for each row of data in the table.

In the example diagram below, ticket data is stored in the Tickets data table and user data is stored in a separate Users data table. These data tables are joined in the datasets using connection points special attributes.

For example, Ticket ID is the connection point for the Ticket data table but Requester ID is the connection point for the Users table.

When a user runs a query, Explore determines which tables contain the required metrics and attributes and if the tables need to be joined. If the required metrics and attributes are located in one table then no connections (or joins) are made. An example of this is a query that counts ticket IDs by status.

However, if the required metrics and attributes are in multiple data tables then the tables will be joined. An example of this is a query that counts ticket updates by assignee name. In this case, the Ticket updates, Tickets, and Users tables are joined to generate the result.

Explore data tables are connected using the LEFT JOIN method. This means that when the tables are joined, the query returns all rows from the table on the left, even if there are no matches from the table on the right. In the example above, a count of ticket ids by assignee name will return all tickets with or without an assignee.

In some cases, it is technically not possible to store data in multiple data tables due to the high volume of the data or high speed of the query execution required. An example of this is the Backlog dataset. This uses only one table for storing data.