‹ Back to the directory

Metrics Model Builder

Define a metrics tree from north star to input drivers, with one owner and one unambiguous definition per metric.

by Reedmarsh Analytics·0 installs
metricskpisanalyticsstrategy
P

Create a free shareskills account to install Metrics Model Builder into Claude.

Create a free account

Metrics Model Builder

Most metric fights are definition fights in disguise. This skill builds a metrics model — a north star, the driver tree beneath it, and a one-block spec per metric — so that every number on a dashboard has exactly one meaning, one owner, and one place where its definition lives. The output is not a dashboard; it is the contract that makes dashboards trustworthy.

When to use this skill

  • Two teams report "activation" (or churn, or engagement) and their numbers disagree
  • A new product or business line needs its measurement designed before launch
  • Leadership asks "what should we actually optimize?" and the honest answer is a shrug
  • Planning season approaches and goals need metrics that can bear weight
  • A metric is being gamed and needs a counterweight

Workflow

  1. Anchor on the value exchange. In one sentence: what does the user get, and what does the business capture when they get it? The north star counts events of that exchange — recurring, hard to fake, and leading revenue rather than trailing it. "Teams completing the core workflow each week" beats "registered accounts" on all three tests.
  2. Decompose into a driver tree of two or three levels, where each level roughly multiplies or adds into the level above — reach x activation x frequency x retention, or new + resurrected − churned. Every leaf must be movable by a specific team; a driver nobody can act on is decoration.
  3. Write the spec for every metric in the tree. This is the deliverable:
    • Name, plus the question it answers in plain words
    • Formula: numerator, denominator, filters, and the grain — per user, per account, per active week
    • Time treatment: event time or processing time; calendar or rolling window; the timezone
    • Inclusions and exclusions stated positively: test accounts, internal users, free tier, refunds
    • One owner, one source of truth (a specific table or query), and a refresh cadence
  4. Stress-test each definition with edge personas: the user who signed up twice, the account that downgraded mid-month, the trial that converted on day 31. If two reasonable people could compute different numbers from the spec, the spec is not finished.
  5. Pair every target metric with a guardrail that catches its failure mode: signups pair with activation rate; speed pairs with error rate; volume pairs with quality. Any measure made a target will be gamed eventually — build the counterweight in advance.
  6. Classify leading versus lagging and set expectations accordingly: leading metrics move in weeks and can be gamed; lagging metrics are honest and slow. Teams steer by leading and report by lagging.
  7. Reconcile against reality. Compute each metric once from its spec and compare with the numbers already circulating. Every discrepancy is either a bug in the spec or a myth in the organization — both are wins to find now rather than in a board meeting.
  8. Version and govern. Definitions change; when one does, the spec gets a changelog entry and historical charts get an annotation — otherwise the organization will argue about a "trend" that is actually a redefinition.

Output format

## Metrics model: <product or business>

North star: <metric> — <the value-exchange sentence>

Driver tree:
<north star>
├─ <driver> (owner)
│  ├─ <input metric> (owner)
└─ <driver> (owner)

### Metric spec: <name>            [repeat one block per metric]
Question: <plain words>
Formula: <numerator> / <denominator>, grain <g>, window <w>
Excludes: <list>
Guardrail pair: <metric>
Owner: <role> | Source: <table/query> | Cadence: <daily/weekly>
Changelog: <date — change — reason>

Quality bar

  • Any analyst could recompute any metric from its spec alone and match the official number
  • No metric has two owners; no owner holds a metric they cannot influence
  • Every target has a paired guardrail; every leaf driver maps to a team
  • The whole tree holds fewer than ~15 metrics — a model nobody can keep in their head governs nothing
  • Redefinitions are impossible to make silently

Smells that the model is broken

  • A "north star" that finance cannot connect to revenue even in principle
  • Ratios averaged across segments instead of recomputed from pooled numerators and denominators
  • A metric that only ever appears in slides, never in a query
  • Definitions living in a chat thread instead of the spec
Metrics Model Builder — AI skill by Reedmarsh Analytics | shareskills