Reporting on ticket tags

Have more questions? Submit a request


  • Jesse Dacumos

    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. 

  • Tricia Johns

    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! 




  • Daniel Yousaf

    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 :)

  • Josh Rosenthal

    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!

  • Mikael Hellström


    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".

    - satisfaction score

    - ticket tag

    - 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.


  • Amy Dee

    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!

  • Jamie McLaren


    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:

    1. "No data match the filtering criteria".  I suspect that the attribute is wrong (Ticket ID isn't relevant), but don't know what to select here.
    2. Need some clarification please, this involves setting up an additional custom metric, which references the original one created, is that correct?  I could do with some advice on implementing this in my own scenario, totally stuck with it.

    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.

  • Amy Dee

    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!

  • Jamie McLaren

    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:

    1. Chart type (line graph vs. donut chart)
    2. The working chart has 2 attributes defined, the broken one only 1 of these

    Any idea where I'm going wrong?

  • Amy Dee

    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!

  • Jamie McLaren

    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 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:

  • Jamie McLaren

    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 idea what happened, but thanks anyway, I think I've solved it.

  • Amy Dee

    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!

  • Jamie McLaren

    Hi Amy, that sound very like what I experienced, almost certainly that's the explanation.

    Really, really appreciate your support with this, thanks again!

  • Andrew Caruso

    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?




  • Amy Dee

    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!

  • Andrew Caruso

    Thank you Any. That worked 

  • Thomas

    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!


  • Amy Dee

    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:

    • SELECT IFNULL((SELECT # Tickets WHERE Ticket Tagappointments),0)
    • SELECT IFNULL((SELECT # Tickets WHERE Ticket Tag = questions),0)

    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:

    • SELECT IFNULL((SELECT # Tickets WHERE (SELECT Tickets with appointments tag BY Ticket Id)=1 AND (SELECT Tickets with questions tag BY Ticket Id)=1),0)

    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! 

  • Emma MacDonald

    So I created the first metric, and now I'm trying to figure out how to use it. I'm confused by this: 

    • Tag is presentSELECT metric WHERE (SELECT # Tickets with your_tag BY Ticket Id)=1 

    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!

  • Amy Dee

    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!

  • Emma MacDonald

    Thank you that does help! But I'm still struggling a little. I tried to create this metric: 

    but it doesn't seem to be working. It won't let me create a report on it. Do you see something obvious wrong with it? 
    And when you say "You can use that to compare tickets with and without a certain tag in the same chart," would I need to create another metric that is Satisfaction score for tickets without that tag? 
    If it would be easier for me to submit a ticket, let me know! 
  • Amy Dee

    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:

    • SELECT( (SELECT # Solved Tickets WHERE Ticket Satisfaction ScoreGood) / (SELECT # Solved Tickets WHERE Ticket Satisfaction Score IN (GoodBad)) )

    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!

  • Emma MacDonald

    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. 

  • Amy Dee

    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!

  • Saz Ehibor-Smith

    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.


  • Amy Dee

    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!

  • Saz Ehibor-Smith

    Thanks Amy

  • Nic Lowden

    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





  • Amy Dee

    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 AttributesTicket 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.

Powered by Zendesk