Product
A product analyst is the product's eyes. You watch how people actually use the app or the site, turn their behavior into numbers, and turn those numbers into decisions — what to fix, what to build, what to kill.
Day to day: you compute metrics (how many came back, reached checkout, got stuck in the funnel), build dashboards so the team can see the picture, and test hunches with A/B tests — 'is the new button really better, or did we just want it to be?'.
SQL is your main language (pulling events and orders from the database). Python with pandas — for cohorts, retention, and A/B. A BI tool like Metabase — to surface metrics without code. Plus a pinch of statistics: proportions, confidence intervals, and an honest p-value.
This branch is for you if you like understanding people, not just crunching numbers: why a user leaves, what keeps them, what makes them pay. It's the most hireable analytics track — everyone with an app or a website is hunting for product analysts.
Unlike a marketing analyst (they're about ads and acquisition) or a BI analyst (more about reporting), you're about what happens INSIDE the product: behavior, retention, experiments. And unlike a data scientist, you care more about a fast, honest answer that drives a decision than about a fancy model.
Read the product's pulse
a couple of eveningsGet a plain-English feel for the core product metrics: active users (DAU/WAU/MAU), conversion, average order value, revenue per user. Not hard math — just learn to read them and explain what each one means.
- You can explain in your own words how DAU differs from MAU, and why their ratio — stickiness — matters.
- You know the difference between revenue, average order value, and ARPU — and when each one is the right lens.
- You compute conversion as a proportion and always keep 'from what to what' in mind.
- You spot when an average misleads because of outliers — a couple of whales drag the average order value up.
- You plot a metric over time and read the trend, not just a single number.
Funnels and cohorts
1–2 weeksLearn to see the user journey as a funnel (where people drop off) and to slice users into cohorts — groups by entry time or trait — so you can compare them fairly.
- You build a funnel from events and compute step-by-step conversion, not just the overall rate.
- You find the funnel's bottleneck and form a hypothesis about why people are lost there.
- You understand what a cohort is and can split users by entry time or by a trait.
- You compare cohorts against each other without confusing 'different people' with 'change over time'.
- You confidently join several tables (events, users, orders) to assemble a funnel.
Retention: who comes back
1–2 weeksGet to grips with retention — the heart of product analytics. Compute day and week retention, build a retention curve, and read its shape.
- You compute retention as the share of a starting cohort that returns, and you get why that's not the same as 'active users'.
- You build a retention curve and explain its shape: the sharp early drop, then the plateau.
- You tell classic (N-day) retention from rolling/range retention and know when each fits.
- You read retention as the key product-market-fit signal — a flat plateau above zero means the product genuinely matters to someone.
- You tie retention to segments: which cohort or user type sticks around better.
Stats basics and the A/B mindset
2–3 weeksAdd the statistical core: randomness, confidence intervals, hypotheses, and — honestly — the p-value. Understand why a difference in metrics can turn out to be just noise.
- You state a null and an alternative hypothesis for a product question.
- You explain the p-value HONESTLY: the chance of a result this extreme (or more) IF there were no effect — and you don't mix it up with 'the probability the hypothesis is true'.
- You compute a confidence interval (including by bootstrap) and always report an estimate with its margin, not a bare number.
- You pick the right test: a t-test for means, a proportions test or chi-square for conversions.
- You understand Type I and Type II errors and what statistical power is.
- You keep in mind that statistical significance is not the same as practical importance.
A full A/B experiment
2–3 weeksRun an A/B end to end: hypothesis → design and sample size → analyze the difference in proportions → confidence interval for the difference (bootstrap) → effect size → a business decision.
- Before touching the data you fix the hypothesis and the metric, so there's no after-the-fact p-hacking.
- You get the role of randomization: why it, specifically, lets you claim causation rather than mere correlation.
- You compare proportions across groups with the right test (proportions z-test or chi-square) and build a bootstrap CI for the difference.
- You size the effect and answer the real question: is this lift even worth shipping.
- You write a business takeaway in plain language — what to do with the result, not just 'p < 0.05'.
- You watch for the traps: peeking before the test ends, multiple comparisons, sample bias.
A product-analytics portfolio
finish · as long as it takesPull 2–3 finished cases into one story — from a product question to a decision. This is what you show at interviews and what makes you competitive.
Finish: The finish line: you can take any service's raw product data and drive it to a conclusion the team can act on. You're competitive.
- Each case lives on GitHub with a clear README — question, data, method, takeaway — readable by a non-analyst too.
- You have at least one BI dashboard (Metabase/Superset) with product metrics, a funnel, and retention.
- You have one A/B case taken all the way, with an honest verdict and an effect-size estimate.
- Every case ends in a decision or a recommendation, not just a chart — you sell the conclusion, not the table.
- In an interview you can walk through any case in 5 minutes: why you measured it, what you found, what you'd change in the product.