How I measure. A product isn't done when it ships — it's done when the metric moves and the guardrails hold. This page consolidates the measurement work that lives across my case studies: the North Stars I've defined, the metric trees behind them, and how I design experiments. It's an index of real artifacts, not a duplicate.

Measurement Philosophy

Four rules I hold to:

  1. One North Star, never a dashboard of equals. A North Star captures value delivered to the user, not activity. Engagement metrics that don't tie to value are vanity.
  2. Every North Star decomposes into a tree. Input metrics are the levers I can directly influence; guardrails are what must not degrade while I push the inputs.
  3. Instrument at spec time, not after launch. The event taxonomy is part of the PRD. Late instrumentation creates a cold-start you can't undo.
  4. Outcome metrics over output metrics. "Shipped 4 features" is output. "D7 retention +6pp" is outcome. I report the second.

North Stars I've Defined

Product North Star Why this metric Source
MyUni VWAC (Verified Weekly Active Contributors) Captures the trust + contribution loop that is the product's moat — not raw DAU MyUni case
Spotify (exercise) Free→Premium conversion rate Direct line to revenue; isolated the activation moment that drove 5%→12.5% Spotify case
SastaSundar Fulfilled-order GMV Ties UX fixes (OCR, queue) to the only number the business survives on SastaSundar case
Lenskart (exercise) Repeat purchase within 18 mo Turns a post-purchase cliff into an engagement runway Lenskart case

Anatomy of a Metric Tree

Using MyUni's VWAC as the worked example:

North Star: VWAC — Verified Weekly Active Contributors
  ├─ Input: % verified users posting ≥1/week
  ├─ Input: comment→view ratio (≥8%)
  ├─ Input: WhatsApp referral rate (≥25%)
  └─ Guardrails:
       • crisis-signal SLA (L4 ≤ 15 min) must hold
       • no drop in trust/safety report-resolution rate

The discipline: if an input metric rises but a guardrail breaks, the change is rejected — growth that degrades trust is negative progress.

How I Design Experiments

My default experiment spec — five fields, no more:

Field What it answers
Hypothesis We believe [change] for [segment] will move [metric] because [reason]
Variant The single change under test (isolate one variable)
Success threshold The pre-committed number that means "ship it"
Guardrail What must not degrade for the win to count
Decision rule Ship / iterate / kill — decided before seeing data

Anti-pattern I avoid: running a test with no pre-committed decision rule. If you decide what counts as success after seeing the data, you're not experimenting — you're rationalising.

Tooling

SQL · Amplitude · Mixpanel · A/B testing frameworks · funnel + cohort analysis. I instrument the event taxonomy myself rather than handing it to analytics after the fact.