Retention and Daily Active Users Explained. | by 💡Mike Shakhomirov | Towards Data Science

Have you ever wondered how to reduce user churn and save money spent on user acquisition? This article is about how to count those users who stay in your App in order to understand what makes them stay.
Marketers who have been tasked to create custom user retention dashboards.
Analysts who might want to create better reports.
AI and ML experts who will definetely want to predict user churn.
Firebase users who might want to question their retention numbers.
Basic knowledge of SQL
Google developer account. It’s free.
BigQuery access. It’s free.
Data Studio access. It’s free.
If you like the template you can download it from here. It’s free. All datasets are included in this template. Read how to copy it in the end of this article.
I will be using BigQuery (BQ) and Data Studio (DS) to work with data.
All data we need will be included in SQL below. So it’s a really small dataset and it won’t cost anything to run it.
SQL can be easily adapted to any other datawarehouse but it’s just easier to run it in BQ and visualize in DS. So don’t hesitate to try it.
Let’s take a look at some user activity example (just copy paste it and run it in BQ):
This will give us a mocked up user activity table:
If you use Firebase or Google Analytics you can extract the data and upload it in BigQuery for further analysis. I wrote about it in one of my previous articles here:
towardsdatascience.com
Now when we have the data we need a view to see if a user was active during each day after registration and then count those who were active.
To count active users per day in BigQuery you can use this SQL below. A bit ugly but something like this should work:
For many marketers the metric that represents the most interest would be 30 day retention because if a user was active on day 30 that means it has been using an App for 30 days. If a user was active at least once during the last 30 days it makes that user a monthly active one (MAU).
However, it’s not necessarily true that this user is an active one.
We need to distinguish between measurable user activity (e.g. K-means clustering of your user base) and simply being active as MAU.
For example, if a user opened your App and then uninstalled it — is it an active user? Yes, it is.
In this article I will be talking about counting user logons and producing DAU/MAU metrics.
New active users are the users that, in a specified period, interact with your app for the first time. (eg. created an account) and then start using it daily, weekly or monthly. These users are often heavily influenced by the user onboarding process they experience.
Returning active users are the users that keep coming back to your app after the period of inactivity and are closely related to the retention and recurring revenue metrics of your business.
We don’t really need to use aggregation in SQL and materialize it because our dataset is relatively small and Data Studio can do aggregation for us.
Datasource:
You can see that I created a new field called user_pseudo_id_percent . We will use it to show the percentage of retained users later.
Now let’s add a new column week_ which we will use to calculate retention per week. Try running this bit of SQL and see what happens:
select ceil(DATE_DIFF('2020-10-25', '2020-10-10', DAY)/7) AS week_diff
For example, in Firebase we have a similar thing called Weekly retention cohorts.
Let’s add this new field to our datasource:
To accurately report on retention, your analytics tool needs to be able to recognize the same user even if they log in six months later using a different browser or device. This might become a real challenge because
... in real life it becomes way more complicated when users have different accounts and multiple devices.
Let’s assume every client Application will log in several times a day when running. Each logon event can be recorded to your Data lake/Data warehouse along with the user id and the device id.
This is pretty much how Firebase logs users. You will have user_pseudo_id by default and user_id can be enabled like so:
firebase.google.com
There is a lot of things you can do to listen in on those events and even pre-process them to just the data you need before sending them to the Data warehouse. Things like Kinesis or Kafka can easily stream event data from your microservices.
— So what is an active user?
— It depends on the business logic you want to apply to your datasets and reports.
Active users are often reported as Monthly active users (MAU), Weekly (WAU), and Daily (DAU). Let’s illustrate active users a little bit more with a visual example:
In the illustration above, you can see user logons each day after registration. Each coloured circle implies a user being active that day. User 'J' (‘J’ is for Johnas) was active during each week 1–6. However, it still counts as 1 MAU (Monthly active user). So we can see 2 Active Users for that month, because all of the users were active at least once during that month. You probably noticed that user id ‘E01’ (‘E’ is for Emma) has 2 devices (user_pseudo_id 2001 and 2000).
We calculated users and that’s why it is 2 (not 3) MAU. So it totally depends on methodology as you can see.
In this case active user numbers may easily double or treble. Just imagine Johnas creating multiple accounts from his one device.
We will take a better look into how to tackle this issue later.
If we narrow it down to weeks (WAU) we can see 2 active users during week 1–3 when during the week 4 there is only 1. I saw people often questioning the user activity numbers when analyzed it on different time frames (monthly, weekly, daily) and thinking there is something wrong with it when it is not.
If a user visits your app every day of the month, that’s a single user. Not 30 different users.
If you like the template above you can simply copy it from here.
Dataset:
We might want to answer the following questions:
How many of all new users were active on day 1,2,...,n?
This is Daily retention cohorts. It’s day number after user registration (not date). Some accounts may have been registered on different dates.
How many of all new users were active on week 1,2,...,n?
This is Weekly retention cohorts (week numbers after the registration date).
How many of all new users were active on month 1,2,...,n?
Monthly retention cohorts (month numbers after the registration date).
Let’s create a dataset for our retention cohorts.
To answer the first question
How many of all new users were active on day 1,2,...,n?
I will use Data Studio with the dataset above and default aggregation set to MAX.
I will use day_number, week_diff and month_diff as dimensions, rows and columns in my pivot table.
I will use user_pseudo_id (device_id) to count unique users as this is pretty much the standard in Firebase for example.
Result:
How many of all new users were active on week 1,2,...,n?
Remember that Firebase retention view that looks familiar? It simply goes 5 weeks backwards and adds first_seen_week to rows:
We can achieve this in Data Studio by adding first_seen to our dataset:
Alternatively we can add first_seen_week:
EXTRACT(WEEK FROM first_seen) AS first_seen_week
I’ve added another device_id which will be first seen on November the 1st and the new dataset will be (remember now we need to use first_seen in partitions for row groupings):
How about a better visualization for retention?
What if we could display our retention rates in calendar style?
We usually use pivot tables to visualize data over retention cohorts, but it can often be insightful to see that same data overlaid on a calendar.
In the next example I will make an assumption that each 30 day retention period equals one month. So it’s not a calendar month really but nothing stops you from displaying retention rates overlaid on calendar months instead of retention cohorts. Just remember it will have a completely different meaning.
Indeed, in many cases you would probably want to display retention simplified like so:
It makes sense to use activity date instead of daily, weekly or monthly cohorts as it is much more intuitive and easier to comprehend.
We can add dates to our previous questions. For example, how many of new users registered between DS_START_DATE and DS_END_DATE were active on day 1,2,...,n?
We could also put first_seen or registration_date on X axis and display 3,7,30 day retention with line graphs.
In real life scenario we would normally have registration_date instead of first_seen so our dataset will probably require a little adjustment.
We can use calendar months as retention cohorts. Just remember it’s not the same as first, second, etc. month after registration. For a user who registered on 2020–10–01 activity date of 2020–11–03 will be month2 retention. However, it is a month1 if we use calendar dates.
It might be very insightful to add user attribution (e.g. campaign, source, medium from Google Analytics) and use it in row groupings to see the retention for different campaigns.
Identify true unique users and calculate retention for them separately. This might have a huge impact on the retention numbers. Users with multiple devices or users who re-install the App same as users with multiple user accounts or spammers are really hard to count. No doubt they might skew your retention numbers.
It might be interesting to see what happens if we use custom retention cohorts, e.g. Day7+-1 day or Day30+-1 day.
Remember 30 day retention and why it is so important for marketers?
You could also calculate retention for different segments of your user base. For example, for those who qualify the particular criteria. Alternately it may be very usefull to perform a quick K-means analysis to cluster your users and then calculate the retention.
This brings me to the end of this post. Using this nifty template you can easily mock up user activity data and unit test your retention reports.
We have just used 5 different ways to display user retention in BigQuery and Data Studio and there is so much more you could do with Firebase, Google Analytics data and this little report.
With just a few simple tweaks in Data Studio this template can be turned into a beautiful real-time analytics dashboard and used to understand you user behaviour better.
Retention is a very important metric because being able to see why, when and where users leave might help you to understand the reasons why they do that.
Retention analysis is a very powerful tool and aims to explain user churn. Using this knowledge marketers can increase retention rates by fixing application bugs, improving App features and building more successful marketing funnels.
It is a well known fact that it costs more to acquire new users than it is to retain existing ones.
Because churned users can translate into a direct loss of revenue, predicting possible users who can churn beforehand can help the company save this loss. And that is why different views on Retention, ways to interpret retention numbers and explanation of reasons why users churn become increasingly important in building Machine learning models (e.g. Chur Prediction).
Thanks for reading!
Click this link and click Use template
Click this link and click Use template
2. Click Copy report with datasets:
3. Some widgets will appear broken but click one and then click Edit
4. Select your billing project and click Reconnect:
Success!
There is a lot more templates and tutorials on datastudioguides.com