Overview
Reporting on ticket tags in Insights when taking one of the following actions:
- Excluding one or more tag(s) from a report
- Filtering reports by tags
Conditions
Zendesk Professional or Enterprise account with access to Insights
Procedure
Reporting on tags is tricky in Insights. There can be any number of tags on a ticket at the same time, and you may need to report on any one of them.
To make this possible, tag data is stored in its own dataset. While this gives you the ability to report on individual tags, regardless of how many tags are on each ticket, it does mean you need to take some extra steps.
This article just covers the basic recipe. For more information about how tag reporting works, including the logic behind this recipe and some specific examples, check out this article: Reporting on tickets with one or more tags.
Create a custom metric for each tag
Since tickets can have multiple tags at the same time, almost every ticket will have at least one tag record that is not the one you're filtering for. This means any filter using Ticket Tag ISN'T, Ticket Tag <>, or Ticket Tag NOT IN will just return all tickets. You must create the metric described below and use a numeric range filter to include (=1) or exclude (=0) tickets with certain tags.
You need to create separate metrics for each tag you want to include in reports. The metrics should all follow this template:
- SELECT IFNULL((SELECT # Tickets WHERE Ticket Tag = your_tag),0)
- Replace your_tag with the tag you want to use in the report.
This metric will return a 1 for tickets that do have the tag and a 0 for tickets that don't have the tag. That means you can use it to include or exclude tickets based on their tags.
There are two main ways to do this:
1. Add a numeric range filter to the report
- For the attribute, select Ticket Id.
- For the metric, select your custom tag filtering metric.
- For the range, there are two options:
- Select "is equal to 1" for tickets that do have the tag.
- Select "is equal to 0" for tickets that do not have the tag
This will filter the whole report based on the tag in your metric. This is useful if you want to compare several different metrics with the same tag restrictions.
2. Nest the tag filter in a custom metric
This will vary a bit, based on the metric. However, the tag filtering portion should follow this template:
- Tag is present: SELECT metric WHERE (SELECT # Tickets with your_tag BY Ticket Id)=1
- Tag is not present: SELECT metric WHERE (SELECT # Tickets with your_tag BY Ticket Id)=0
This allows you to compare different tag filters within the same report.
79 Comments
What would be the best way to work this into a CSAT report?
I created the # of tickets by tag metric, but i can't seem to filter by it on a CSAT % report.
I am new to building reports and I am wondering if there is any other way to filter a report by ticket tags other than this metric style?
If not, can anyone offer assistance? I am struggling to add a metric to the report that I have built.
The example is that tickets that have multiple tags (i.e. escalated, call_center_access_request) are showing up in my report. I need all tickets that include call_center_access_request to be excluded. The complication is that I want the escalated tags to show UNLESS call_center_access_request is also tagged. Does that make sense?
Thanks for the assistance you can offer!
Tricia
Hi Jesse!
I've created a ticket for your question, as it will involve looking at account specific data.
You'll hear from me soon :)
Hey Tricia,
You should be able to set up that logic by creating up a metric for each tag, one to exclude call_center and one to include escalation.
That should only show you the tickets with the escalated tag but without the call_center tag!
Hello!
I really like the guide and has just begun unraveling the more hidden potentials of Zendesk, and ofc I have encountered a little snag that I am wondering about.
I have created a custom metric that contains a couple of custom metrics, the function is to filter out all tickets that contains a couple of custom tags.
So, the "main metric" that holds the other ones works well, it contains everything I need. This little "snag" that I encountered is that I can´t render a report that sorts tickets on "ticket tag" instead of "ticket group" as an example (which works but doesn´t give me what I want).
I might add that all the custom metrics are build on the "# Tickets" metrics, so this should work.
As an example of what I want to do is shown below. The problem seems to be that I can´t render the report with "ticket tag" as a "How".
"What"
- satisfaction score
"How"
- ticket tag
"Filters":
- ticket tag where id is <the custom metric> is equal to 1
- ticket tag where id is closed_by_merge is equal to 0
So the question is, how do I solve this puzzle? The only solution that I have right now is to make a dashboard with one report per metric, which will take a boatload of time since I estimate to end up on 200 tags.
Thanks
Mikael
Hi Mikael! The most important piece here is that "satisfaction score" metric under WHAT. If that metric is not properly connected to ticket tags, you won't be able to slice by Ticket Tag under HOW.
If you just want to filter your results by tag, then these custom metric filters should work in any report that looks at ticket data. However, if you actually want to display tags in the table, then every metric needs to be correctly connected to tag data.
Try making a version of this report that uses the # Tickets metric and the Ticket Satisfaction Score attribute. That should allow you to use tags in the chart.
I hope this helps! Happy reporting!
Hi,
This article covers exactly what I was looking for, however I'm having some difficulty in implementing the advice within.
What I'm looking to do is report on the number of tickets raised and solved against a couple of custom field attributes, but to exclude any tickets that have been closed by merge, as they for me are duplicates. For example, here is one such report, which I display as a Donut chart:
WHAT: #Tickets Created
HOW: Product (custom field) & Week (Mon-Sun)/Year (Ticket Created)
FILTER: Week (Mon-Sun)/Year (Ticket Created) is last week
I've got as far as creating the custom metric:
I've tried both suggested methods of using this new custom metric, but having some issues:
If it would help for me to raise a ticket and/or provide any additional information about the way that my metrics/reports are set up, more than happy to do so. I think that if I can get this working in one report I can pretty easily replicate it across the rest.
Hi Jamie! I see the issue here. The # Tickets Created metric is looking for ticket creation events. It is not connected to tag data, so it will not work in this metric.
You need to use the # Tickets metric for the tag filter. It is the only default metric that is correctly connected to tags.
Fortunately, you do not need to display the tag filtering metric in your report. It just needs to exist for a report filter. (The layout is in the "Numeric Range Filter" section of the recipe above.) Once you have the report filter in place, it should work with any ticket-based metric.
The rest of your recipe looks fine. Just use the updated tag metric under FILTER and your usual # Tickets Created metric under WHAT, and you should get the results you need.
I hope this helps! Happy reporting!
Hi Amy,
Thanks very much for your response, that worked perfectly for the example report that I shared, it removed the 2 tickets that I know for a fact were "closed by merge".
Unfortunately, I haven't been able to replicate this across my other reports, I've compared them side-by-side and can't see what fundamental difference there might be that makes them work differently.
A further example of a report (line chart) that I'm struggling with is as follows:
WHAT: #Tickets Created
HOW: Week (Mon-Sun)/Year (Ticket Created)
FILTER: Week (Mon-Sun)/Year (Ticket Created) is from 6 weeks ago to 1 week ago AND <attribute> where Tag Filter "closed_by_merge" is equal to 0 (this my tag filter, which now uses # Tickets rather than # Tickets Created)
When I save this out I see only "No data match the filtering criteria" again, but it's almost exactly the same as the report discussed yesterday that I was able to successfully amend. The only differences between the two are:
Any idea where I'm going wrong?
Hi Jamie! At first glance, I see one big issue here.
You shouldn't leave the numeric range filter undefined. Instead, make sure you specify Ticket Id as the attribute. That way, Insights knows how to apply the filter to the rest of the report. In this case, it would only allow tickets (by their ID) that return a 0 in the tag metric.
If you're still seeing odd behavior, even with # Tickets in the tag metric and Ticket Id in the report filter, then I recommend submitting a ticket to our support team. We may need to take a closer look.
I hope this helps! Happy reporting!
That's brilliant Amy, worked a treat, thanks again for your help.
I'm going to be a real pain though and ask one final question...is there a straightforward way to apply the tag filter to key metric widgets? My specific reports are accurate, but I like to have "Tickets Created Last Month" in bold at the very top as a headline, they don't allow quite the same customisation though.
I'm guessing if it is possible that it involves using a further custom metric that includes the nested tag filter, I did have a stab at that but am still getting the result including tickets "closed by merge". Working below, but I may be way off the mark:
Apologies Amy, I was messing around with the above new custom metric and it now appears to be working, although it still reads exactly the same...no idea what happened, but thanks anyway, I think I've solved it.
Hi Jamie! That's awesome! I'm glad it's working for you.
There is one odd behavior with nested metrics that may have had an impact here. When you nest a metric in a larger metric, Insights stores the full query of the nested metric at that time. It does not keep a live link to the nested metric.
This is great for cases where you delete a metric without realizing it's in use elsewhere. Insights can keep using the original query in any larger metrics without any problem, even if the metric itself is gone.
This is awkward for cases where you make changes to component metrics. Insights will still have the outdated version stored until you remove and re-add it in the larger metric (and save the change). That may have been what happened here, if you had an older version of the tag metric in your larger headline metric.
Happy reporting!
Hi Amy, that sound very like what I experienced, almost certainly that's the explanation.
Really, really appreciate your support with this, thanks again!
Hello Amy,
I would like to add more fields to my report and having some issues. My fields are broking down by departments so when a rep closes out a ticket they have to pick what department the end user is from. I would like to have a report that shows me all the fields I want in one report.
So something like below. Does this make sense?
Hi Andrew! It sounds like your tickets have a field for the department, which your agents fill in before solving tickets. Is that the case?
If so, you don't need to use tags to report on the field. You can just use the field itself. I recommend starting with something like this:
WHAT - # Tickets
HOW - Department (or whatever the field is called)
This will show you how many tickets have each value in the field. You don't need to make extra metrics. If you report on a field, you can also use ranking filters or find the event of the field changing. Tags can't do that.
In general, I recommend reporting on ticket fields whenever possible and minimize your use of tags. That will make reports easier to manage and more robust.
I hope this helps! Happy reporting!
Thank you Any. That worked
What if I want a metric to report on when two or more tags are present on a single ticket? For example, I want to report on the number of tickets that deal with Appointment and Questions as well as Appointment and Bugs? I tried this, but did not get the results I was hoping for:
SELECT IFNULL ((SELECT # Tickets WHERE Ticket Tag [Ticket Tag] = questions) AND (SELECT # Tickets WHERE Ticket Tag [Ticket Tag] = appointments),0)
I also tried SELECT IFNULL ((SELECT # Tickets WHERE Ticket Tag [Ticket Tag] = questions AND appointments),0)
I'm stumped and frustrated!
Hi Thomas! There are a couple picky issues here, but you're on the right track.
First, it looks like you used the Ticket Tag [Ticket Tag] Attribute Label, instead of the Ticket Tag Attribute. That will cause syntax issues. Make sure you're using the Attribute in this recipe.
Second, a single metric is good for OR logic, or to exclude a large group of tags at once. It's not ideal for using AND logic to find multiple tags on the same ticket.
If you're interested in AND logic, I recommend making separate filtering metrics for each tag:
You can put both of them in numeric ranges on the same report. That would find tickets that would be counted in both metrics, meaning the tickets have both tags. You can also combine them within one larger metric:
This copies the logic of multiple report filters: it only shows tickets that would be counted in both filtering metrics.
It may be possible to combine both tag filters into one metric without going through these setup stages, but it would be exceptionally complex at best. The relationship between ticket and tag data is a bit rigid. It's easier to work with small building blocks than to build everything at once.
I hope this helps! Happy reporting!
So I created the first metric, and now I'm trying to figure out how to use it. I'm confused by this:
How do you add the first "metric"? I'm not seeing it in any of the options and it doesn't work when I just type it in. If someone could email me, that would be very helpful. I have a feeling I'm going to have several questions!
Hi Emma! This is whichever metric you want to see. For example, if you want to look at full resolution times for tickets that do not have a closed_by_merge tag, the metric would look like this:
SELECT Full Resolution Time (hrs) [Mdn] WHERE (SELECT # Tickets with closed_by_merge tag BY Ticket Id) =0
(You need to create the # Tickets with closed_by_merge tag separately.)
This just means that you can nest a tag filtering metric in a larger metric. You can use that to compare tickets with and without a certain tag in the same chart.
I hope this helps! Happy reporting!
Thank you that does help! But I'm still struggling a little. I tried to create this metric:
Hi Emma! This gets tricky. The default satisfaction metrics are all based on the Satisfaction Survey Change dataset, which is connected to ticket updates. You can learn more about the different types of changes and updates in this article on the events model.
The issue is that tags are not connected to ticket events. Insights can't get directly from your "Internal Troubleshooting" tag to those satisfaction changes, so it won't be able to filter your results correctly.
At this point, you have a few broad options:
1 - Filter the report
Apply the tag filter as a numeric range filter on the report as a whole instead of within the metric. Those filters are applied in a different way, so it should work with your satisfaction metrics as-is. However, this means the entire report will have the same tag filter(s), so you can't compare results with and without a certain tag within the same report.
2 - Alternate ticket metric
Create an alternate % Satisfaction Score metric based on the Ticket Satisfaction Score attribute. This attribute shows the current satisfaction rating on the ticket. The metric could look something like this:
Once you have a metric like this, it should work in the metric / tag filter template from before. This allows you to report on the % Satisfied score and compare tags within one report. However, you would not be able to report on the rating event; you'd be reporting on the ticket as a whole.
3 - Connect tags to events
Tags and satisfaction events are both connected to tickets; they're just connected through different paths. It should be possible to define all the various data model relationships and put the two in the same metric at the same time.
However, this approach is exceptionally complicated and varies by report. It would also likely require a whole series of custom metrics to keep all the pieces in place, which is beyond what we can cover in support.
For now, I'd focus on the first couple options and see where they get you. If you have more specific questions at that point, I recommend sending in a ticket.
I hope this helps! Happy reporting!
Hi Amy Dee,
Yes! I was able to get #2 to work for me. I tried to submit a ticket, but the person who replied gave a different answer that wasn't helpful.
Is there a way to create a similar alternative metric for # Public Comments? It makes sense the way you did it for Satisfaction Score, but I can't figure it out for other metrics that aren't a %. I need to be able to report on # Public Comments for tickets with certain tags as well.
Hi Emma! That's good news! I'm glad you got the alternative satisfaction metric working.
The #2 option works for satisfaction scores, because tickets have their own satisfaction attribute separate from the ticket event version. That lets you combine them within one metric, because tags and tickets are directly linked.
The issue with # Public Comments (and pretty much all other update metrics) is that it doesn't have a separate ticket property. Comments are only recorded on ticket updates, so there is no simple way to connect comments and tags directly.
This leaves you with options 1 and 3. Option 1 is far simpler. You can use a numeric range filter on the report as a whole. Those filters interact with the report a different way, so they should work with the # Public Comments metric.
If you want to try comparing different tag filters with ticket events in the same chart, you need option 3 with a lot of complicated metrics.
For now, I recommend sticking with option 1, where the whole report uses the same tag filter(s). If you want to compare different tags, I recommend making separate reports and putting them beside each other on a dashboard.
I hope this helps! Happy reporting!
Hi Amy,
Thank you in advance.
I am having difficulty following the 2nd stage of this. I think you started to reference it in this comment but I am not following the #Ticket with your_tag portion of this.
I have created the initial metric to isolate the tag but no idea where I find the #Ticket with your_tag. I can find the metric created. Just not with the #Ticket.
Saz
Hi Saz! If you're referring to the "Nest the tag filter" option, # Tickets with your_tag is your custom tag-filtering metric from the start. I just used that title as a placeholder for the article.
It sounds like you gave it a different name, which is why you're not seeing it by that name in your list. That's totally fine. Just use the metric you created, with whatever title you gave it.
I hope this helps! Happy reporting!
Thanks Amy
Hi Amy,
I've followed all the steps but can't seem to get either method to work...
My customer metric seems to submit perfectly fine in the editor without any errors
However, when I try to filter on the metric following the steps I get an error (see flow below)
1. Set up metric
2. Add in How factor
3. Add numeric range filter with Ticket ID as attribute and custom metric as metric
Error that report cannot be pulled
Hi Nic! The metric is close, but one of the elements is from the wrong list. Ticket Tag [Ticket Tag] is for the attribute label. It's not the attribute itself. That's why it isn't doing anything right now.
Remove the Ticket Tag [Ticket Tag] piece, then replace it by going to Attributes > Ticket Tag. It won't have any extra layers or brackets.
(Fun tidbit for future reports: attribute labels allow you to work with text strings, which you can use for things like reporting on nested drop-down fields.)
I hope this helps! Happy reporting!
Please sign in to leave a comment.