Product Metrics skill for Codex

A metric system is done when one north star reflects value customers actually receive, every team owns input metrics that plausibly move it, guardrails catch damage, and each metric has a definition precise enough that two analysts writing SQL independently get the same number.

North star metric

Criteria, all required:

• Measures value delivered to the customer, not value extracted (revenue, pageviews).
• Leading indicator of revenue or retention, not a lagging financial number.
• Moves within weeks when the product improves.
• Countable from data the team has or can instrument.
• Understandable by everyone in one sentence.

Product type	North star pattern	Example
Collaboration SaaS	Active teams doing the core action	Weekly active teams with 3+ members editing
Marketplace	Successful transactions	Weekly completed bookings
Consumer content	Engaged consumption	Weekly users with 3+ sessions of 5+ min
Dev tool / API	Successful usage in production	Weekly accounts with 1k+ successful API calls
Fintech / payments	Value moved	Monthly payment volume from active merchants

Reject candidates that fail the “can we game it without helping users?” test. Signups, downloads and raw DAU fail. Always pair the north star with at least two guardrails.

Metric tree

Decompose the north star into multiplicative or additive drivers until each leaf is something one team can change with product work.

Weekly active teams (north star)
├── New active teams
│   ├── Signups (marketing)
│   ├── Activation rate: % of new workspaces with 3+ members editing in 7 days (onboarding)
│   └── Time to first shared doc (onboarding)
├── Retained active teams
│   ├── Week-4 team retention (core)
│   └── Feature adoption: % active teams using comments weekly (collaboration)
└── Resurrected teams
    └── Reactivation rate after 28 days dormant (lifecycle)
Guardrails: support tickets per 100 teams, p95 editor latency, unsubscribe rate

For each leaf: owner team, current value, target, and the hypothesis connecting it to its parent. Leaves with no owner or no plausible lever get cut.

Writing a definition

Every metric gets a definition card. Ambiguity hides in each of these fields:

### Activation rate (7-day)
Numerator: workspaces created in the cohort week with >= 3 distinct users who fired
  `document_edited` within 7 x 24 h of workspace creation
Denominator: workspaces created in the cohort week, excluding internal and test
  workspaces (is_internal = false, email domain not in test list)
Grain: cohort week (Monday 00:00 UTC start)
Source: warehouse table analytics.events, analytics.workspaces
Known caveats: users who join via SSO auto-provisioning fire no invite events
Owner: Onboarding squad | Reviewed: 2026-10-01

Questions to resolve for every metric: which event exactly, what counts as a user (account, person, device), time zone, window length and anchor, exclusions (internal, bots, test, refunds), and whether it is cohort-based or period-based.

Query example

-- 7-day activation by weekly signup cohort (Postgres/BigQuery-style SQL; adjust date functions)
with cohort as (
  select id as workspace_id, created_at,
         date_trunc('week', created_at) as cohort_week
  from workspaces
  where not is_internal
),
editors as (
  select c.workspace_id, count(distinct e.user_id) as editors
  from cohort c
  join events e
    on e.workspace_id = c.workspace_id
   and e.event_name = 'document_edited'
   and e.occurred_at <  c.created_at + interval '7 days'
  group by 1
)
select c.cohort_week,
       count(*) as workspaces,
       avg(case when coalesce(ed.editors, 0) >= 3 then 1.0 else 0 end) as activation_rate
from cohort c
left join editors ed using (workspace_id)
where c.cohort_week <= current_date - interval '14 days'  -- only complete cohorts
group by 1
order by 1;

Exclude incomplete cohorts; partial cohorts make the latest week look worse. For funnel and retention query patterns in depth, see $sql-for-analytics.

Workflow

- [ ] 1. Read the strategy, business model and existing dashboards/metric docs
- [ ] 2. Inspect the event schema or tracking plan (repo or warehouse) to see what is measurable
- [ ] 3. Propose 2-3 north star candidates; test each against the criteria
- [ ] 4. Build the metric tree down to team-owned leaves
- [ ] 5. Add guardrails for quality, cost, trust and speed
- [ ] 6. Write definition cards; compute baselines where data access allows
- [ ] 7. List instrumentation gaps; hand them to $analytics-tracking-plan

In Codex, warehouse access usually requires credentials and network; if neither is available, write the queries and definitions and ask the user to run them, rather than guessing baselines.

Auditing existing metrics

Flag each dashboard metric as one of:

Flag	Meaning	Action
Vanity	Only goes up (cumulative signups, total users)	Replace with rate or active count
Ambiguous	Definition missing or disputed	Write a definition card
Orphan	No owner, no decision uses it	Remove from team dashboards
Lagging only	Revenue, churn with no leading inputs	Add input metrics
Healthy	Defined, owned, used in a decision	Keep

Gotchas

• Ratios hide volume: activation rising because signups collapsed is not success. Show numerator and denominator.
• Changing a definition breaks trends. Version definitions and backfill or annotate.
• Averages hide distributions. Use medians or percentiles for time and money metrics.
• Goodhart’s law: once a team is paid on a metric, guardrails matter more than ever.
• DAU/MAU ratios suit daily-use products only; a payroll tool used monthly is healthy at a low ratio.
• Never present a baseline you did not compute; mark it “unknown”.

Verification

Hand two definition cards to a fresh read and ask whether the SQL could be written without questions. Check that every leaf in the tree has an owner and a plausible lever, every north star candidate passes all criteria, at least two guardrails exist, and computed numbers reconcile with an independent source (billing system, admin console counts) within a few percent.