Product Analytics
Product analytics starts not with SQL but with the question "what should we even measure, and why". An analyst picks metrics from business goals, designs them so decisions can be made on them, and when a metric drops, localizes the cause in order rather than rushing to fix things blindly.
The topic is failed on thinking, not technique. Confusing correlation with causation, computing LTV from revenue instead of profit, prioritizing by the loudest stakeholder — those are the classic traps. The map below runs from selecting metrics to prioritizing what to build.
Topic map
- Metric selection — how to assemble a coherent metric set from the business model, not from the data that happens to exist.
- Metric design — how to design a metric to compare two options and to compare distributions, not averages.
- Metric quality — the criteria of a good metric: tied to a goal, actionable, measurable, sensitive, decomposable.
- Metric-drop investigation — ordered blocks for the root-cause search, from data quality to external factors.
- Correlation vs causation — why a link does not prove a cause and how self-selection breaks conclusions.
- Unit economics — CAC versus LTV, LTV from profit, and discounting.
- Data visualization — show the metric itself, not the raw material the reader computes it from in their head.
- Fermi estimation — an upper and a lower bound from an anchor, with explicit assumptions.
- Backlog prioritization — impact versus cost and the RICE/ICE framings.
Common traps
| Mistake | Consequence |
|---|---|
| Choosing metrics from available data, not from goals | A dashboard of numbers that influence nothing |
| Reading correlation as proven causation | A false conclusion about a feature's or program's effect |
| Computing LTV from revenue, not profit | Unit economics look healthier than they are |
| Fixing a metric before checking data quality | Fixing the product when a counter is broken |
| Comparing averages only, ignoring the distribution | Tails and percentiles are missed |
| Prioritizing by the loudest stakeholder | Building the wrong thing for impact |
Interview relevance
Product analytics is asked to check the structure of your thinking, not knowledge of formulas. A strong candidate always starts from the goal and the unit of measure — "first I define a North Star, then I estimate impact in that metric" — and names the trap out loud before falling into it.
Typical checks:
- Selecting and designing metrics from a business goal and their quality criteria.
- Structured, block-by-block investigation of a metric drop.
- The difference between correlation and causation and the role of an A/B test.
- CAC/LTV unit economics and prioritization by impact and cost.
Common wrong answer: "the metric dropped — roll back the last release". Before a fix, the analyst checks the data (seasonality, a broken counter, the denominator) and localizes the segment — otherwise you fix what was not broken.