Reporting on ticket tags

Have more questions? Submit a request


  • Nic Lowden

    Thanks Amy! I've cleared that up but am running into more issues. 

    I want to filter for the following conditions:
    1. Remove tickets that have both call and tier_1 tags
    2. Remove tickets that have no manual response from the agent and have certain automated tags (low_star_rating, auto generated by chats etc.)

    Seems like this is proving to be super complex with the custom metrics as this is a combination of ANDs and ORs within one search...!

    Would really appreciate your help on this

  • Amy Dee

    Hi Nic! That is a lot of moving parts! Assuming your "certain automated tags" part means any one of a list of tags, and assuming you want all tickets that meet 1 or 2, then I'd start with an approach like this:

    1. Create a tag filtering metric for Ticket Tagcall 
    2. Create a tag filtering metric for Ticket Tagtier_1 
    3. Create a tag filtering metric for Ticket Tag IN (low_star_ratingauto-generatedchats, etc)
    4. Use the nested metric approach from the article above to combine them in a metric with AND and OR logic:

    SELECT ticket metric WHERE
    ( (SELECT call tag BY Ticket Id)=1 AND (SELECT tier_1 tag BY Ticket Id)=1 )
    ( (SELECT # Replies BY Ticket Id)=0 AND (SELECT auto tags BY Ticket Id)=1 )

    This should find tickets with EITHER the call and tier_1 tags OR 0 replies and at least one auto tag. (A "reply" is a public comment by an agent after ticket creation.)

    If you want to use this to exclude matching tickets, you could wrap SELECT IFNULL((metric), 0) around it, then filter your report for tickets that return a 0. This part would be just like the tag filtering steps above but with a much more complex filtering metric.

    Some tips: Be very careful with parentheses when you combine AND and OR logic within a metric. Otherwise, Insights may group elements in unexpected ways. Also, this type of metric will be highly resource-intensive, so you should try to keep the report is focused on small sets of tickets at a time.

    Please note - I'm providing this template for demonstration purposes. I can't guarantee it for all use cases, and I strongly advise you to audit your results.

    I hope this helps! Happy reporting!

  • John Ferreira



    I am getting an error on my syntax but I can not find the problem.


    Can you help me?



    Thank you,



  • Amy Dee

    Hi John! It looks like you typed in the name of your tag. You need to select it from the elements list on the right. It will be under Attribute ValuesTicket Tag. When you add it as an element, it will appear orange in the metric editor.

    I hope this helps! Happy reporting!

  • Jesper

    Hi Amy!

    I am trying to nest the tag filter in a custom metric as described in the article because I want several different metrics in the same report. However I'm always running in to the "Report not computable due to improper metric definition" error. What's causing it is that I want to group the result by Updater or Ticket Assignee (Historic) in the How-section.

    It's kind of weird, because if I choose WHAT: # Tickets solved, HOW: Updater, FILTER:Ticket Id where MyTagFilterMetric is equal to 1, it works fine.

    But as soon as I create the metric "SELECT # Tickets Solved WHERE (SELECT MyTagFilterMetric BY Ticket Id)=1" and group by Updater, I get the error message.

    I guess these setups aren't equivalent in every way, but since the connections between the datasets seems to exist, I think it should somehow be possible to create th report with the tag filter nested as well. I noticed the caveat about the template varying a bit depending on the metric, but I've tried all kinds of different variations now and can't get it to work so I'm hoping for some guidance on this!

    Thanks in advance,


  • Amy Dee

    Hi Jesper! The issue here is that tags are not connected to events. They're only connected to the ticket as a whole, so they only respond to ticket-level properties.

    When you put a numeric range filter on the report, it applies before the rest of the content. With tag reporting, this means Insights uses the report-level filter to find tickets with (or without) the specific tag. Once Insights has a list, it can work with individual events in those tickets.

    You can report on events and tags, as long as the two are kept completely separate.

    Once you nest the tag filter into the metric, Insights needs to process those filters along with the rest of the calculations and slices. That moves the entire report up to whole tickets and ticket-level properties. That's why your report is throwing an error. Updater is an update property, and it is not compatible with ticket tags.

    Ultimately, if ticket tags (or any other "BY Ticket Id" aggregations) appear anywhere in the metrics under WHAT, then event properties (like Updater and Date (Event)) will no longer work under HOW.

    At this point, I recommend taking a quick step back and reviewing your goals with this report. Do you truly need the Updater, or would it make sense to use the Ticket Assignee instead? The assignee applies to the ticket as a whole, so it would work with ticket tags in the metrics. If you do need the updater, though, you'll need to move tag filters from WHAT to FILTER, and likely put several smaller reports on a dashboard.

    I hope this helps! Happy reporting!

  • Jesper

    Alright, thank you Amy. I need the assignee at the time of the event. Historic assignee would have been okay but the regular Ticket assignee doesn't work. I guess I'll just have to create several different reports then.

    These tags I'm trying to report on are generated from a multi-select field. So another workaround would probably be to trigger values in another (hidden) ticket field and base the report on those field values. Because those regular ticket fields are connected to events as I understand it. But it's an inconvenient and anoying workaround plus I won't be able to look at data retroactively, just the data gathered after the creation of those triggers. So I guess what I'm pushing for is the possibility to use multi-select fields directly in these instances. It's probably a related issue.

    Anyway, thanks a bunch for your reply!

  • Carla

    Hi Amy,

    Please could you let me know why the set up underlined in red doesn't work?

    This is the metric I am referring to.

  • Brett - Community Manager

    Hi Carla,

    There isn't anything that stands out from the screenshot you provided so I'm going to generate a ticket on your behalf and pass over to our Customer Advocacy team for further assistance.

    You'll receive a follow-up email shortly stating your ticket has been created.


  • Anastazie Sedlakova


    want to create report on tag usage, but it doesn't seem to filter. For different tags it shows exactly the same numbers when I use filtering with custom metric (Ticket Id where macro_test1 is equal to 1).  If I use custom metric (Ticket Id where macro_test1 is equal to 0) and where I get following error: No data match the filtering criteria.

    Can you please help me to figure out where is the problem?




    What: # Tickets Solved

    How: Date (Ticket Solved)

    Filter: 1) Ticket Id where macro_test1 is equal to 1

    2) Date (Ticket Solved) is the last 32 days

    macro test metric contains following MAQL query:

    SELECT IFNULL((SELECT # Tickets Solved WHERE Ticket Tag = automat), 0)


  • Dan Ross

    Hey Anastazie,

    It looks like you're using # Tickets Solved as your metric definition, instead of # Tickets as denoted in the article above.

    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.

    Once you get the # Tickets, you can then add report filters to filter them down by status of the tickets.

  • Nick


    My company has a large number of tags to track, so global metrics showing tickets from YesterdayLast 7 Days, and Last 30 Days are super useful, rather than creating tag-specific metrics. I've created these and they work like a charm... except for one tag!

    While these global metrics are accurate for all other tags, and confirmed via search in Zendesk, for whatever reason this one tag is showing values that are wildly incorrect - more than double the actual value.

    One example of this is in our Yesterday metric, seen below:

    This should return a value of 9 for the tag in question, but instead returns a value of 23.

    Also, our Last 7 Days metric seen below:

    This should return a value of 67 for this tag, but instead returns a value of 171

    Given the the metrics return the correct values on all other tags I'm not quite sure what could be causing the issue.

    Help! (and thanks in advance!)


  • Amy Dee

    Hi Nick! At first glance, the biggest difference between your custom metrics and the default # Tickets metric is the Ticket Tag Deleted Flag condition. The default metric excludes deleted tags, while your custom versions do not. If your workflow involves tags being added and later removed, it could lead to your metrics skewing high.

    Try replacing the SELECT COUNT(Ticket Id, TicketTagId) WHERE Ticket Status <> Deleted portion with just SELECT # Tickets WHERE Date (Ticket Created)... That should limit your report to tickets and tags that have not been deleted.

    I hope this helps! Happy reporting!

  • Nick

    Cheers, Amy! That did the trick. Thanks so much for the help!

  • Anoop Mehta

    Hi Amy,

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

    I am in the process of setting up custom metrics for all my 'ticket categorization' tags. 

    I am running into an issue, when I go to look up <your_tag>, allot of them are not showing up. Some of them are showing up. I figured this is because the tag will only show up as an attribute once it has been added to a ticket. That being said, I created a test ticket and added all the tags I wanted to create metrics for. 


    Still, only a handful are showing up instead of all of them. 

    Is there a delay from when the tag is added on a case to when it will show up as an attribute I can select from Ticket Tag?

  • Amy Dee

    Hi Anoop! Insights is not a real-time platform. There will be a delay between an event on a ticket and that event syncing to Insights.

    For Professional accounts, Insights syncs once per day. For Enterprise syncs, Insights syncs hourly (based on the time of the last sync, so they're not perfectly even). If you recently added tags to your tickets, give the data a chance to sync before you check the metrics.

    I hope this helps! Happy reporting!

  • Anoop Mehta

    Thanks Amy - that helped a bunch!

  • Christopher C.


    I am trying to build a report to show our agents' macro usage per week.


    # Tickets

    # Tickets Solved

    # Custom Metric  (# Tickets / # Tickets Solved) to get percentage of ticket solved vs ticket solved with macro


    # Ticket Assignee


    Ticket Tag is... (All Ticket tags associated with a macro) over 50 tags

    Week (Mon-Sun) (Ticket Solved) is Last Week


    But I still feel like the outcome is not correct. Any ideas how I can improve my report?


    Kind Regards,



  • Amy Dee

    Hi Chris! It looks like you ultimately want to see how many tickets are solved with one of those macro tags, compared to the total number of tickets solved. Is that correct?

    If so, you'll need to start by building a tag-filtering metric, then nesting it in your report metrics. A Ticket Tag IS filter on the report is inconsistent at best, especially when you mix and match metrics like this. (# Tickets Solved does not connect to tags, so it will break your filtering.) It's better to be explicit within the metrics.

    Start with a metric matching the recipe above:

    • SELECT IFNULL((SELECT # Tickets WHERE Ticket Tag IN (macro_tag1macro_tag2, [etc])),0)

    If all your macro tags start or end with the same string (like "macro"), you can use the text string in your metric instead of selecting each individual value. This recipe uses the same technique: Reporting on multi-select fields with tags.

    From there, you can create comparison metrics like this - 

    • SELECT( (SELECT # Solved Tickets WHERE (SELECT macro filter metric BY Ticket ID) =1) / # Solved Tickets )

    This should show you solved tickets with at least one of the macro tags divided by all solved tickets. Since the numerator and denominator use the same base metric, it should give you more consistent results in the report.

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

    I hope this helps! Happy reporting!


Please sign in to leave a comment.

Powered by Zendesk