product analytics
Also called: product data analysis, in-product analytics, behavioral analytics, product usage analytics
The practice of measuring what people actually do inside a product, from the events they trigger, and turning those numbers into decisions about what to build, fix, price and grow.
Product analytics is the work of answering product questions with behavioral data. Every meaningful thing a user does in an app or web product (signs up, creates a group, adds an expense, opens a paywall, cancels a subscription) is logged as an event with a time, a user ID and properties. Product analytics turns that stream into metrics, compares them across people, time and versions, and ends with a decision someone writes down.
The questions it answers are practical ones:
- Who uses the product, and how often, at the product's natural rhythm (DAU, WAU, MAU, stickiness)?
- Where do new users get stuck on the way to their first real value (funnels, activation)?
- Do people come back after the first week, month, quarter (retention by cohort)?
- Did the change work, and how sure are we (A/B tests, careful before/after comparisons)?
- Does it pay: conversion to paid, revenue per user, LTV against acquisition cost?
- How will we grow: which channels bring users who stay, how much comes from invites?
It overlaps with neighboring disciplines but asks a different question:
The most useful habit in product analytics is to start from a decision, not from a dashboard: write the question, define each metric precisely enough that two people get the same number, check the raw data for counting traps (server-generated events, staff accounts, time zones), and only then chart it. A number without a decision attached is usually a vanity metric.
Example
Maya, the product lead at Halves (a bill-splitting app), asks: "Is receipt scanning worth more investment?" Scanning is one of the Halves Plus features, so it sits behind a paywall.
1. Define the terms. A monthly active user (MAU) is someone who added an expense or recorded a settle-up themselves in the last 30 days. Server-created recurring bills and staff accounts don't count. In June Halves had 40,000 MAU.
2. Look at the paywall by trigger. 3,200 of those users saw the paywall at least once; each user is counted under the first trigger they hit:
3. Read it. Receipt scanning brings half of all paywall views (1,600 / 3,200 = 50%) and 64% of trials (128 / 200), and users who meet the paywall there start a trial twice as often as those who meet it in settings (8.0% vs 4.1%).
4. Write the decision. "Receipt scanning is the strongest reason people try Plus. Next: improve the scan flow and measure trial-to-paid for scan-triggered trials. Whether scanning also keeps people is a separate question: users who scan receipts differ from those who don't, so we'll test it rather than compare the two groups."
Common mistakes
- Starting from a dashboard instead of a question. Charts without a decision attached turn into a weekly ritual nobody acts on.
- Undefined metrics. "Active users" means nothing until you write down the action, the unit, the window, the time zone and the exclusions.
- Trusting raw event counts. Server-generated events, duplicate logging and QA accounts inflate numbers; check the raw rows before you chart them.
- Reading correlation as cause. "Users who use feature X retain better" usually says who chooses X, not what X does. Use an experiment or say what the comparison can't prove.
- Treating it as a tool purchase. Installing an analytics SDK gives you events, not answers; the tracking plan and the definitions are the real work.