This article helps you get started with the Metrics that Matter - Part I report from the User Retention Playbook.

We recommend opening the report in another window or tab so you can consult the methodology and set-up steps as you explore the report. If you'd like a bit more of an overview of how Mode Playbook reports work generally, please read this article.

Report overview

Simply monitoring retention often isn't enough---we also want to know what drives retention, and how we can increase it. This report takes helps answer that question. It shows which actions most strongly correlate with retention. In other words, it helps determine whether or not a user adding things to their cart---or entering their email, or sending two messages, or returning three times---is most predictive of them becoming long-term users of your product. While it's important to note that correlations are NOT causal, it does provide a good place to start (or, waggle its eyebrows suggestively and gesture furtively while mouthing 'look over there'). This report is designed to find that place to start.

Reading this report

This report compares the number of times users' take actions in their first week to the likelihood that they return in their second week (7 to 14 days after they first sign up). For those interested in different length windows (maybe you want actions taken in their first three days, and care about 28-35 day retention), both of these windows are adjustable---the first 7-day window is defined on lines 23 and 24; the second is defined by line 35.

The graphic on the report explores which metrics can be most valuable for predicting retention. The left side of each row lists the an action and a count. That row corresponds to the users who took that action at least that many times in their first week.

The right side of the table shows a series of colored bars. These bars explore how each feature correlations with retention in several ways. Though the metrics shown vary, each colored bar always represents the same cohort of users:

• Red-orange bars: These bars represent users who retained, but didn't do the listed action in their first week.
• Purple bars: These bars represent users who both retained and did the listed action.
• Blue bars: These bars represent users who took the action but didn't retain.

You can sort each column by clicking on the table header. If you sort by the column with the bars, it will sort by whichever metric is showing in the table at that time.

While this example shows how taking an action between 1 to 10 times correlations with retention, this range can be adjusted. To change these counts to something else, add or remove values from the array on line 183 of the presentation:

metricCounts = [1,2,3,4,5,6,7,8,9,10]

Interpreting these results

This report allows you to uncover a few things. The first step allows you to see how retention rates change as feature use increases. For some actions, like home pages visits in the example, retention rates increase steadily as users take the action more. For other actions, such as searching, retention rates barely change. And for some, like sending messages, retention rates level off after the action's been taken a few times.

The second step lets you see how common these actions are. In addition to helping you better understand retention, this can also help describe what new users do when they first start using your product.

Steps three and four help you find which actions most strongly correlate with retention. Because stronger correlations mean that users who take that action are likely to retain and that users who retain are likely to take that action, this metric weeds out infrequent actions that are only taken by power users.

Using this with your data

This query the standard events and users tables. The event table should include both the events that you want to measure retention against, and the events that you want to use to define someone who retained. These retention events are typically logins, purchases, or page views.

The names of these events also have to be defined in the query, in the final SELECT statement. For each event you define in the event table that you want to consider, you should add a line to this SELECT statement like the following:

COUNT(CASE WHEN e.event_name = [your event] THEN e.user_id ELSE NULL END) AS [your_event]

Step-by-step instructions

1. From the report, click the more button to the right of Export and then click Duplicate.

2. In the box that pops up, select the Workspace you want to duplicate the report to.

3. Modify the common table expression in lines 4-19 to reference your database tables and relevant columns.

   

4. Modify lines 25-29 to reference the column names you added in Step 3. Follow the format described above. Add additional events as needed.

   

5. Click Run.

6. Click Report and then Publish to change the report name and description.

7. Share with your colleagues.

Database notes

One part of this query can be database-specific. For details on how to adapt these to your database, see our Database Notes.

• Adding or subtracting a fixed time period to a date. This function is used on line 23, 24, and 34.