What is product analytics? Measuring what people do in your product and turning it into decisions: the eight questions it answers, the tools, a worked example.
By Sergey BruhPublished 9 min read
A free course for PMs and marketers: short lessons, real product data and exercises with instant feedback.
Start the free course9 min read
What a tracking plan is, and a free tracking plan template in six sections: questions, events, properties, metric definitions, QA, change log, with an example.
What is product analytics? Product analytics is the practice of measuring what people actually do inside a product, from the events they trigger, and turning those numbers into decisions: what to build, what to fix, how to price and where to grow. Web and marketing analytics mostly tell you who arrived and from where; product analytics follows them after sign-up. Did they reach the moment the product is useful? Did they come back next week? Did they pay, and did they bring anyone? A dashboard full of charts isn't product analytics; a clear answer to one of those questions, with the numbers behind it and the decision it leads to, is. This guide walks through the eight questions product analytics answers, one short section each, with a worked example, what product analytics tools do and links to deeper guides.
They overlap at the edges: product analytics borrows cost data from marketing to judge a channel, and hands revenue per cohort to finance. The difference is the unit: product analytics thinks in users over time, not in visits or in calendar months.
Everything starts with an event, a record that something happened: who (a user id), what (expense_added) and when (a timestamp). Event properties describe that one moment, such as the amount or how the expense was entered. User properties describe the person and stay the same across their events, such as the sign-up date or the channel they came from. Splitting events by user properties is how most questions get answered: "do people from paid ads add fewer expenses than invited people?" The lesson on events, properties and users walks through a real-looking log.
Our running example is Halves, a bill-splitting app. The team asks a simple question: how many active users did we have last week? The raw export has 147 event rows from 22 accounts. Here is what happens as the definition gets precise:
Three accounts only had recurring bills added automatically by the server; they never opened the app (). One QA account was flagged as internal (18). A second one wasn't, but its sign-up channel was "staff" and every expense it added was exactly 1 dollar, a typical test pattern (). So the honest answer is 17, and it comes with a written definition: real people, not staff, who opened the app at least once during the week. The lessons on counting traps and metric definitions turn this into a habit.
That's product analytics in miniature: a question, a definition, a check for traps and a number that survives when someone recounts it.
Before any chart, decide which events a question needs, what properties they carry and how each metric is defined, so that two people get the same number. A tracking plan is the written contract between product, engineering and analytics; the tracking plan template shows what goes into one.
A team needs one metric that captures the value users get, plus the inputs that move it. Total downloads or sign-ups only go up, which makes them vanity metrics: they feel good and decide nothing. It also helps to pair volume metrics (how much: active users, expenses added) with quality metrics (how well: the share of new groups that get a second member), as the volume vs quality metrics lesson shows. Choosing a north star is covered in north star metric examples and the north star lesson. For how often people use the product, see the DAU/MAU ratio, and why the right rhythm (daily, weekly or monthly) depends on the product.
A funnel lists the steps from sign-up to value and shows the share of users who make it from each step to the next. The biggest drop isn't always the best place to work; funnel analysis covers order, conversion windows and who counts. Activation is the moment a new user first gets real value, written as an action plus a time limit, for Halves something like "a second group member and three expenses in the first week"; activation rate shows how to find that moment in data rather than guess it.
Retention is the share of a cohort still using the product after a given time. It's the metric that most often separates products that work from products that are merely marketed well. How to calculate retention rate compares day-N, rolling and bracket retention, and the cohort analysis example shows how to read a cohort table without averaging it wrong. A curve that flattens instead of falling to zero is one of the clearest signs of product-market fit.
An A/B test answers it best: one primary metric chosen up front, a sample size worked out before launch and a decision rule written down. Two guides from the statistics side help here: how long to run an A/B test and minimum detectable effect.
Often there's no test: a new version shipped to everyone, or a feature only some users chose. Before-and-after comparisons can be fair if you compare like with like (same traffic mix, same season), but "users who do X retain better" usually says more about who chooses X than about X itself. Correlation vs causation explains why.
Revenue per user, conversion to paid, the LTV curve by cohort, acquisition cost and how long a cohort takes to pay it back. The LTV to CAC ratio puts these together on two paid channels: at Halves, a paid-social user earns about 1.55 times their acquisition cost in 12 months.
Growth comes from channels, and from users bringing other users. The viral coefficient measures the second: at Halves each new user brings about 0.31 more through invitations. That can't drive growth alone, but over all generations it turns every 100 users a channel brings into about 145. Forecasting active users from cohorts, new users times retention, ties it all together.
The AARRR funnel (Acquisition, Activation, Retention, Referral, Revenue) is a handy map of the same ground: questions 3 and 4 cover activation and retention, 7 covers revenue, 8 covers acquisition and referral. Use it as a checklist to find where growth leaks, not as five dashboards to fill.
Turns product questions into metrics and data, checks the data for traps, runs or reads experiments and writes answers the team can act on. In smaller teams the product manager does much of this.
Event-analytics tools collect the events your app sends and turn them into funnels, retention curves, cohorts and user paths without writing SQL for each question. A spreadsheet or a warehouse with SQL can answer the same questions more slowly. The tool matters less than the tracking plan behind it: with vague event names and no definitions, any tool shows confident wrong numbers. For a quick check without a tool, the free retention calculator turns cohort counts into retention.
It's a branch of it, focused on user behavior inside a product. It borrows statistics, SQL and visualization from general data analytics, but its core units are users, events and cohorts over time.
It helps, but the harder part is asking the right question and defining metrics precisely. Many answers come from an event-analytics tool or a spreadsheet once the definitions are right.
One activation event, weekly or monthly retention by cohort, and a small set of well-defined events that feed them. Add more only when a real question needs it.
The free course Product Analytics: From Data to Decisions takes you through all eight questions on realistic Halves data, from events and funnels to retention types, LTV, payback and growth. Start with the first lesson, events, properties and users.
