How to Build a Retention Report in Mixpanel
Acquisition numbers look good in board decks, but retention determines whether a product grows. Mixpanel's Retention report shows what share of users come back after their first interaction, broken down by day, week, or month. Built well, it tells you whether a product change improved stickiness. Built carelessly, it produces a curve nobody can act on.
This guide walks through choosing the right start and return events, picking retention criteria, setting time buckets, adding breakdowns, and comparing cohorts. It assumes your Mixpanel project already has reliable event tracking in place.
Measuring a change in Mixpanel? Write the experiment brief before you ship.
Describe the change and the number you want to move. Vantage turns it into a written brief you can share with eng and data before anything ships.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds an experiment brief from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Define what retention means for your product
Before building the report, decide which action shows a user got value. Logging in is rarely the right return event; it measures habit, not value. For a project tool, the return event might be creating or updating a task. For an analytics product, it might be viewing a report. Write the definition down and get agreement from the team.
- Identify the action that represents real value for users
- Decide the natural usage frequency: daily, weekly, or monthly
- Agree on the definition with product and leadership
Create the Retention report
In Mixpanel, create a new report and choose Retention. Select the starting event, which defines when a user enters a cohort, and the return event, which counts as coming back. A common start event is a signup or first key action. You can choose to count only the first time a user performs the start event, which is useful for new-user retention.
- Create a new Retention report
- Select the start event, such as Sign Up
- Select the return event that represents value
- Choose whether to use the first occurrence of the start event
Choose retention criteria and time buckets
Mixpanel lets you count a user as retained if they return in a specific period, or on or after that period. Period-specific retention shows the share of users active in week 4, which reveals the true shape of the curve. 'On or after' retention is always higher and answers whether users ever came back. Set the time unit to match your product's natural frequency.
Read the curve
Look at where the curve flattens. A curve that keeps declining toward zero indicates a retention problem. A curve that flattens at some level shows a group of users who found lasting value. The flattening point and the level it flattens at are more useful than any single day's number.
- Find the period where the curve flattens
- Note the retention level at that point
- Compare early periods to see where most drop-off happens
Add breakdowns to find drivers
Break down retention by user or event properties such as acquisition channel, plan, platform, or whether the user completed onboarding. Differences between segments point to what drives retention. If users who invited a teammate retain far better, that becomes a hypothesis for an onboarding change.
Compare cohorts over time
Switching to a view of retention by start date shows whether recent cohorts retain better than older ones. After shipping an onboarding change, this is how you see whether new cohorts behave differently. Give changes enough time to show up; weekly retention needs several weeks of data per cohort.
- Group users by start week or month
- Compare cohorts before and after a product change
- Wait until cohorts have enough periods of data before drawing conclusions
Save the report to a board
Save the report and add it to a board your team reviews regularly. Add a short note explaining the start and return events, so anyone reading the chart understands what it measures.
Common mistakes
Using any event as the return event
Counting any activity as a return inflates retention with users who opened the app and left. Choose an event that represents real value.
Reading 'on or after' as period retention
'On or after' numbers look healthier because they count any return after the period. Know which criteria you are using before comparing with benchmarks.
Comparing incomplete cohorts
Recent cohorts have not had time to reach later periods. Compare only periods that all cohorts have completed.
Tips
Build one report for new-user retention and one for all active users; they answer different questions.
Pair retention with a funnel of onboarding steps to see which step correlates with retained users.
Annotate boards with release dates so cohort changes can be traced to product changes.
Revisit your return event definition when the product's core value changes.
How Vantage helps
A retention report shows where users drop off; the next step is turning that into a scoped fix. In Vantage, PMs bring the finding in as context, generate a PRD with success metrics tied to the retention curve, and produce dependency-aware tickets that push to Linear or Jira.