Zendesk Explore Calculated Metrics: Formulas That Work

Last updated: August 23, 2026

Zendesk Explore Calculated Metrics

Every Zendesk reporting project hits the same wall. You know the number you want, Explore has hundreds of built-in metrics, and none of them is the one you need. Tickets solved within an hour, backlog older than a week, escalations per account, the share of work arriving through one form — all of it is one formula away, and the formula editor is where most support ops work quietly stops.

The syntax is small. There are maybe six things to learn, and the reason calculated metrics feel hard is not the language but the three decisions you make before you type anything: metric or attribute, standard or fixed, and which aggregator. Get those wrong and you will get a valid formula that returns a confidently wrong number.

This guide covers the decisions first, then the syntax, then the errors that cost the most time.

What this guide gets you

  • A rule for choosing between a calculated metric, a calculated attribute, and a result calculation
  • Working formulas for the four patterns that cover most real requests
  • The aggregator rules that decide whether your number is right
  • How to fix the formula errors Explore reports most often
  • How to keep a calculation library from becoming unmaintainable

This is the mechanic behind most of the reports in the support metrics dashboard. If you have ever read one of our metric guides and hit a step that says “create a calculated metric,” this is that step explained properly.

First decision: metric, attribute, or result calculation

This is the decision people get wrong, and it produces the most confusing symptom — a report that looks plausible and disagrees with the ticket list.

You want Use Why
A new number to measure Standard calculated metric Metrics go in the Metrics panel and get aggregated
A new way to group or label rows Standard calculated attribute Attributes go in Rows, Columns, or Filters
Aggregation at a level the report layout does not use Fixed calculated metric or attribute Locks the calculation to a chosen level
Maths on numbers the report already calculated Result metric calculation Runs after aggregation, on displayed results

The practical test: if the answer to your question is a count, a duration, or a rate, you want a metric. If the answer is a bucket, a label, or a category you want to split by — “over 3 days” versus “under 3 days”, “enterprise” versus “self-serve” — you want an attribute.

The standard-versus-result distinction matters more than it looks. Standard calculations run at row level, before aggregation. Result calculations run after aggregation, on what the report already produced. A ratio of two metrics is almost always a result calculation, because you want total divided by total, not the average of a row-by-row division. Dividing before aggregating is the single most common cause of percentages that do not match a hand count.

All of these live in the Calculations menu (the calculator icon) in the right sidebar of the report builder.

The syntax, in one pass

Six rules cover nearly everything.

1. Fields go in square brackets. [Ticket ID], [Ticket channel], [Assignee name].

2. Text values go in quotes and must match exactly. "Email" is not "email". Click an attribute in the sidebar to see its real values rather than guessing — case and spacing are the most common silent failure.

3. Conditions follow IF / THEN / ELSE / ENDIF. Every IF needs an ENDIF. Omitting ELSE is allowed and returns empty when the condition fails, which is usually what you want for a conditional count.

IF ([Ticket channel]="Email") THEN [Ticket ID] ENDIF

4. Use ELIF instead of stacking ELSE IF. Chained conditions get unreadable fast; ELIF keeps them flat.

5. Wrap metrics in VALUE() when you need their number. Attributes carry values; metrics need to be evaluated before you can compare them.

IF (VALUE(Full resolution time (min)) < 60) THEN [Ticket ID] ENDIF

6. Build formulas with the field picker, not the keyboard. The Select a field control inserts exact names. Explore validates as you type and shows a green check when the syntax parses — note that a green check means “this parses,” not “this is correct.”

Four patterns that cover most requests

Pattern 1: conditional count

The workhorse. Count only the tickets that meet a condition, so you can trend that subset like any other metric.

IF ([Ticket channel]="Email" AND [Ticket priority]="Urgent")
THEN [Ticket ID]
ENDIF

Set the aggregator to D_COUNT so each ticket counts once. Name it for what it counts — Urgent email tickets, not Metric 1.

Pattern 2: threshold count

“How many tickets beat our target?” This is the basis of every internal SLA-style report you build without an SLA policy.

IF (VALUE(First reply time - Business hours (min)) <= 60)
THEN [Ticket ID]
ENDIF

Two things to get right. Use the business-hours variant if your target is a working-hours promise — see Zendesk business hours reporting for why this changes the number so much. And decide explicitly what happens to tickets with no first reply yet: they are NULL, they fail the condition, and they vanish. If “no reply yet” should count as a miss, count it separately rather than assuming the metric handles it.

Pattern 3: bucketing attribute

Turn a continuous number into groups you can put in Rows. This is an attribute, not a metric.

IF (VALUE(Unsolved tickets age (days)) < 1) THEN "1 - Under a day"
ELIF (VALUE(Unsolved tickets age (days)) < 7) THEN "2 - 1 to 7 days"
ELIF (VALUE(Unsolved tickets age (days)) < 30) THEN "3 - 7 to 30 days"
ELSE "4 - Over 30 days"
ENDIF

Number your labels. Explore sorts attribute values alphabetically, so unnumbered buckets sort as “1 to 7 days, Over 30 days, Under a day” and every chart built on them reads backwards. This is the cheapest formatting habit in Explore and almost nobody does it on the first attempt.

Pattern 4: rate as a result calculation

A percentage is division of two aggregates, so it belongs in a result calculation, not a standard metric.

Add both counts to the report — say Urgent email tickets and Tickets — then create a Result metric calculation:

(Urgent email tickets / Tickets) * 100

Now the number is correct at every level of the report, including totals. Build the same thing as a standard calculated metric and the total row will be an average of ratios, which is not a ratio.

Aggregators decide whether your number is right

A formula can be perfect and still return the wrong answer because of the aggregator. This is the part that separates a working report from a trusted one.

Aggregator Use for Watch out for
COUNT Counting every recorded value Double counts a ticket that matches twice
D_COUNT Counting unique objects — tickets, users, organizations The default choice for ticket counts
SUM Totals of durations and database-counted metrics Skewed by outliers
AVG Arithmetic mean Skewed by outliers; usually the wrong default
MED Median The better default for durations
VALUE Extracting a metric’s value inside a formula Required in most conditions

Two rules worth internalising:

Use D_COUNT for ticket counts. COUNT and D_COUNT agree until a ticket can appear more than once — which happens the moment you group by an attribute that has multiple values per ticket. Tags are the classic case: group tickets by tag and the column adds up to more than your ticket count, because a ticket with three tags lands in three rows. That is not a bug, and it is also not a number you should put in a board deck without a footnote. See Zendesk tag coverage rate for how to handle it.

Prefer MED over AVG for durations. One ticket that sat open over a holiday weekend will move an average and not a median. Our reasoning is in why median beats average for support metrics, and Explore already defaults several duration metrics to median for exactly this reason.

When the report layout fights the calculation

Some questions need a number calculated at ticket level and then displayed at group level. “Tickets that were reassigned more than twice” is one: reassignment is counted from update-level events, but the question is about tickets.

That is what ATTRIBUTE_FIX is for. It pins the aggregation to a level you name, regardless of what the report has in Rows.

IF (ATTRIBUTE_FIX(COUNT(Group assignments), [Ticket ID]) > 2)
THEN "Bounced repeatedly"
ELSE "Normal routing"
ENDIF

If Explore tells you that a metric “can’t be used” in a calculated attribute and suggests ATTRIBUTE_FIX or ATTRIBUTE_ADD, this is what it is asking for. The error is telling you the truth: you asked for an aggregate inside something that runs per row, and you need to state which level the aggregate belongs to.

The errors you will actually hit

Symptom Cause Fix
“Add an aggregator” Bare metric name in a formula Wrap it: SUM(...) or VALUE(...)
Aggregator not allowed on this metric Metric already contains an aggregator Use VALUE, or change the inner aggregator
Can’t use COUNT here — use ATTRIBUTE_FIX Aggregate inside a row-level calculation Wrap in ATTRIBUTE_FIX with an explicit level
“Calculation is referencing itself” Formula includes the metric you are editing Duplicate the source metric under a new name
Green check, empty report Condition never matches Check exact spelling and case of quoted values
Rows of 0 and NULL Calculated metrics return all rows by default Add a metric filter starting at 1
Total does not match the parts Ratio built as a standard metric Rebuild as a result calculation
Buckets sort wrongly Alphabetical sorting of labels Prefix labels with 1 -, 2 -, 3 -

The last three are the expensive ones, because the report runs, looks finished, and is wrong. Everything above them just fails loudly.

Common mistakes

  • Dividing before aggregating. Rates belong in result calculations. A standard calculated metric that divides row by row produces a total that is an average of ratios.
  • Guessing attribute values. "Web Form" versus "Web form" returns an empty report with no error. Click the attribute and read the real values.
  • Using COUNT where D_COUNT belongs. Silent inflation as soon as you group by tags or any multi-value attribute.
  • Leaving AVG on duration metrics. Outliers do the talking.
  • Punctuation in calculation names. Quotes, parentheses, and brackets in a metric name break formulas that reference it later. Keep names plain.
  • Forgetting NULLs are not zeros. A ticket with no first reply is absent from a threshold count, not a failure in it.
  • Rebuilding the same calculation per report. Six near-identical Solved under 1h metrics will eventually disagree, and nobody will know which one the exec deck used.
  • Ignoring the business-hours variant. Any duration threshold that reflects a promise to a customer should match the clock that promise was made on.

Keeping a calculation library maintainable

Calculated metrics accumulate faster than dashboards. Four habits keep them usable:

  1. Name for the definition, not the requester. Solved within 1h business hours beats Priya SLA metric.
  2. Prefix by domain — SLA:, CSAT:, Backlog: — so the list stays browsable at fifty entries.
  3. Write the definition down outside Explore, next to the metric that uses it. The formula records what it does; only you can record why the threshold is 60 minutes.
  4. Review quarterly and delete. Unused calculations are not free: they are future disagreements about which number is real. This pairs with the audit in the Zendesk Explore dashboard migration checklist.

If your library is growing because Explore cannot answer routine questions without a formula, that is worth noticing on its own. Most of the calculations teams build repeatedly — backlog aging, reply-time thresholds, per-account load — are metrics a purpose-built support dashboard reports without a formula editor.

Where these calculations get used

FAQ

Do I need a specific Explore plan? Creating reports and calculations requires Explore Professional or Enterprise. On Lite you can view prebuilt dashboards but not build calculations.

What is the difference between a standard and a fixed calculation? Standard calculations evaluate row by row and then respect whatever grouping the report applies. Fixed calculations aggregate at a level you specify and hold that level regardless of report layout.

Why does my calculated metric show zeros and blanks? Calculated metrics display all results by default, including nulls and zeros. Add a metric filter starting at 1 to hide them.

Can I reference one calculated metric inside another? Yes, and it is good practice for shared logic — but keep names free of punctuation, and never reference a calculation inside itself.

Why does my percentage not match a manual count? Almost always because the ratio was built as a standard calculated metric instead of a result calculation, so totals average the row-level ratios.

Should thresholds use business hours or calendar hours? Match the promise. Internal productivity targets usually want business hours; customer-facing elapsed time wants calendar hours. See business hours vs calendar hours.

How do I count unique customers rather than tickets? Use the relevant user metric with a D_COUNT aggregator so repeat requesters count once. Zendesk tickets per customer covers the reporting patterns.

Get the metrics you would otherwise have to write formulas for - start free