Product & Analytics: How to Decide What to Build, What to Measure, and What to Learn Next

If you remember only a few things from this page:

• Product analytics is the study of how people behave inside a digital product, usually through events, funnels, cohorts, retention and feature usage.
• Product strategy and product analytics are connected, but they are not the same thing. Data can inform a decision; it cannot decide what your business should care about.
• More tracking is not automatically better. Track the events and properties that help answer important product questions.
• Quantitative data is good at showing what is happening. Qualitative research often helps explain why. Experiments are useful when you need stronger evidence about what caused the change.
• A metric becomes useful only when you know what decision would change because of it.
• Do not build a metric list. Build a metric system: an outcome you care about, actionable inputs, guardrails that protect against unintended harm, and diagnostic metrics that explain movement.
• Not every product decision needs an A/B test. The strength of evidence should match the cost, reversibility and uncertainty of the decision.
• AI can make analysis faster, but ambiguous event names, broken identity, duplicate events and weak business context still produce weak answers.

The rest of this page explains how these pieces fit together.

I have worked on analytics setups involving GA4, Google Tag Manager, funnels, lifecycle reporting and campaign measurement.

One lesson kept repeating: a technically correct tracking setup can still leave you with a weak decision system.

Events can fire correctly. Dashboards can populate. Conversion numbers can reconcile. You can still be left asking:

So what should we actually do differently?

That changed how I think about analytics.

Instrumentation is plumbing. Useful analytics starts when the data is tied to a question, a hypothesis or a decision.

For example, tracking transfer_started and transfer_completed in a fintech product may tell you the overall completion rate. But if the question is why completion changed, those two events alone may not be enough. You may need context such as user tenure, KYC state, funding method, transfer type, acquisition source or previous behaviour.

The event is not the insight. The event is evidence.

Product analytics is the practice of collecting and analysing behavioural data to understand how people use a digital product.

Typical questions include:

• Where do users abandon onboarding?
• Which behaviours are associated with activation?
• Which features are actually adopted?
• Do users who complete a particular action retain better?
• How does behaviour differ between new and returning users?
• Which product changes improved conversion or engagement?

Most product analytics systems are built around events, properties, users or accounts, funnels, cohorts and retention analysis.

That sounds technical, but the important word is not analytics.

It is product.

The purpose is to improve decisions about the product and the outcomes it creates for users and the business.

Teams often collapse three different problems into one vague request for "more data."

They are not the same problem.

Product strategy should not be a dashboard sorted by metric size.

Discovery should not be a backlog vote.

Analytics should not be a screenshot used to justify a decision already made.

Each discipline reduces a different kind of uncertainty.

Product Talk describes product discovery as the work teams do to make decisions about what to build, starting with an outcome, understanding customer opportunities, and testing solutions. SVPG similarly distinguishes outcome-oriented product work from feature delivery where teams simply execute a pre-decided roadmap.

The distinction matters because shipping is not evidence that the right problem was solved.

I prefer to think about product work as a loop rather than a roadmap that moves only forward.

1. Define the decision

Start with the decision, not the dashboard.

Examples:

• Should we change this onboarding step?
• Should we invest in this feature?
• Is this drop-off a product problem or an acquisition-quality problem?
• Should we expand this workflow or simplify it?
• Did the release create durable behaviour change?

If you cannot name the decision, you probably do not yet know what data you need.

2. State what you currently believe

Write the hypothesis before looking for confirming evidence.

For example:

Users are abandoning onboarding because we ask for information before they understand why it is needed.

That is much more useful than:

Onboarding conversion is low.

The first statement gives you something that can be challenged.

3. Choose the evidence that could change your mind

This is where teams often default to whatever tool they already have open.

Instead ask:

• Do I need behavioural data?
• Do I need to watch sessions?
• Do I need customer interviews?
• Do I need support tickets?
• Do I need a usability test?
• Do I need an experiment?
• Do I need cohort analysis?

The best evidence source depends on the question.

4. Instrument or research only what is needed

More data can create more confidence without creating more truth.

Amplitude currently recommends starting with a small set of critical events and warns that tracking everything can bury useful signal under unnecessary data. A tracking plan should define what events mean, which properties matter and why the data exists.

That is a better starting point than instrumenting every click because someone might need it later.

5. Look for the first meaningful change

Do not jump immediately to the final business metric.

If you changed onboarding, the first meaningful effect may be:

• completion rate
• time to value
• activation behaviour
• error rate
• feature discovery

Then look downstream:

• retention
• repeat usage
• monetisation
• support burden
• quality or fraud metrics where relevant

A local improvement can create a downstream problem.

6. Decide what the evidence actually supports

There are at least four possible conclusions:

1. The hypothesis looks supported.
2. The hypothesis looks wrong.
3. The result is promising but not causal.
4. The data is too weak to decide.

The fourth answer is uncomfortable, but often more useful than pretending the dashboard is conclusive.

7. Update the model, not just the backlog

The output of analytics should not always be another feature.

Sometimes the right next step is:

• remove something
• change a default
• improve the message
• fix instrumentation
• segment the audience differently
• run another test
• interview users
• leave the product alone

Good analytics should make your understanding of the product better, not simply make the roadmap longer.

Before committing engineering time to a product change, I would want answers to questions like these.

Problem

1. What user or business outcome are we trying to improve?
2. What evidence tells us the problem is real?
3. Which users experience it, and how often?
4. Are we seeing a symptom or the underlying problem?

Hypothesis

5. What do we believe is causing the problem?
6. What evidence would prove that explanation wrong?
7. What behaviour should change if our hypothesis is correct?

Measurement

8. Which event or outcome represents that behaviour?
9. Which properties or segments are required to interpret it correctly?
10. What downstream metric could get worse even if the primary metric improves?

Decision

11. What result would make us ship, iterate, stop or investigate further?
12. Do we need causal evidence, or is directional evidence enough for this decision?
13. What is the smallest useful test that can reduce uncertainty?

You do not need all thirteen answers for every tiny change.

The point is to prevent a common failure mode: building first and deciding what success means after the numbers arrive.

A useful way to see the difference between analytics and strategy is to look at Airbnb's booking experience.

In Lenny Rachitsky's account of his time at Airbnb, the team became increasingly concerned that a large share of booking requests were being rejected or ignored by hosts.

The metric exposed a real problem: a guest could find a home, decide to book it, enter their information, and still fail to get a reservation.

At that point, imagine you owned the problem.

You could:

• send hosts more reminders
• make acceptance faster
• rank responsive hosts higher
• make rejection harder
• improve the request flow
• send the guest to more alternatives after a rejection

Those are all reasonable optimisation ideas.

The team tried several improvements around host acceptance and the booking flow. They helped, but they did not fundamentally change the experience.

The more important question became:

If we designed the ideal booking experience from scratch, why should a guest have to ask permission to book an available home at all?

That reframed the problem from "How do we improve request acceptance?" to "How do we make booking feel instant?"

Airbnb already had a feature called Instant Book. Instead of treating it as one feature among many, the team made expanding instant booking a strategic direction. In his account of the work, Lenny Rachitsky describes Instant Book growing from roughly 5% of bookings to more than 80% over the following two and a half years.

Airbnb still describes Instant Book as a way for guests to book without waiting for host approval, and its current search documentation says listings that can be booked instantly may rank higher because the booking response is automatic.

What this case teaches

The rejected-booking data mattered.

But the data did not say:

Build Instant Book.

It said:

Something important is broken between intent and successful booking.

Product analytics helped reveal and quantify the friction. Product judgment reframed the user experience. Strategy chose a direction. Product changes implemented that direction. Measurement then showed whether the system improved.

That sequence is much closer to how strong product decisions actually happen than "look at the biggest funnel drop and fix it."

This comparison is useful because the tools increasingly overlap.

The boundary is not absolute.

GA4, for example, uses events to measure interactions on websites and apps, and it can support funnels, custom events and user-level dimensions. Dedicated product analytics platforms tend to make behavioural exploration, cohorting, retention and product-specific analysis more central to the workflow.

Choose the system based on the questions you need to answer, not the category printed on the vendor's website.

Tools are useful when they reduce the distance between a question and reliable evidence. They are not a substitute for a clear question, a clean data model or product judgment.

Here is a practical way to think about the stack. These are examples, not endorsements, and capabilities increasingly overlap.

A small team does not need every category. A single platform may cover several jobs well enough. The better selection criteria are the questions you need to answer, the maturity of your tracking, privacy requirements, implementation effort, cost and whether the people making decisions will actually use the tool.

For example, if a funnel shows that users drop at step three, a product analytics tool can quantify the drop. A replay tool can help you observe what users encountered. A usability test or interview can reveal the reasoning behind the behaviour. If you then change the experience and need causal evidence, an experiment may be appropriate.

The tools change. The evidence logic should not.

Product teams can measure hundreds of things. That does not mean they should optimise all of them.

A useful metric tells you something about value, behaviour, friction or economics.

The question is not:

What is the best product metric?

It is:

What metric gives us the clearest evidence for the decision we are making?

A serious analytics setup needs more than one KPI.

I find it more useful to separate metrics into four jobs:

This is why a North Star Metric should not become a religion.

Amplitude's North Star framework treats the North Star and its inputs as a system: the outcome expresses value, while a small set of inputs gives teams something more actionable to influence. Reforge makes a similar distinction between outcome metrics and the input metrics that drive them.

The guardrail matters because almost any local metric can be gamed accidentally.

Imagine an onboarding change that increases completion by making identity checks less visible. Completion may rise, while downstream verification failures, support contacts or fraud risk also rise.

A dashboard that shows only the success metric would call that a win.

A metric system would ask whether the product became healthier.

Define the metric precisely enough to query

A metric name is not a metric definition.

"Activation" is incomplete until you specify:

• who qualifies
• what behaviour counts
• within what time window
• which exclusions apply
• how identity is handled
• how the metric is segmented
• what would invalidate the interpretation

This is one reason Lenny's guidance on product metrics repeatedly emphasizes that the right metrics depend on the product and business model rather than on a universal dashboard template.

This is one of the most important limitations of behavioural data.

Suppose users who use Feature A retain better.

Possible explanations include:

• Feature A creates value and improves retention.
• Highly engaged users were already more likely to discover Feature A.
• Feature A is available only to a higher-value segment.
• Users are forced through Feature A as part of another workflow.
• A third factor causes both Feature A usage and retention.

The chart shows an association.

It does not automatically tell you which explanation is true.

That is why I prefer data-informed over data-driven as a mental model.

Behavioural analytics is one evidence source. Interviews, usability research, customer support, market context, experiments and domain knowledge can all change the interpretation.

Product Talk makes a similar point in its guidance on product decisions: strong decisions should draw on multiple data points and research activities rather than one isolated interview or one test.

There is a second mistake on the other side of the spectrum: believing that a decision is irresponsible unless an experiment proves it.

That is not how every product should operate.

In Lenny's profile of how Linear builds product, co-founder Karri Saarinen explains that Linear does not use project-level metric goals or A/B tests as the default decision mechanism. The company uses a high-level North Star, customer understanding, product taste and judgment because many B2B product changes have adoption cycles and qualities that do not fit neatly into rapid experimentation.

That does not mean "ignore the data."

It means match the evidence method to the decision.

A rough rule:

The question is not whether a team is "data-driven."

The better question is whether the evidence is strong enough for the decision being made.

Event naming looks like a technical detail until two teams disagree about what an event means.

Consider an event called:

payment_completed

Does that mean:

• the user clicked Pay?
• the payment was submitted?
• the payment provider authorised it?
• the settlement completed?
• the recipient received funds?

Those are different states with different business meanings.

A clean event taxonomy should define:

• event name
• exact trigger
• event properties
• user/account properties
• source
• owner
• business purpose
• expected downstream use

Amplitude's current documentation describes a tracking plan as a source of truth for events and properties and recommends aligning tracking with business objectives before instrumentation.

This becomes even more important when multiple teams use the same data.

Event names are only one source of analytics errors. Identity can break the analysis just as easily.

Suppose someone browses anonymously, creates an account, signs in on another device and later uses the product as part of a company account. If those identities are not connected correctly, the same person can appear as multiple users, pre-signup behaviour can disappear from the journey, and retention or conversion can be miscounted.

Amplitude and PostHog both document identity resolution as a core part of accurate user-level analysis. In B2B products, the question may become even more complicated because you may need both a person-level view and an account-level view.

Before trusting a lifecycle metric, ask:

• What represents a unique user?
• What happens before login?
• When and how is an anonymous user identified?
• What happens across devices?
• Do we analyse people, accounts, workspaces or all three?
• Are test users, employees and bots excluded where appropriate?

Privacy belongs in the same design conversation. Do not send sensitive information simply because an analytics tool technically accepts custom properties. Google Analytics explicitly prohibits sending personally identifiable information such as email addresses or phone numbers, and replay tools require careful masking and capture controls.

The practical rule is simple: collect the minimum data required to answer the product question, define who can access it, and verify what is actually being captured.

In 2026, major product analytics platforms are embedding natural-language querying, automated investigations and AI-assisted analysis into their workflows. Amplitude offers AI-assisted analysis, Mixpanel has built AI agents into its analytics experience, and PostHog exposes analytics and replay workflows through AI interfaces and MCP.

That can reduce the time between a question and an answer.

It does not remove the need for clean data.

Amplitude's guidance for AI ingestion makes the dependency explicit: AI systems read event names, properties, descriptions and business context. Ambiguous or stale taxonomy can produce incorrect answers.

This creates an important shift:

When querying becomes easier, defining the data correctly becomes more valuable.

An AI agent can generate a funnel in seconds. It cannot rescue an event called completed when nobody agrees on what completion means.

Analytics theatre is when the organisation looks data-driven without becoming better at decisions.

It can look like:

• dashboards nobody acts on
• dozens of KPIs without priorities
• tracking hundreds of events "just in case"
• post-launch metrics chosen after the result is known
• A/B tests without meaningful hypotheses
• feature adoption celebrated without checking retention or value
• correlation presented as causation
• one blended conversion rate hiding very different cohorts
• data used to win an argument rather than test an assumption

The fix is not another dashboard.

It is a stronger connection between decision → evidence → action.

Product does not sit on one side of the company while growth sits on the other.

Acquisition determines who enters the product. Product experience determines whether they reach value. Retention determines whether that value repeats. Monetisation determines whether the system creates economic value. Measurement determines whether we understand any of it correctly.

That is why this pillar connects directly with Growth & Marketing.

The same user journey can be viewed through different questions:

• Growth: Where is the system constrained?
• Product: What should we change to create more value?
• Analytics: What evidence tells us the change mattered?
• Psychology: Why might users behave this way?

The disciplines are different. The customer journey is not.

This pillar is the map. The deeper guides will handle the individual problems in more detail.

Product Strategy

How to decide what to build, for whom and why, including customer problems, strategic choices, prioritisation and the difference between a strategy and a roadmap.

Product Growth

How the product itself contributes to acquisition, activation, retention, expansion and referral.

Marketing Measurement & Attribution

How to distinguish tracking, attribution and causal measurement so that teams understand what is actually driving growth.

As those guides go live, this page will link directly to them.

When somebody asks for another dashboard, event, report or experiment, I like to ask:

What decision becomes easier if we know the answer?

If nobody can answer that, the analytics request probably needs more thinking before it needs more instrumentation.

That question does not solve product strategy.

But it forces the conversation back to the reason analytics exists in the first place.

What is product analytics?

Product analytics is the collection and analysis of behavioural data about how users interact with a digital product. Teams use it to understand activation, funnels, engagement, feature adoption, retention, conversion and other user behaviours.

What is the difference between product analytics and web analytics?

Web analytics usually focuses on how visitors arrive at and navigate a website, including traffic sources, pages, sessions and website conversions. Product analytics focuses more heavily on behaviour inside a product across time, including user journeys, feature usage, funnels, cohorts and retention. Modern tools increasingly overlap, so the right choice depends on the questions you need to answer.

Can GA4 be used for product analytics?

Yes, for many use cases. GA4 uses an event-based model and can capture custom events, event parameters and user properties across websites and apps. Teams with deeper behavioural-analysis needs may also use dedicated product analytics tools for workflows such as advanced cohorts, retention analysis, feature adoption and self-serve exploration.

What product analytics metrics should I track?

Start with the metrics tied to your product's value and the decisions you need to make. Common examples include activation, time to value, funnel conversion, retention, churn, feature adoption and monetisation. Do not track a metric simply because another company uses it.

How many events should a product track?

There is no universal number. The better principle is to start with the critical user behaviours needed to answer important business and product questions. Tracking too many events can make the system harder to govern and the signal harder to interpret.

What is a North Star Metric, and do I need only one?

A North Star Metric is a high-level measure intended to represent customer value and long-term product success. In practice, one metric is rarely enough to run the product. Teams usually also need actionable input metrics, guardrails and diagnostic metrics so they can understand what is driving the outcome and whether improvement in one area is creating harm elsewhere.

Is product analytics enough to decide what to build?

No. Product analytics is one evidence source. Decisions about what to build should also consider customer needs, qualitative research, strategic fit, market context, business constraints and, where appropriate, experiments.

What is the difference between product strategy and product analytics?

Product strategy sets direction: which customers, problems and outcomes the product should prioritise and why. Product analytics provides behavioural evidence that can inform those choices and evaluate what happens after changes are made. Analytics supports strategy; it does not replace it.

How does AI change product analytics?

AI can make querying, anomaly detection, investigation and reporting faster. But AI still depends on the quality and meaning of the underlying data. Clear event definitions, consistent properties and good governance become more important when automated systems are interpreting the data on your behalf.

1. Amplitude: What Is Product Analytics?
2. Amplitude: Plan your taxonomy
3. Amplitude: What events do you need?
4. Amplitude: Preparing data for AI ingestion
5. Mixpanel: What is product analytics? A complete guide for 2026
6. Amplitude: About the North Star Framework
7. Reforge: How to Choose & Measure North Star Metrics
8. Lenny's Newsletter: Getting better at product strategy
9. Lenny's Newsletter: How Linear builds product
10. Lenny's Newsletter: The most important consumer metrics to track
11. Airbnb: Understanding Instant Book
12. Airbnb: How search results work
13. Product Talk: Product Discovery
14. Product Talk: Product Decisions
15. SVPG: Build to Learn vs Build to Earn
16. Google Analytics: Set up events
17. Google Analytics: Avoid sending personally identifiable information
18. Amplitude: Track unique users
19. Mixpanel: Product Intelligence Platform
20. PostHog: Product analytics
21. PostHog: Anonymous vs identified events
22. Microsoft Clarity: Session recordings and heatmaps
23. Statsig: Product development and experimentation platform
24. Optimizely: Experimentation
25. Maze: User research and testing
26. Dovetail: Customer intelligence and research

I’m Saurav Mishra. I work across growth, product, marketing and analytics, and I also build and experiment with digital products using modern AI and development tools.

LinkedIn · Explore my case studies →