Zendesk Tag Co-Occurrence Report

Most tag reports answer one question: which labels appear most often?

That is useful, but it is incomplete. Support problems rarely arrive as one clean tag. They arrive as combinations: billing plus bug, onboarding plus permissions, refund plus delay. A tag co-occurrence report helps you see those combinations so you can find the patterns a single-tag dashboard hides.

This guide shows how to build the report, when to use it, and how to connect it to the support metrics dashboard, Zendesk Tags Analysis Guide, and Zendesk Category Distribution Report.

What this report should answer

A useful tag co-occurrence report helps you answer:

which tags appear together most often
which pairs are associated with slow resolution time, high reopen rate, or unusual volume
whether one issue type is clustering inside one product area or customer segment
whether your taxonomy is too fragmented to describe problems cleanly

For the definition, see tag co-occurrence.

Why tag co-occurrence matters

Single-tag reporting is good for broad patterns. Co-occurrence is what turns it into diagnosis.

For example:

bug + checkout tells engineering more than bug alone
billing + refund tells operations more than billing alone
permissions + onboarding tells success more than onboarding alone

The combinations reveal context. They show which issue categories overlap, which workflows compound, and where the real support drag is hiding.

This is especially helpful when basic tag views already tell you what is common but still do not explain why a queue feels harder than normal.

How to build the report

1. Start with a clean tag set

Co-occurrence reporting becomes useless fast if the taxonomy is noisy.

Before building the report, clean up:

duplicate tags
tags used once or twice with no clear purpose
internal workflow tags mixed with issue tags
inconsistent naming for the same concept

If the underlying labels are messy, the pair analysis will only make the mess look smarter.

2. Identify the tag families you want to compare

The best co-occurrence reports usually combine different tag types, such as:

issue type
product area
root cause
customer segment
workflow outcome

Pairs are more useful when they connect different dimensions of the same ticket instead of repeating near-synonyms.

3. Pull ticket-level rows

Zendesk Explore is strong for standard tag breakdowns, but co-occurrence often requires ticket-level extraction because one ticket can carry several tags.

Use one of these approaches:

export ticket rows with their tag sets and calculate pairs outside Explore
create a saved analysis in your reporting stack that normalizes tags into pairs
use TicketBoard or a warehouse model if you already centralize support data

The goal is simple: for each ticket, count every meaningful tag pair once.

4. Rank by frequency first

Start with a table of the most common pairs.

That gives you the basic map of what combinations dominate the queue. From there, add outcome metrics so the report becomes operational instead of descriptive.

5. Add outcome context

Once you know the common pairs, review them beside:

ticket count
median resolution time
reopen rate
CSAT where available

This tells you whether a pair is merely common or also unusually painful.

How to interpret the patterns

One pair dominates both volume and slow resolution

This is usually your strongest candidate for intervention.

If a combination is common and slow, it is often exposing one recurring workflow that support, product, or documentation should fix directly.

A pair is low volume but extremely high pain

Do not ignore it, but do not overreact either.

Some co-occurrence pairs describe rare edge cases. The important question is whether the pair signals a strategic customer problem, a revenue risk, or a broader process weakness hiding under low volume.

This often means one product area or workflow is interacting badly with several issue types. The fix may belong with the shared root rather than each pair individually.

Co-occurrence keeps exposing near-duplicate tags

That is a taxonomy problem.

If several pairs are really the same issue under different labels, clean the tag system before you trust the trend.

Common mistakes

Running pair analysis on messy tags. Taxonomy quality comes first.
Looking only at the most frequent pairs. Some high-pain pairs matter more than high-volume ones.
Comparing pairs without ticket count. Rare combinations can distort decisions.
Treating co-occurrence as proof of causation. The pair tells you where to investigate, not what caused the issue.
Mixing internal workflow tags with customer-problem tags. Keep the report focused on meaningful operational signals.

What to do when one pair stands out

Read the tickets behind the pair.
Check whether the combination maps to one repeatable scenario.
Decide whether the fix belongs in product, routing, documentation, or training.
Simplify the taxonomy if the pattern is really a labeling issue.
Re-track the pair over the next few weeks.

The right outcome is not a prettier tag chart. It is a narrower list of issue combinations the team can actually act on.

Where this report fits

Tag co-occurrence works best beside:

Those views tell you what the queue is made of, while co-occurrence tells you which issue combinations deserve attention first.

FAQ

Can Zendesk Explore do tag co-occurrence natively?
Not cleanly in most setups, because one ticket can have many tags and pair analysis usually needs ticket-level transformation. Explore is still useful for the baseline tag views that tell you where to start.

How many tags should we include?
Start with your most important governed tags. A smaller, cleaner set is more useful than throwing the entire taxonomy into the report.

Is this only useful for large teams?
No. Small teams often benefit more because a few recurring issue combinations can consume a disproportionate share of weekly effort.

Find the Zendesk tag combinations that a single-tag dashboard cannot explain - start free