Product analyst role: funnels, experiments and the weekly review

The Monday metrics review sets the rhythm

In most product teams the week starts with a metrics review. The product analyst prepares it: weekly active users, activation, the core conversion funnel, retention for recent signup cohorts, and anything that moved sharply. The PM and engineering lead read it and ask "why". The rest of the week is largely spent answering those whys.

A sample week for an analyst on a hypothetical Indian grocery delivery app:

• Monday: metrics review. Checkout conversion fell on Android only.
• Tuesday: break the drop down by app version; it is concentrated in the version released Friday. Check with engineering whether the payment-page event still fires.
• Wednesday: it does not fire on one payment method, so conversion looked lower than it was. Write a short note correcting last week's number.
• Thursday: design the analysis plan for an upcoming test of a "repeat last order" button.
• Friday: answer three ad hoc questions from the PM and update the event dictionary.

Notice Wednesday. A large share of product analytics is discovering that a metric moved because tracking changed, not because users did.

The query you will rerun every week

Here is a weekly funnel on synthetic event data. It counts users who reached each step in order, not just users who fired each event, which is the mistake that makes funnels exceed 100%. It runs in SQLite as written.

CREATE TABLE events (user_id INTEGER, event TEXT, ts TEXT);
INSERT INTO events VALUES
 (1,'app_open','2026-09-21 09:00'),(1,'add_to_cart','2026-09-21 09:05'),(1,'checkout_start','2026-09-21 09:07'),(1,'order_placed','2026-09-21 09:09'),
 (2,'app_open','2026-09-21 10:00'),(2,'add_to_cart','2026-09-21 10:02'),
 (3,'app_open','2026-09-22 11:00'),(3,'checkout_start','2026-09-22 11:01'),
 (4,'app_open','2026-09-23 12:00'),(4,'add_to_cart','2026-09-23 12:03'),(4,'checkout_start','2026-09-23 12:04'),
 (5,'add_to_cart','2026-09-24 08:00'),(5,'app_open','2026-09-24 08:01');

WITH firsts AS (
  SELECT user_id,
         MIN(CASE WHEN event='app_open' THEN ts END)       AS t_open,
         MIN(CASE WHEN event='add_to_cart' THEN ts END)    AS t_cart,
         MIN(CASE WHEN event='checkout_start' THEN ts END) AS t_checkout,
         MIN(CASE WHEN event='order_placed' THEN ts END)   AS t_order
  FROM events
  WHERE ts >= '2026-09-21' AND ts < '2026-09-28'
  GROUP BY user_id
),
ordered AS (
  SELECT user_id,
         t_open IS NOT NULL AS s1,
         (t_open IS NOT NULL AND t_cart > t_open) AS s2,
         (t_open IS NOT NULL AND t_cart > t_open AND t_checkout > t_cart) AS s3,
         (t_open IS NOT NULL AND t_cart > t_open AND t_checkout > t_cart AND t_order > t_checkout) AS s4
  FROM firsts
)
SELECT SUM(s1) AS opened, SUM(s2) AS carted, SUM(s3) AS checked_out, SUM(s4) AS ordered,
       ROUND(100.0 * SUM(s4) / SUM(s1), 1) AS open_to_order_pct
FROM ordered;

On this data the result is 5 opened, 3 carted, 2 checked out, 1 ordered, 20.0%. User 3 checked out without a cart event and user 5 added to cart before opening; strict ordering excludes both from later steps. Whether that is right is a product decision, and writing it down is part of the analyst's job. Using first occurrences is a simplification; a real funnel may need sessions or per-attempt logic.

Experiments: the second half of the job

Most mature product teams run A/B tests. The product analyst usually owns the analysis plan before launch: the primary metric, guardrail metrics (such as refunds or app crashes), the minimum run length and the sample size needed. After the test, the analyst reports the effect with its uncertainty and flags anything that invalidates the result, such as unequal group sizes that suggest assignment broke.

Decisions changed, not dashboards shipped

Good product analysts are judged on the correctness and adoption of core metrics, the share of launches that had a pre-agreed success metric, the speed and quality of answers to product questions, and how often their analysis changed a decision. Dashboard count is a poor measure; one trusted metrics review beats twenty unused dashboards.

PMs, engineers and the instrumentation backlog

You typically report to an analytics lead or head of data, and sit with a product squad: a PM, engineers, a designer. Engineers matter more than people expect, because they implement the tracking your analysis depends on.

Product analyst versus business analyst and data scientist

A business analyst in a product firm overlaps heavily, but tends to lean towards requirements and process. A data scientist is expected to build models; a product analyst mostly uses descriptive analysis and experiments. In small startups one person often does all three.

Mixpanel, A/B testing and other posting signals

Tracking plan first, experiments second

Spend the first month learning the event dictionary and reproducing the existing core metrics yourself. In the second month, find and fix at least one tracking gap. By the third, own the weekly review. From here, people move to senior product analyst, analytics manager, data scientist or product manager.

The Data Analyst programme teaches SQL funnels, cohort analysis and experiment reading with synthetic product data; check your current gaps with the free skill check.