Canonical KPI Definition Template (Interactive)

Concise, unique name. Prefer noun-verb or clear metric phrasing (e.g., 'Checkout Conversion Rate', 'Mean Time to Repair'). Avoid ambiguous abbreviations.

One or two sentences describing what the metric measures and why it matters.

What decisions, actions, or outcomes should this metric guide? Example: 'Used by product managers to decide when to prioritize checkout flow improvements.'

Provide a clear formula, numerator/denominator, aggregation method and time window. State units (percentage, count, seconds). Example: 'Checkout Conversion Rate = (completed_checkouts / visits_with_cart) * 100 over 28-day rolling window.'

Give SQL pseudocode showing joins, filters, windowing, and grouping. Example: 'SELECT DATE(event_time) as day, COUNT(DISTINCT order_id) / COUNT(DISTINCT session_id) as conversion_rate FROM events WHERE event_type IN ('cart_add', 'checkout_complete') GROUP BY day;'. Include known parameters such as time_zone, event dedup rules, and primary keys.

Select the primary counting unit or grain of the metric. This clarifies whether it's per-user, per-session, per-order, per-device, etc.

If 'Other' or extra explanation is needed, describe how unique keys are determined, de-duplication rules, and primary keys used.

List tables, events, systems, API endpoints, ETL jobs and transformations that produce the data used in this metric. Note any known upstream owners and refresh schedules.

Person or role accountable for the metric (e.g., 'Product Analytics / Lead: Name, email'). This owner is responsible for accuracy, definition changes, and reviews.

Who uses this metric (roles, teams, reports, dashboards, alerts)? How is it acted on? Example: 'Used in Weekly Ops dashboard and automated alert to SRE.'

How often is the metric computed or expected to be fresh? Choose the usual cadence for reporting and alerting.

Unit of measure (e.g., %, count, seconds, $).

Define target, acceptable range, warning thresholds, and breach conditions. Example: 'Target=2.5% ±0.3%; Warning if <2.2%; Breach if <1.9% for two consecutive days.'

Document known data quality issues, sampling, imputation, smoothing, outlier treatment, or when the metric may be unreliable. Record approved transformations and who authorized them.

Describe any alerts, anomaly detection, responsible on-call, and runbooks or escalation steps tied to this metric.

Give representative examples (recent values, baseline, seasonality notes) so reviewers can sanity-check the metric when it's implemented.

Select yes if the metric uses personally identifiable information or other regulated data. If yes, note compliance and retention constraints in the limitations field above.

How often should the owner review and reauthorize the metric definition?

Comma-separated tags to help cataloging (e.g., 'revenue, funnel, ops, sla').

When this definition takes effect and any short version history or version number.