Skip to content

You didn't get into analytics to spend an hour explaining a Slack thread

Grounded in: r/analytics: "Has anyone else spent more time explaining metrics than analyzing them?" (2026-07-14), with supporting evidence from r/analytics: "How do you handle stakeholders who keep changing the metric definition midproject?" (2026-07-18)

An analyst posted something small on r/analytics that a lot of people recognized immediately: they got into the field to solve problems with data, and somewhere along the way half the job turned into explaining why two dashboards show different numbers, or why one metric isn't the same as another. The post described losing almost an hour before a meeting answering Slack messages about why revenue looked different in two places. Not building anything, not analyzing anything, just narrating a discrepancy that already existed.

That hour is not an edge case. It's the default tax on every team that has more than one dashboard and no single place where "revenue" (or "active user," or "churn") is defined once. Every new report is a chance for someone to rebuild the metric slightly differently (a different join, a different date cutoff, a different filter nobody knew mattered), and every difference becomes somebody's Slack thread to explain, live, under time pressure, usually right before the meeting where the number actually matters.

The stakeholder-drift version of the same problem. A different thread from the same week described a KPI that started as total revenue, became net revenue, then got sliced by region with new date logic: three redefinitions before the dashboard even shipped, with the underlying data model refactored twice along the way and no record of what changed or when. Nobody was working from a spec. They were working from whatever the metric currently meant, which kept moving.

Why "just explain it better" doesn't fix this. The instinct is to get faster at answering: write a FAQ, keep a glossary doc, become the person who can rattle off the difference between the two revenue numbers from memory. That's optimizing the wrong step. The actual cost isn't that explaining takes time; it's that every explanation is being reconstructed from scratch, from memory, by whoever happens to be asked. There's no artifact that already contains the answer. The explanation is the missing infrastructure, performed live, on repeat, by a human.

What removes the tax instead of getting better at paying it:

  1. One definition, referenced everywhere. A metric ledger means "revenue" is defined once (exact filters, joins, as-of logic) and every dashboard that uses it points back to that single definition instead of quietly re-deriving its own. Two dashboards can't drift apart if there's only one place the definition lives.
  2. A record of what changed, not just what it is now. When a stakeholder redefines a KPI mid-project, that redefinition should be a versioned, timestamped event, not a silent edit that leaves the old dashboards looking "wrong" with no explanation of why they no longer match.
  3. The explanation becomes a lookup, not a performance. When someone asks "why is this different," the answer should be a link to the metric's definition and version history, not an analyst reconstructing the story live in a Slack thread for the tenth time this quarter.

The person who wrote that Reddit post didn't lose an hour because they're bad at communicating. They lost it because their stack has no memory: no single place a metric's definition lives, gets versioned, and can be pointed to instead of re-explained. Fix that, and the job goes back to what they signed up for: analyzing data, not narrating why two copies of the same number disagree.

Canon makes the metric definition the product — approved, versioned, and checkable. See how it works →