How We Built a User Growth Model for our App (including template)

Over the last few weeks, we’ve been building a user growth model for Rescover. It’s been so useful, I wanted to share the process and the model itself.

Why did we build a growth model?

• We wanted to better understand the underlying metrics needed to get into millions of active users.
• We wanted to get a better sense of how many users are required to start generating meaningful revenue.
• If and when we seek investment for Rescover, we knew we would be expected to provide insights on how we plan to grow and build revenue.
• We hoped it would influence our thinking for what we decide to build over the coming months (which it has).

Right from the start, we doubled down on analytics. That was a good decision. We track absolutely everything we could think of using mixpanel. We therefore knew it would be easy to plug our own numbers into a model and see what improvements were needed to get into the big time.

A word of warning before we dive in.

Whilst the model relies on widely used metrics, we purposely kept things simple. It’s also tailored towards our own situation.

What our growth model tracks:

• The model tracks four key things — acquisition, retention, virality and monetisation.
• Distinctions are made between organic and paid users for everything, except monetisation.
• All assumptions can be adjusted over time (to model improvements in the future)

Download the growth model

Now is probably a good time to share the model itself, as you may want to experiment with it as you read. You can download the excel here.

The configurable options are within the ‘Baselines (monthly)’ and ‘Events’ sections on the ‘Summary’ tab. The rest of the ‘Summary’ tab will auto update to give you a summary of your growth over time.

You can ignore the other tabs, they are just doing the calculations behind the scenes.

OK, let’s jump into each area to explain how it works:

Acquisition

Acquisition deals with new users installing your app.

We wanted to track two acquisition channels.

Firstly, we have a specific organic channel which we wanted to include in the model. We have a slimmed down version of Rescover on the web, with a call to action of installing the app to be able to track releases and get notifications.

This acquisition channel was straight forward to build. We forecast unique visitors to the website and then apply a % conversion to install.

We expect our unique visitors to steadily grow (our content is increasing daily and is very SEO friendly), so it needed to take that into account.

We decided to make three assumptions:

1. Organic Acquisition Base Traffic — this is the base level of unique visitors to the website for the first month (gives us something to start with) and every month thereafter. This is an absolute number (i.e. 2,500).
2. Organic Acquisition Traffic Growth — this is the monthly growth rate applied to the base level over time. Because we expect web traffic to grow steadily (not exponentially), it’s non compound and applied to each month. This is set as a percentage (i.e. 50%).
3. Organic Acquisition Conversion — this is the conversion of traffic to app installs each month. This is set as a percentage (i.e. 5%).

The above assumptions (2,500, 50% and 5%) are actually the numbers we used in our own model. We also assumed a steady improvement in ‘Organic Acquisition Traffic Growth’ (50% to 200%).

We picked those based on data we were seeing (visitors) or where we didn’t yet have data, we made an educated guess for what we expected to see (web traffic growth and % to install).

Heres what that looks like by the numbers:

assuming a base of 2,500 unique visitors to our website, steadily growing and converting to app installs at 5%.

The second acquisition channel we wanted to track was paid acquisition. We made two assumptions:

1. Paid Acquisition Spend — monthly paid marketing budget (£)
2. Cost Per Install — average cost per install (£)

In our own model, we adjusted both of these over time.

We assumed only a small improvement to our ‘cost per install’ because we are already achieving a low rate (all time average of $0.50). It felt reasonable to expect with more time to dedicate to it, we could get it down a bit further.

We adjusted our monthly paid acquisition budget to conserve it before the launch of a few key growth initiatives. We also factored in more spend around the time of a launch in the U.S.

Retention

Retention deals with how many of your users stay using your app.

We tackled retention from two angles. Some of our thinking was inspired by Andrew Chen’s great article — New data shows losing 80% of mobile users is normal, and why the best apps do better.

As you can see below, with most apps, there is a steep initial drop off of users with a fairly predictable long tail after that.

retention graph ‘borrowed’ from Andrew Chen’s article.

True to the article, our own retention curve looked very similiar. I wrote a bit about how this insight influenced our product roadmap here — What I’ve Learned About Product Roadmaps in the Last 6 Month’s

We tend to look more closely at weekly retention to measure our progress. This is because there is too much variance in the day to day retention — partly because of the lack of a compelling reason to use rescover daily (we’re working on that now — watch this space).

Taking that into account, we made two assumptions in our retention modelling.

1. Acquisition Survival — this is the % of new users retained from week one, into week two (survived the initial steep drop off). This is set as a percentage (i.e. 25%).
2. User retention — this is the % of users retained every 4 weeks thereafter (the long tail). This is set as a percentage (i.e 50%).

In our own model, we simply plugged in our mixpanel numbers for the above two assumptions as a starting point. We then modelled some improvements to both over time.

We were fairly punchy with our future improvements on Acquisition Survival (survived the initial steep drop off). This is because, whilst we have pretty good early retention, we have some nice ideas for how to improve it further. We also knew that most retention improvements are made early on, with the long tail being more predictable and harder to shift (as shown in Andrew Chen’s article above).

We did model some small improvements to the user retention (long tail). This is because we have a number of features planned, which stand a good chance of impacting long term retention.

The model also allows for a distinction between organic, paid and viral users. Upon reflection, some of this might not have been necessary and is a bit confusing, but bear with me whilst I explain.

You can set the Acquisition Survival (survived the initial steep drop off) and the User Retention (long tail) rates for both organic and paid users separately with the following assumptions:

• Organic Acquisition Survival (survived the initial steep drop off)
• Organic User Retention (long tail)
• Paid Acquisition Survival (survived the initial steep drop off)
• Paid User Retention (long tail)

You can also set the User Retention of viral users, for both organic and paid users. (Yeah, this is where it gets a bit confusing).

Viral users (we’ll talk about virality in a bit) are people who installed the app as a result of being invited by an existing user. The model allows you to make forecast User Retention (long tail) with the following assumptions:

• Organic Viral User Retention
• Paid Viral User Retention

Now, I have no idea if the retention rate for organic, paid or viral users is, or should be different. We’re working on breaking this out for Rescover at the moment so we can see the difference.

The model does allow for retention assumptions to be different for each of these types of users, if you want them to be.

For modelling purposes, we assumed there was no differentiation between these users. We will change this as we get insights that suggest different.

If you wanted to do the same, here’s how you would do it. Lets say you wanted to set the Acquisition Survival (survived the initial steep drop off) to 20% and the User Retention (long tail) to 50% for ALL users. It would look like this (specific assumptions highlighted in red):

Note: You may have noticed, you can’t set the Acquisition Survival (survived the initial steep drop off) for Viral Users. That was an oversight and we should probably add that option. Seeing as we aren’t making a differentiation between types of users at the moment, we just haven’t got round to it yet.

Virality

Virality deals with how many new users you get as a result of your existing users spreading the word.

This can happen passively (your product is just so goddamn good or for some other reason, it takes off like wildfire), or you may have features specifically designed that allow your existing users to invite their friends to use your app.

It’s effectively another organic channel (you’re not paying for these users), driven by a multiplier of your existing user numbers.

We kept things simple, and went for just two assumptions in modelling virality.

1. Virality — this is how many users, each of your existing users bring in. This is set as a %. (i.e 100% = each user brings in one new user). This can be set differently for paid and organic users with the Organic Virality and Paid Virality assumptions.
2. Viral Cycle Time — this is how long it takes for a new user to bring in another new user. This is set as a number in months (i.e 1 = 1 month and 0.5 = half a month).

Let’s say, you want to model getting one new user virally for every two existing users, and it takes a month for that to happen. Let’s also say you don’t want to differentiate between organic and paid users.

You would use 50% for Virality and 1 for Viral Cycle Time.

Let’s see how that plays out. An initial 1000 users will bring in 500 users in month one (1000 x 50%). These extra 500 users will then bring in another 250 users in month two (500 x 50%), who will go on to bring in another 125 users (250 x 50%) in month three — and so it continues.

You can see how your 1000 initial users, end up being 1,625 users after 3 months. A word of warning — this example is simplified on purpose and doesn’t take into account retention.

In our model, we already had a good sense of how many installs we were seeing virally. We set it as that to start with and modelled in sensible improvements into the future. We based these improvements on features we’re going to be shipping that will encourage users to share content and spread the word.

It’s worth making the point that setting Virality to anything over 100% and/or shortening the Viral Cycle Time will forecast exponential growth. This is because it will have a compounding effect. Play around with it and you’ll see what I mean.

Spending some time with the viral assumptions will highlight the power of virality in growing quickly and achieving massive scale.

Monetisation

Monetisation deals with how much revenue is generated per user.

We kept this super simple and made just one assumption:

1. Monthly Revenue per User — this is how much revenue each user generates each month (£).

This is possibly the simplest way to model revenue. We did it that way because Rescover will primarily have an advertising revenue model. It therefore felt the best way to get a sense of how much revenue we could build, based on how many users we have.

Also, because the big social networks are transparent about their MAU and revenue per quarter, it’s easy to get a benchmark of what others are achieving. The Cheat Sheet published a great article on this here — See How Much Money Your Social Networks Make Off of You.

The big five are shown below:

image ‘borrowed’ from The Cheat Sheet article.

Using the above as a guide, we made a good guess at how much revenue we could generate per user. We also decided on a point in the future it felt reasonable to start monetising.

We started very conservative (when and how much). We then modelled in some sensible improvements into the future, to reflect a better advertising experience over time.

Note: When setting the ‘Monthly Revenue per User’ assumption, you will need to divide your annual revenue per user by 12, and then use that figure. This is because the model applies this value to each months active users.

Adjusting assumptions over time

Almost every model has two things in common. You need to be able to make assumptions and you need to be able to change those assumptions over time, due to internal and external events occurring.

That’s where ‘events’ come in.

Events allow you to specify a change in the baseline assumption, and over a defined period. There are the four configurable options per event.

• Effect: the name of the assumption you want to change (pick this from the drop down box that appears when you click into an effect cell).
• Value: the new value for the assumption in the future.
• From: the date at which you want the new value to be applied.
• To: the date at which you want the new value to stop being applied, (the baseline value will continue to apply after this date)

Here’s an example:

Let’s say you wanted to start off with an Acquisition Survival rate of 20%, and wanted to model an improvement to 40% over time.

Let’s also say, you wanted to make no differentiation between paid and organic users. And you wanted it to occur fairly evenly through to the end of 2016 and then settle during 2017.

You might do something like this:

As you can see, the baseline assumption for organic and paid is set to 20%.

We then model 5% improvements for three quarters (Q3, 2015 — Q2, 2016), a 2.5% improvement for the next quarter (Q3, 2016), followed by a 2.5% improvement for the next quarter and the following year (Q4, 2016 and the entire of 2017).

The reason we’re setting the baseline ‘Acquisition Survival’ for both organic and paid, is to ensure there is no differentiation (if set only one, the other would just carry the baseline assumption).

The events table can also be dragged vertically to allow for as many events as you want.

OK, What did we learn?

We learned a few things from putting this together. We knew them already, but the model helped put them in our faces as a stark reminder.

Installs don’t mean shit. Ok, they kinda do, in that everything starts with an install. Only when you start factoring in retention are you forced to see what a small fraction of your installs actually end up as active users. Eventually everyone will leave your product.

It’s kinda like having a bad day on ‘Lemmings’:

1991. puzzle-platformer ‘Lemmings’.

Retention is crazy important. Because of the above, you have to prioritise keeping hold of people that install your app. It’s the foundation to everything. Without a good level of retention, you’ll always struggle to build sustainable big numbers.

Sustainable is the key word here. You can fake growth with a big acquisition budget or a clever marketing initiative. But, that will always come back to bite you if there isn’t a strong foundation of retention.

Retention also directly impacts how powerful virality can be and how much revenue you can build. After building out the core product, retention should be what you focus on.

You cannot buy your way to big. By big, I mean hundreds of thousands and millions of active users. To get to that level, you absolutely need to have a strong organic pipeline — either a unique organic channel or strong virality. In our own model, we don’t get into the hundreds of thousands of users without a very big marketing budget, or strong retention and virality.

We need to be BIG to build a business. If we can monetise at $5 a user annually (on par with Twitter), you would need to average 1M MAU per year, to net $5M revenue. 1M MAU is BIG and $5M revenue whilst nice, isn’t BIG. So, you either need to monetise at a higher rate or be really, really big to build a sizeable business.

Again, we knew these things, but the model abruptly shoved it in our faces. The biggest things for us were points three and four.

As a result, we’ve started to shift our focus towards organic growth initiatives.

We’ve been working exclusively on retention for quite a while and we’ve got into pretty good shape. And we’ve been growing each week consistently because we’ve been buying installs effeciently.

But, if we’re to build a sizeable and sustainable business, we need to get into the hundreds of thousands and millions of users. As mentioned above, we can’t buy our way to that. We need to start establishing strong levels of organic growth.

We’re working on making things much easier and fun to share. We’re also working on introducing new content into the app which will encourage a daily habit, aswell as be highly shareable.

Last Words

I’ve worked on many forecasts in my time, and there becomes a point in which you shift from making sensible assumptions and having something quite useful — to agonising over the detail and completely living in la la land. It’s a fine line between the two.

Models are just models. They are built on assumptions (guesses) and often these assumptions are layered upon other assumptions (more guesses). They aren’t worth agonising over and you have to keep reminding yourself, you’re living slightly in fantasy land most of the time.

That’s why I think you shouldn’t get carried away with the future timeframe. Anything beyond a couple of years feels too fictional. Also, try to limit how many assumptions you make overall.

Where possible, base assumptions on a mix of your own data and well known industry benchmarks. Model your improvements around specific initiatives. Think through which assumptions they will impact and how.

It’s incredibly hard to separate what you reasonably expect to happen vs. what you want to see with all your soul. — especially when you are emotionally invested.

Keep reminding yourself that. If you don’t, you might end up with the perfect hockey stick model that looks great on a board slide, but has as much chance as actually happening as Meek Mill putting Drake in his place.

Lastly, don’t spend too much time on modelling growth.

It can be a useful exercise, but don’t let it distract you from what’s most important — shipping product, talking to users, doing things quickly, growing weekly etc.

If you find any bugs or have any questions or feedback, let me know in the comments. We’re not claiming to have the perfect model or indeed the right one for your app, so any feedback is really helpful to us and others reading.

Rescover

P.S Rescover is available for free on iOS and Android in the UK. It lets you discover things you love (movies, tv shows, games and music), and stay in the know with when & where they come out.

If you get a chance, we’d love it if you could download the app and let us know what you think. Sharing it with your friends — well that’d be the icing on the cake ;-)

The FIFA 16 page on Rescover and an example of a personalised timeline.

P.S Thanks to Simon Scott for his help with the model. Without him, it wouldn’t have been possible — our brains just don’t work like his ;-) And thanks to Jay Bayley, Richard Leggett, Barry Avraam, Jess Ratcliffe for reading early drafts of this.