D_COUNT vs COUNT in Zendesk Explore
D_COUNT vs COUNT in Zendesk is the single most common cause of a report that looks plausible and is wrong. Two minutes to understand, and it'll save you an argument.
D_COUNT vs COUNT in Zendesk, in one line
COUNT(Tickets) counts values, duplicates included
D_COUNT(Tickets) counts distinct values, each one onceThat's the whole rule. Everything below is consequences.
In Explore, an aggregator sits on every metric, and you choose it. Ticket-based metrics commonly default to a distinct count, because in most contexts the question "how many tickets" means "how many different tickets". When you write your own metric, the aggregator is yours to pick, and picking the wrong one is silent.
It's silent because both answers are numbers, both are the right order of magnitude, and neither throws an error. The report just quietly overstates.
Where they diverge: one row isn't one ticket
COUNT and D_COUNT return the same answer whenever every underlying row is a separate ticket. That's why a plain volume report works fine either way, and why people conclude the distinction does not matter.
It matters the moment a single ticket produces more than one row. That happens far more often than you'd think.
In all four cases, COUNT is counting rows and calling them tickets.
Getting it wrong, example one: tickets by tag
You build volume by tag for last month. Your tag list shows billing, refund, urgent and vip. The chart totals 1,400 tickets. Your view count says 900.
Nothing is broken. Your average ticket carries about one and a half tags, and COUNT counted the tag rows. Switch to a distinct count of tickets and the bars change, because now a ticket tagged both billing and refund contributes one to each bar instead of inflating the total.
Here's the part that trips people up even after they fix it. With D_COUNT, the bars still don't sum to 900, and they never will, because that ticket is legitimately in two bars. The bars are correct and the sum is meaningless. Do not add them up in a slide.
Getting it wrong, example two: the Updates dataset
You want tickets that were reassigned, so you go to Support Updates, filter to assignee changes, and count.
With COUNT you get the number of reassignment events. With D_COUNT you get the number of tickets that were reassigned at least once. Those are different questions and both are legitimate. The failure is labelling one with the other name.
A ticket bounced between four agents is one ticket and three reassignments. If your slide says "42 tickets were reassigned" and the metric counted events, the real number of affected tickets might be fifteen. Somebody will eventually check, usually in the meeting.
Rule of thumb for that dataset: if the sentence starts with "how many tickets", you want a distinct count. If it starts with "how many times", you want COUNT.
Getting it wrong, example three: agents per ticket
A nice metric, and a good demonstration of the distinction being the whole point of the report.
Count distinct agents who commented on each ticket, then average it. That's a genuine measure of how much passing around your process does, and it needs a distinct count in the middle or it just measures comment volume.
Build it with COUNT and you get average comments per ticket, which is a different and much less interesting number. The report will look fine. The insight is gone.
Two quieter differences, then a rule
Nulls. Counting a field that's empty on many tickets behaves differently from counting tickets, and a metric that counts a sparsely populated custom field will undercount badly. If your number is much smaller than expected, check whether you're counting a field rather than a record.
Cost. Distinct counts are more expensive to compute. On a big account with several distinct counts and a wide date range, that's the difference between a report that loads and one that times out. If a report is slow, look here before you blame the dataset.
Filters interact with both. A filter applied to the report changes which rows survive before the aggregator runs, so adding a tag filter to a COUNT-based metric can move the number in a direction that feels arbitrary until you remember you are counting rows. Distinct counts are much more stable under filtering, which is one more reason they are the safer default for anything ticket-shaped.
The rule that keeps you out of trouble: decide whether the thing you're counting is an event or a record. Events take COUNT. Records take D_COUNT. Then check the total against a number you already trust, because a report that disagrees with your view counts by fifty per cent is telling you something before anybody else has to.
Frequently asked questions
Which Explore aggregator should be the default?
D_COUNT, in most cases. The Zendesk Explore aggregator you pick decides whether one row means one ticket, and D_COUNT counts distinct tickets rather than rows.
What does D_COUNT do in Zendesk Explore?
It counts distinct values, so a ticket appearing on several rows is counted once. COUNT counts every row.
Why do my Explore totals not match the sum of the rows?
With a distinct count and a one-to-many breakdown like tags, a ticket can legitimately appear in more than one row. The total is distinct across all of them, so the parts won't add up.
When should I use COUNT instead of D_COUNT?
When you are counting events rather than records: reassignments, comments, updates, satisfaction responses.
Why is my Explore report so slow?
Distinct counts are computationally expensive. Several of them over a wide date range is a common cause of a report that won't load.
How do I check which aggregator a metric uses?
Open the metric in the report builder and look at its aggregator setting. Do not assume the default is the one you want.
Counted once, or counted twice
Explore can count a ticket once. It cannot tell that two tickets are the same conversation. Ticket Merger can.
Start free trial14-day free trial. No credit card required.