Reporting on tags

Tags are reportable and awkward. Selecting several in the Filters panel multiplies your metric, which is the trap here.

Tags are reportable and awkward. A ticket can carry many, so selecting several in the Filters panel multiplies your metric, which is the trap here.

Report on them

1. Open a report on a dataset that exposes tags: Support - Tickets, Support - Updates history, Support - SLAs, Guide - Knowledge Capture, Answer Bot - Article Recommendations, Talk - Calls, or Chat - Engagement.
2. Add the tag attribute as a grouping, or filter on a tag. The one you usually want is Ticket tags; there are also Requester tags, Assignee tags, Organization tags and several more, and they answer different questions.
3. Compare the total against the ticket count.

The multiplication, stated exactly

This is the documented behaviour and it is worth quoting to whoever queries your number: selecting multiple tags in the Filters panel multiplies the report's metric values by the number of matching tags.

So a ticket carrying three of the tags you selected is counted three times. Not a rounding difference, a multiple. One tag in the filter is a clean question; several is a number that needs explaining on the report itself.

Use the tag functions instead

These express what people usually mean by "tickets tagged X or Y" without the filter panel doing its multiplication.

A breakdown by tag is not a breakdown

"How many tickets carry this tag" is a clean question. "Break my tickets down by tag" is not, because the categories overlap by design.

Where you want a clean breakdown, use a drop-down field. That is what fields are for.

Tags are only as good as the tagging

Applied by triggers and macros, they are consistent. Applied by agents choosing from memory, they are not: the same subject ends up under three spellings, and the report undercounts all of them.

Look at the list before you build anything. In Admin Center, click Objects and rules, then Tickets > Tags. You will usually find near-duplicates, and dealing with them is a prerequisite rather than an improvement.

Tags outlive their deletion

Three things make a tag harder to retire than it looks.

• Tags cannot be deleted from closed tickets. Whatever you clean up, the closed history keeps them.
• Deleted tags keep appearing as suggestions until the closed tickets containing them retire out of the list and the tag has not been used again for 60 days.
• Deleting tags from tickets does not remove references to them in automations, macros and triggers, so a rule can quietly start applying a tag you thought was gone.

Trend reports on tags need all three in mind, and a clean-up needs the business rules checked as its last step rather than its first.

When a tag deserves promotion

If you report on one tag regularly, it should probably be a field. Fields are validated, single-valued and reportable without any of the caveats above.

See also

• Reporting on custom fields
• Tags on users and organisations
• Adding filters