Plan requirement
| Subscription | Suite Professional or higher, Explore Professional or higher |
| Access | Admin |
Explore can report on tags, with two behaviours that make the numbers wrong if you do not know about them.
Build the report
- Open Explore and create a report on a ticket dataset.
- Add a metric counting tickets.
- Add the tag attribute as a row.
- Filter to the tags you care about, rather than showing all of them.
The two behaviours
A ticket with three tags counts three times
Because tags are a list, not a single value. Add up a tag breakdown and the total exceeds your ticket count. That is correct behaviour and a wrong conclusion if you read it as a share of tickets.
There is a direct fix, so there is no need for a workaround. Use the D_COUNT aggregator instead of COUNT: D_COUNT counts each ticket once however many tags it carries, while COUNT lets it be counted again for each one.
Beyond that, filtering to one set of mutually exclusive tags, or using a field, are the other routes.
Unfiltered means everything
A report on all tags shows every tag your account has ever used, including typos and abandoned schemes. Always filter to the ones you are asking about.
Why a field is usually better
A drop-down field holds one value per ticket, so the numbers add up and the list is fixed. Anything you report on regularly should be a field, with tags reserved for marking that something happened.
If a tag report is important enough to be on a dashboard, that is the signal to make it a field.
What tags do report well
Yes-or-no questions. How many tickets were escalated, how many got a reminder, how many came through a particular route. Those are exactly what tags are for.
One limit to design around: a ticket can carry any number of tags, but the tag field holds at most 5,096 characters in total. Long, descriptive tag names are what gets you near that, not the count.
Comments
0 comments
Article is closed for comments.