This article explains how to create metrics and reports using the Ticket Events datasets.

Ticket Events tracks all events of a ticket. The Ticket Updates attribute is the center of all our Ticket Events, and it's broken into three types of events. When looking at events you will create a count metric with Ticket Updates and one of these three events and use the other attributes to filter for what you are looking for.

Understanding the Events model

Before the Ticket Events model was added to Insights, reporting was ticket-centric, and we could only tell what your Zendesk looked like currently (for example: current assignee of a ticket, how many tickets are currently open, and so on). Ticket Events tracks all events of a ticket over time.

Here is the model of every Insights project.

The Ticket Updates attribute is the center of all our Ticket Events, and it's broken into three types of events: text field changes, numeric changes, and satisfaction score changes. Let's define each of these data sets in the events model.

Ticket updates

Ticket Updates is the key to the events model and is an attribute which is represented as a unique ID for each time the Submit button is clicked on a ticket. Within one ticket update you can have multiple events, such as the image below:

An important thing to note is the Ticket Update ID is randomly generated and does not represent the order in which events happen.

There are three different types of field change:

Ticket text field changes

Ticket numeric field changes

Satisfaction survey changes

Ticket text field changes

To measure ticket text field changes, you will use the Ticket Text Field Change dataset. This dataset captures changes to any system or custom text field within a ticket. In this model, "text field" refers to any qualitative field, including ticket text fields, dropdown fields, and checkboxes.

There are three key attributes for each text field change:

Text Field: the field that changed

[Text Field] Previous Value: the value before the change

[Text Field] New Value: the value after the change

For example, if a ticket status changes from Solved to Open, it will have these three values:

Text Field: Status

[Text Field] Previous Value: [Status] solved

[Text Field] New Value: [Status] open

This type of tracking enables us to see how many times a ticket text field changed.

Ticket numeric field changes

Very similar to ticket text field changes, the Ticket Numeric Change dataset captures changes to any system or custom numeric field within a ticket. In this model, "numeric field" refers to any quantitative field, including ticket numeric and decimal fields.

There are also three key pieces of information for each numeric field change. However, numeric fields behave a bit differently.

Numeric Field is an attribute, and it captures the field that changed.

[Numeric Field] Old value and [Numeric Field] New value are both facts, and they capture the values before and after the change.

For examples of how to use numeric field changes in reports, check out this recipe article for the Time Tracking app.

Satisfaction Survey changes

The third type of change that is tracked is satisfaction surveys. Satisfaction surveys are similar to ticket text fields, but they have special rules and restrictions in Zendesk.

The Satisfaction Survey Change dataset has two key attributes:

Satisfaction Old Value: the value before the change

Satisfaction New Value: the value after the change

These attributes only have four possible values: Unoffered, Offered, Bad, and Good.

Creating metrics using the ticket events

Now that we’ve gone over the building blocks of the Ticket Events model, the next step is to learn how to create metrics using these different attributes. Typically, if you want to look at the number of events, your metric will look like this:

“Count the number of updates with at least one ticket text field change, where the status field changed to open, pending, or on-hold status from solved status, and the ticket has not been deleted.”

If you want to slice the report by the lowest grain (Ticket Updates) it will look like this:

As you can see, ticket ID 226 had 3 re-opens.

In Insights there is a default metric called # Reopens that measures the total number of reopens on each ticket. The custom metric above allows you to slice by Date (Event), so you can see when each reopen actually took place.

Example 2: How many times was the ticket updated with a comment?

Ticket comments are not stored in a separate dataset. They are connected directly to the Ticket Updates dataset.

There are three default metrics that count updates with comments: # Total Comments, # Public Comments, and # Private Comments. These metrics use the Comment Present and Public Comment attributes to find updates with public or private comments.

Hello!! First time to create a new metric. :) I was told by zendesk support to replicate this metric for a report I'm building.

However, this is what I came up with because there is no 'ticket text field change" and "status". Just "Records of Ticket Text Field Change" and "Ticket Status".

So I continued with that metric. I was also told to input the following in the HOW Tab and Filters

The report is supposed to look like this:

However,when I followed everything (except for the custom metric), no data will show. It says no data match the filtering criteria. I think it might be the custom metric because that's the only one that's not exactly the same as what I was told to do. Am I missing something?

Hi Jacky! You can only capture one text field change at a time in a single metric, since each field change has its own ID. However, you can nest a filtering metric within a larger one. This works because one update may include any number of individual field changes, and you can work with updates and field changes separately.

In this case, you would start by finding one of the field changes in its own metric:

(The # Ticket Updates at the start is under Metrics, while the Ticket Updates at the end is under Attributes.)

This metric counts ticket updates with a text field change from Group L1 to Group L2, where the update as a whole also includes a status change from open to on-hold. The result should be updates with both types of field change.

Please note - these examples are provided for demonstration purposes only. I can't guarantee them for all use cases, and I strongly recommend that you audit your results.

This finds ticket updates with some other text field change, where the ticket was in the "L1" group at the start of the update, and the update as a whole is not counted in the group change metric.

For more information, you can check out GoodData's documentation on IFNULL Best Practices. It's not directly related to this use case, but we also have similar numeric range filtering in our recipe for Reporting on ticket tags.

As before, this metric is just to give you a starting point and some ideas. I can't guarantee this for all use cases, and I strongly recommend that you test and audit the results. There are a lot of moving parts here, so you'll want to make sure they fit together as you intend.

under HOW I used Category, Date (Event), Ticket Id, Ticket Updates, and Updater

under FILTER I used Ticket Id where Date Created on or after 01 Jan 2019is greater than0

Although, the report I am receiving is showing the date event, but not the different categories used in the ticket (please see below). It is only showing one category (i.e., the last category updated).

I am not sure, what wrong I am doing here? Looking forward to your help and great support.

Hi Guys, after some guidance. I must be doing something wrong and am just missing it.....

I am trying to report on tickets that have changed severity, (which is a custom field but shows in the ticket event history when it is changed etc) and found this article which pointed me in what I hoped was the right direction. So I took the example that was used to show tickets being re-opened etc and tried to create a metric for my severity report. So what I ended up doing was this....

No matter what I do it says it has an unexpected ']' and is expecting a ')'.

I edited all the way back to the first value after the IN statement and it looks like it is having an issue with the first attribute listed having the [ ] around it after the IN, however that is what the example shows and I'm assuming this works for others, so I must be doing something wrong.......

Many thanks for your input. You were correct re the typo on the Moderate Severity bracket, that indeed was showing as a curly bracket.

So I think I understand what you were saying re the attribute vs the attribute values, that makes sense.

However when I add the attribute value for severity it brings up the list of values and I have to select one or all of them, in my case 1 through 5 from Critical to Minor.

I cannot add just the one value in orange like you have in your example.

And then again when I select the values for the text field New Value and Previous Value etc it adds the values as 1-Critical, 2-Urgent, etc, etc, but they do not have the Severity part first in the square brackets, [Severity] 1-Critical, etc.

So have I somehow got the add of the attribute value incorrect?

So for example if I add the attribute values for Severity my Metric looks like this:

All sorted and working now. I was confusing the attribute values of the actual attribute I had called 'Severity' with the attribute values for the [Text Field] New Value etc, which has the severity values included.Got my head around it now. Thanks for your assistance, very much appreciated.

Hi, Is there any way to get replies data in the report based on metrics with Text Field changes and attributes? I have a report with Priority (Historic) attribute and a custom metric for counting customers' comments (using Text Field changes attribute), but can not build a proper metric for counting ALL agents' replies (because not all events with replies have text field change there). I know the comments are not connected with any field changes but maybe there is some workaround?

While I'm rather limited on what I can assist with when it comes to custom metrics, it may be helpful for other users to jump in if we had a screenshot of the custom metric you've set up. Any additional information you can provide may beneficial :)

I'm not sure if there are any other implications to duplicating the metric with this slight edit other than the fact that it will begin to include Ticket Updates even if there were no Text Field changes. If anyone knows more about this I would be interested to know as well.