In Part 1 of this series, we hypothesized that there might be a small group of power users within our app because Firebase Analytics told us that our 3-month retention rate was 9%. What this metric doesn’t tell us is the frequency of engagement within that period. What we’re interested in now is: how many of our users are power users?

Power User Curve

The power user curve, also commonly called the activity histogram or the L30, is a histogram that compares the total number of days users were active across a 30-day period (or a month).

Look for the smile

An app with a strong cohort of power users will present a “smile” in its power user curve. In our sample histogram, the data first shows a steep drop-off of engagement from most users after a couple of days. More interestingly on the tail end of the histogram, we see engagement rise.

Calculating the Power User Curve

To create our power user curve we’ll use from our dataset the month of February in 2020. Here’s the SQL query to extract our data from BigQuery.

-- Replace the fields PROJECT and DATABASE to match your project DECLARE STARTMONTH DATE DEFAULT '2020-02-01'; --day is ignored WITH data as (

SELECT * FROM (

SELECT PARSE_DATE('%Y%m%d', '2020'||_TABLE_SUFFIX) event_date, user_pseudo_id user_id

FROM `PROJECT.DATABASE.events_2020*`

WHERE event_name = 'user_engagement'

) WHERE

EXTRACT(MONTH from event_date) = EXTRACT(MONTH from STARTMONTH)

)

SELECT

daysActive,

COUNT(DISTINCT(user_id))

FROM

(

SELECT

user_id,

COUNT(DISTINCT event_date) daysActive

FROM

data

GROUP BY user_id

) userEvents

GROUP BY daysActive

ORDER BY daysActive ASC

Note that in our query, we filter our logs for event_name = 'user_engagement' . In Firebase, this particular event log is automatically generated when a user has the app in the foreground for a minimum number of seconds (default set to 10 sec). This value is set within the app, so we need to be aware of how this may impact our results. For the moment we’ll live with it (because my time machine is still in beta).

The above query will extract for us a unique count of days that a user has engaged with our app in February of 2020 (29 days, it was a leap year). Then, plotting the results into a histogram we can get a better idea of how our users are engaging with our daily-use app.

At first glance, we see a sharp dropoff of users after a single day of use and we also don’t see the upward trend at its tail. However, upon closer inspection, there is something interesting going on at day 29. What would happen if we cropped away the first two days and zoomed in?

Now, this is interesting. After removing the first two days we see our smile appear. In fact, it appears that 14 users have used our app every day in the month of February.

Monthly trends

Taking this one step further, we can also track this trend over several months. We haven’t done any marketing nor has the app been updated, so we shouldn’t expect drastic changes, but here are the results.

Since January, there definitely seems to be a small group of power users on our app. Perhaps a New Years resolutions bump? It will be interesting to monitor this over the coming months to see if the trend persists or levels off.

Take away

Zooming in on the data can be misleading and we need to be careful not to paint a story that isn’t accurate. For this example, we merely wanted to validate that we have power users on our app.

We might take a guess at who these people are but there’s no way to be sure from a single histogram. We can consider taking the following next steps from lowest to highest effort:

Dive into the data : Taking a deeper dive into the default event logs may reveal patterns that help us better understand our users.

: Taking a deeper dive into the default event logs may reveal patterns that help us better understand our users. User survey : Sending out a user survey to build a profile of our power users can answer questions that we otherwise couldn’t by combing through the event logs.

: Sending out a user survey to build a profile of our power users can answer questions that we otherwise couldn’t by combing through the event logs. Collect more data: We can consider adding a questionnaire to the onboarding steps to help us build a profile of our users. As well, adding custom event triggers in the app can help us monitor activities not captured by default in Firebase.

Closing Thoughts

Despite the cohort being small (1% of our total user base in February), we’ve used data to confirm that we have power users on our app 🎉. The task from here would be to identify what type of users they represent and how we can get more of them.

Now that we have a baseline measurement we can continue to monitor this metric as we push new features. We’ll need to keep in mind that this is a lagging metric and that we’ll need a month’s worth of data to calculate it again. It would be a good idea to A/B test new features to keep the data separate for evaluation.

In the next part of this series, I’ll cover cohort analysis.

PS. I think it’s time to adopt a cat. 🐈