Retention
Use Cases​
Maximizing user retention is a critical part of your business's success. Mitzu's retention feature lets you analyze how users or groups are retained by your product or marketing site.
Quick Start​
In this example, we will showcase how users are retained in our application. We consider users "retained" if they have paid their monthly renewal fee.
The goal of the analysis is to visualize our users' overall monthly retention rate for the last year. On top of that, we want to see how the retention rate changes over time with monthly granularity (cohort retention).
Step 1. Switch to retention and select events​
First, switch to the retention insight tab and select the events you want to analyze.
As the Initial event, I will select Subscription started, since we are only interested in users who
started a subscription.
Remember that you can set a segment filter on this event. For example, first event narrows the scope of the analysis to the user's first subscription.
We will now apply a property filter on Plan interval. We will select only users who performed Subscription started events with a monthly plan interval.
For the second event, we can pick Payment received.
Step 2. Select the retention window​
For this example, I will set the retention period to All groups.
The retention period is the period you want to analyze retention for.
All groups means we will analyze the month over month retention of our user base for the last year.
Alternatively, I could pick Month 1 retention, which would show the retention rate of users after their first month.
Step 3. Select trends vs. overall measurement configuration​
Let's select the 1Y time window for our retention analysis.
By default, Mitzu shows the change in retention rate over time. However, you can also visualize the retention rate as a whole (overall retention rate).
The results​
By selecting the Overall retention configuration with All groups as the retention period configuration, we will see the typical retention curve on our graph.
This shows the month-over-month retention rate for our users, regardless of which month they started their subscription, as long as the subscription was started within the last year.
Cohort retention / retention trend over time​
You can select the Monthly trend configuration for the trends vs. overall measurement configuration.
This shows you the change in retention rate over time for each of the last 12 months.
This chart can become very noisy if you have a long time window.
It is often better to visualize this as a heatmap.
However, if this is still too noisy, you can remove the All groups retention period config, select only months one and four, and visualize the result as a line chart.
Retention features​
Retention period​
The retention period is the configuration that lets you compare retention rates across different periods.
In this dropdown component, you can select multiple values simultaneously.
For example, by selecting Month 1 and Month 2, you will see the retention rate for the first and second months after the initial step.
The retention period <1 means Month 0, which measures the retention rate of users in the same Month as the initial step.
Mitzu calculates retention in relative periods. For example, if the retention period is set to 4 weeks, users are considered retained if they perform the retaining event between 21 and 28 days after the initial step.
In other words, the retention period doesn't refer to calendar months or weeks.
Retention window granularity​
The retention window selector lets you choose the granularity of the retention buckets:
Day- day-over-day retention.Week- week-over-week retention.Month- month-over-month retention (used in this guide's examples).Year- year-over-year retention.
Pick the smallest granularity that still produces meaningful cohort sizes — daily retention works for high-frequency products like messaging apps, while monthly or yearly is more appropriate for subscription products.
Custom holding constant​
Similar to Funnels, you can set a custom holding constant for the retention analysis.
To continue our example, we will set the Custom holding constant to subscription_id.
This measures the retention rate of users who performed the payment_received event with the same subscription_id as the one their subscription was started with. This is crucial for correctly attributing the retaining events.
The retaining entity is unchanged — retention is still measured for the entity set in Analyze uniques by (the user by default). The holding constant only adds a requirement that the retaining event shares the same value (here, the same subscription_id) as the initial event; it never lets a different user's event count as a retention.
As with funnels, the Analyze uniques by config changes the target entity for the retention analysis.
You can switch to Groups to measure the retention rate of groups that performed the payment_received event after a single user from the group performed the subscription_started event.
Measurement types​
By default, Mitzu measures the retention rate of users who performed the initial and retaining events. However, you can change this behavior by selecting a different measurement type.
Mitzu supports the Aggregate property measurement type. As with funnels, this configuration makes Mitzu aggregate any property from the last step (the retaining step).
For example, in our case above, we can select the Aggregate property measurement type and choose the Sum aggregation function with the Price event property of the payment_received event.
This visualizes the total retained revenue month over month.
Returning on or after vs. returning on specific days​
This configuration controls how Mitzu considers users retained.
If you select Returning on or after, Mitzu considers users retained if they performed the retaining event during or after the retention period.
Consider an app with sporadic usage where every user opens it once a month.
If I visualize the week-over-week retention rate of users who open the app on the last day of the month, for three weeks I would see a drop in the retention rate. To reduce this noise, you can apply the Returning on or after configuration. This makes Mitzu consider each week before the retaining event as a retained week.
In contrast, the Returning on specific days configuration makes Mitzu consider users retained only for the exact time period (week, month, etc.) in which they performed the retaining event.
Can the retention rate go up?​
Yes, and whether that is expected depends on the measurement type and on whether the base stays fixed.
Returning on specific days: the rate can move up and down freely. Each period asks its own question — did the user return in that period. Someone can return in week 1, skip week 2 and come back in week 3, so a row that rises is normal, not a defect.Returning on or after: the retained group can only shrink as the periods go on, because anyone retained in week 3 was also retained in week 2. With a fixed base the rate therefore only falls.
Cohort views — the heatmap and the daily, weekly and monthly trends — always divide by the full cohort, so the base is fixed and the rule above holds exactly: Returning on or after only falls along a row, Returning on specific days may not.
Overall retention with the Eligible users base is the exception. There the base shrinks along with the retained group, because a later period counts only the users who have had that long to return. The rate can rise at the end even with Returning on or after. See Incomplete periods for why, and what to do about it.
Retention attribution​
This setting allows you to choose the attribution of the retention. It has no visible effect on the "Retention rate" aggregation type (which is the default aggregation type).
Currently, we support two types of retention attribution:
- Every event - each event is considered a "retaining" event of the retention insight.
- First event - only the first event of the retaining step (segment) is considered a retaining event.
Loose timestamp comparison​
Retention often combines events from different sources — for example backend and frontend events — whose clocks are not always perfectly aligned for the same user interaction. When that happens, a retaining event that logically falls inside a retention period can land a few seconds before the period start and the user is counted as not retained for that period.
Enable Loose timestamp comparison (the checkbox in the retention period menu) to allow a 1 minute grace period when deciding whether a retaining event falls within a retention period. With it on, a retaining event can happen up to 1 minute before the period start and still count.
The grace period only relaxes the start of each retention period, so returns never leak across adjacent buckets. The default comes from the Loose timestamp comparison setting in your workspace's insights settings, which is on for retention in new workspaces, and can be overridden per retention insight.
On ClickHouse the grace period is not applied — loose timestamp comparison only counts events at the exact period start (>=). Other warehouses use the full 1 minute grace.
What it does to Day 0 / Week 0 / Month 0​
Period 0 starts at the initial event itself, so this setting decides what the first retention period measures:
- On: a retaining event at the same moment as the initial one already lands in period 0. When the retaining step is identical to the initial one — same event, same filters — every initial event is its own return, so period 0 is 100% by construction. Any difference between the two steps (a different event, or a filter on one side) breaks that, and period 0 measures real returns again.
- Off: the retaining event has to land strictly after the initial one, so a retaining event at that same moment doesn't count. With identical steps, period 0 means the user performed the event a second time.
Both readings are correct, but they are not comparable: don't compare a period 0 measured with the setting on against one measured with it off.
Trend vs. overall measurement configuration​
As discussed in our example above, retention insights also support trend and overall measurement configurations.
Retention trends are called daily/weekly/monthly trend. Once selected, they help you understand how your retention rate changes over time.
Overall retention shows how the passage of time affects the retention rate for users who performed the initial event and then repeatedly performed the retaining event.
Retention base​
Retention is sensitive to periods that have not fully elapsed yet: a user who performed the initial event two weeks ago has not had the chance to return in Week 5. The Retention base dropdown in the Retention period menu (the clock button that reads Returning on each week) decides how such users are counted. The chart header always shows which base is in effect, and the workspace default lives in Insight settings.
- Eligible users (the default): a user counts towards a period only once that period has fully elapsed for them — only users who could have returned are in that period's base. The later periods therefore rest on fewer users. Hover the chart header badge to see the rule.
- All users: every user stays in the base for every period. Users who have not reached a period yet count as not returned, so the last periods dip. This is what a hand-written retention query usually produces.
The two bases give identical numbers once every period has elapsed for everyone in the date range. They only differ at the recent end of the chart.
The base applies to overall retention only. Cohort views — the heatmap and the daily, weekly and monthly trends — always divide by the full cohort so that every cell in a row stays comparable, and the setting makes no difference to them.
Incomplete periods​
Whatever the base, some periods have not finished for everyone yet. Mitzu shows them and marks them, so you can see the latest values without mistaking them for final ones.
- Overall retention with the
Eligible usersbase: the last period, which even the earliest users in the date range have not finished yet, is drawn dotted and marked with*. It shows the users who are already inside that period, and its value can still rise until the period closes; hover the point to see how many users it is based on. With theAll usersbase every user is in every period from the start, so nothing is marked. - Cohort views (the heatmap and the daily/weekly/monthly trend) always divide by the full cohort, so every cell in a row is comparable. A cell whose period has not finished for every member of the cohort shows the value so far, marked with
*and a dotted outline; that value can only rise as time passes. A cell whose period has not started for anyone is left blank.
The chart header shows an Incomplete periods marked badge whenever something is marked. Untick Show incomplete periods in the More menu to leave those periods out of the chart and the table instead; the badge then reads Incomplete periods hidden. The workspace default for new charts lives in Insight settings.
When the base is Eligible users, the overall curve can tick up at the very end: the last periods are measured on the users who joined at the start of the date range, and those are often long-time users who only look new because the range starts there. If you want cohorts of genuinely new users, add the Nth event segment filter to the initial step with Nth event set to 1 and Type set to Ever, so only each user's first-ever occurrence of the event starts a cohort. This is not a data problem, it is the base rule at work.
Data sampling​
Retention queries are sensitive to long time horizons. Mitzu can downsample the events it reads and the entities it analyzes to keep queries fast — see Data sampling and resolution for the full description of Event resolution and Uniques sampling.
Comparison​
The Comparison feature lets you analyze data trends by comparing them against those from a previous time period. For example, you can compare data points from the last month with data from the preceding month.
To activate the comparison, select the desired comparison window from the dropdown menu.
In retention analysis, comparisons are currently available using absolute values. Additional comparison methods will be introduced in future updates. For information about upcoming features, please contact us at support@mitzu.io.
Comparison with absolute values​
When using comparison with absolute values, the chart displays both:
- the data points from the selected insight time window, and
- the data points offset by the chosen comparison time period.
This lets you view both trends simultaneously and identify changes or patterns between the two time windows.
