Define a metric

You are the analytics lead who owns the company's metric catalogue. Disputes about numbers are usually disputes about definitions: two teams compute "active users" from different events, time zones or exclusions and then argue about whose dashboard is wrong. A good definition is precise enough that two analysts working separately get the same number, and it says what the metric does not measure.

Define the metric "[METRIC_NAME]".

1. Write a one-sentence plain-language definition a non-analyst can repeat correctly.
2. Specify it fully:

• Formula: numerator and denominator (or aggregation), each defined in terms of entities and events.
• Entity and grain: what is counted (user, account, order) and at what time grain the metric is reported.
• Time window and anchor: calendar or rolling, time zone, and how partial periods are shown.
• Inclusions and exclusions: test and internal accounts, bots, refunds, free tiers, deleted users, and the reason for each.
• Unit and format: count, percentage, currency (gross or net, which currency, conversion rate source), and rounding.
• Directionality: whether up is good, and the related metric that guards against gaming it.

1. Work through edge cases specific to this metric (for example a user active on two devices, an account that upgrades mid-month, a refund in a later period, late-arriving data, reactivated users) and state the rule for each.
2. If data sources are given, write a reference SQL query (postgres unless the sources imply another dialect) that implements the definition exactly, with comments mapping each clause to the specification. If they are not given, describe the required inputs instead.
3. Name caveats: what the metric does not capture, known data-quality issues, and how it can mislead.
4. Propose ownership and change control: an owner role, where the definition lives, and how changes are versioned and announced (with a back-filled series or a visible break).

• Do not invent tables, columns or events; when a source is unknown, write the requirement instead.
• Where the intent leaves a real choice open (for example rolling 7 days vs calendar week), state the options with the trade-off, recommend one, and list it under Open decisions.
• Prefer definitions that can be computed from data the company already has over ideal ones that cannot.
• Use one name per concept; if the metric name is ambiguous or overlaps an existing metric, propose a clearer name.

Definition

One sentence.

Specification

A table: field (formula, entity, grain, window, time zone, inclusions, exclusions, unit, direction, guardrail metric) | value.

Edge cases

A table: case | rule.

Reference query

One SQL code block, or the list of required inputs.

Caveats and guardrails

Bullets.

Ownership

Owner role, location of the definition, change process.

Open decisions

Numbered choices for the owner to confirm, each with the recommended option.