The art of modeling and calculating LTV, and why it matters to the success of your next mobile game.
If you are working on building a successful free-to-play game studio or game, understanding LTV is tremendously important. Talk of LTV is never far from conversations about free-to-play theory, and it serves as a fundamental metric or value in numerous strategies and conventions around monetising free games. There is no way around it – to scale your game successfully you simply have to be on top of LTV – and how to model it.
And yet, for all the attention showered on LTV, it is often misunderstood. Ultimately, LTV is a dynamic entity, and it varies dependent on user source. So, for example, different ad campaigns would mean variances in LTV. That makes modelling LTV a fundamentally important process, as it can let you know if a given ad campaign or similar effort is worth the investment.
With all that in mind, let’s take a look at the fine art of modelling, calculating and harnessing LTV, in this, the first of a two-part article.
What is is LTV, and why should you calculate it?
LTV stands for ‘Lifetime Value’, and refers to the amount of revenue you make from your customers. LTV is a fundamental KPI (key performance indicator) for a free-to-play game, making it a highly important consideration if you want to find success.
The concept of LTV is built around the notion of players’ individual ‘lifetime’ with a game; in other words ‘how long they will spend actively engaged with a given title’. Put simply, LTV asks ‘how much will a game make from a player who spends a typical amount of time with that game?’. That relationship between player and game varies by title, by genre, by platform and by type of user. Modelling and calculating it can prove particularly difficult, but understanding it brings manifold advantages. At its simplest, if your LTV is greater than your CPI (cost-per-install), your game should grow profitably.
What are the limitations of LTV, and what do you need to bear in mind?
Despite its value and importance, LTV isn’t a perfect concept. Some of the things to be aware of when considering LTV are the relatively open definition of ‘lifetime’ in this context, the limitations of some of the methods that employ or deploy LTV, and the challenge of analysing and extrapolating LTV early in a game’s roadmap.
Let’s start by further considering the definition of a player ‘lifetime’. Essentially, because every game is different, ‘lifetime’ will mean different things across different genres and forms – as will the related rules of understanding and harnessing LTV. A hypercasual game will generally monetise soon after release – and may lose players fairly shortly thereafter – meaning you should know if it has a viable LTV within days. A mid-core game, meanwhile, may take months – or even years – before a reliable notion of player lifetime emerges. As such, defining ‘lifetime’ depends on the type of game, the benchmarks that exist and how robust your data is.
A hypercasual game may have a LTV that spans one-to-five weeks, whereas a mid-core game’s LTV might cross a full 12 months.
Furthermore, LTV doesn’t always suggest a consistent, steady rate of engagement. Some games may see 90% of player spend come in the first three months of a user’s time with that title, and then a tail of many more months thereafter, where engagement and spending are in decline. In theory, that could give some games a practically indefiniate lifetime. Only a small number of players may realistically play that way, but their existence can make it tricky to consider the typical player. Engaging paying players for an indefinite time is no bad thing, but ‘indefinite LTV’ brings little practical use as a metric to understand and strategise around monetising free-to-play titles.
Clearly, then, the idea of ‘lifetime’ as an inconsistent entity makes LTV an inconsistent value. That doesn’t render it useless – far from it, in fact. But careful consideration of relative lifetime is essential in taking meaning from any LTV calculation.
As we can see, typical player lifetimes can vary across different kinds of game. Furthermore, players’ behaviours and spending within a game may shift through a given lifetime; again, with distinct patterns across different genres. Player lifetime is a dynamic, inconsistent entity, rather than a singular, static value. And that is why it must be carefully modelled and calculated.
How to model, harness and evaluate LTV
As with defining ‘lifetime’, understanding the modelling and methodology of LTV means considering inconsistency. The perfect LTV robot would be a mix of a data scientist, a product manager and a UA expert, though you’ll likely have to build your own out of expert staff or external contributors. A data scientist will ensure game data is accurate and that your studio is consuming and storing it correctly. With that data they can build the models that allow you to quickly calculate LTV using the main variables.
A product manager understands the ins and outs of the game itself; the when and the where of a coming feature, the ideal monetisation hooks and strategy, what can be tweaked to improve LTV, and the issues that are minimising the potential of a player’s lifetime with the release.
And a UA manager controls the marketing, and usually holds the purse strings. They need to see the details and the exact numbers to know where to spend more, and where to spend less. Their job is to ramp up the UA when the LTV is above CPI (or ROAS, from ‘return on advertising spend’), always working alongside the product manager and the data scientist to optimise the processes.
To understand LTV, data really is everything. You may well have heard the phrase ‘garbage in; garbage out’ when discussion turns to data. That’s just as true in the case of LTV as it is when large corporations use data to plot organisational strategy. Before you even start building any LTV models, you must make sure you have the right data, from the right sources, looking at the things that drive your economic decisions. At Sugar, we spend a huge amount of time on this piece process, and it is often incredibly under-appreciated. Most of the time, the data needs to be normalised or cleaned up, and will have to be correctly mapped. Ask yourself some important questions. Where are you storing it? Do you have the right attribution and analytics setup? Are you looking at net or gross figures and are you pulling in all ad and IAP revenues, or are some missing in your tracking? The answers to all those questions might come from having the right expertise on your team – or supporting your team.
How do you calculate LTV?
With the right people in place, you need to address LTV’s million-dollar question. Which LTV model should you pick to calculate your game’s own LTV? There are many different options, from the retention-based to simple ‘Average Days Played’ and ARPDAU models. Some people look at money spent and money made, and just divide that figure by their total number of users. These approaches are too limiting in our view, and don’t give you much insight beyond one or two data points.
Everyone has their favourite, of course, but at Sugar we favour a model where predictive revenue curves drive our analysis. Below we will touch on two models; the basic retention model, where we started many moons ago, and the revenue curve model which we know and love today
For many the well-established ‘retention/ARPDAU’ model of LTV offers a good place to start, as it can reliably give you a rough idea of where your LTV lies. For this you simply need your main retention stats such as d1 (day one), d7 and d30 retention, as well as your ARPDAU. Effectively you build a revenue curve of a typical user and multiply it by the ARPDAU for the lifetime of that user. For Example, if d1 retention is 40%, d7 is 20%, d30 is 10% and ARPDAU is $0.10, then the curve you build will give a 120 day LTV of $1.19. The first chart below shows the shape of that retention curve, while the second demonstrates the relationship between LTV and CPI (which we have simply assumed to be $1.10).
If you want to advance the model, then you may make assumptions about general d90 and d180 retention, and build a longer tail to your curve. That’s probably a better reflection of reality, but remember those tail end numbers will be low – probably in the 0.5-to-2% range. That number, however, can be considerably higher for some midcore and hardcore titles.You could also decide to have a linear retention curve, or a curve that is shaped more like an actual curve, so built using clever formulae.
There are problems with those approaches, however. Primarily, that’s because ARPDAU isn’t a fixed number, in that it varies day-by-day. Equally, retention can move about a lot too – it is a dynamic entity in the case of many players, games and genres. For example, what would happen if you acquired cohorts of big spenders who only played your game for two weeks before moving on? Using the conventional retention/ARPDAU model for calculating LTV would overestimate the retention metrics, while underestimating their ARPDAU.
Establishing more detailed LTV models
At Sugar we have a team that specialises in building the models behind our technology. After years of experience, we are confident that our approach of building revenue curves from historic cohorts works best. The principle behind the approach is as follows: We take a set of historic revenue data – either organic or inorganic – and we plot the average revenue curve over time for those users. As a result, we know the average revenue curve per type of user.
These curves are then applied to the most recent cohorts of users, to forecast and analyse LTV. The model then needs to be constantly improved, as the accuracy of that revenue curve is everything – and it’s constantly changing. Different cohorts will have different performance characteristics – as well as distinct revenue trends – so it’s not a static curve that can be used forever. The model has to be updated daily, using inputs such as the K-factor (the great unknown!) – more on that below.
In terms of building and maintaining your model for calculating LTV, Excel is always a good place to start, and you can’t go wrong with it for version one of your model. As you iterate and improve the model, you’ll probably want to build it using Python in the cloud. There are some off-the-shelf, ready-made platforms which take your data and they spit out your LTV, but the methodology is opaque, they’re often not flexible enough and can be quite limiting. You’ll learn more, and gain in the long run, if you build it yourself.
The dark art of the K-Factor.
The ‘K-factor’ is the holy grail for most mobile studios, and with good reason. The K-factor considers how many ‘free organic installs’ a given game gets for every dollar spent on UA. Those organic installs can effectively be understood as a positive side effect of paying for users through conventional UA.
As a game rises up the charts, or as acquired users make word-of-mouth recommendations, free users are picked up. Better still, if a game hits viral popularity, exponential growth in free organic users can occur. Giving consideration to the K-factor is a notoriously hard part of modelling for mobile games, and as such it forms a core part of our platform at Sugar. If you have a good game, the metric will be above one – so if it is 1.5, then for every 100 users you buy, you get 50 for ‘free’. Games at scale rarely have a K-factor above 1.1-to-1.2, but as you’re starting out and growing, it could be higher and provide a big tailwind. And in that case, once you’re spending on UA, you need to build something into your model to reflect that very real benefit.
There are some great benchmarks for tracking and calculating LTV out there from outfits including Game Analytics, Mobile Dev Demo and Appsflyer, and the numbers tend to move about a lot.
But to give you a rough idea of LTV by genre:
- A hypercasual game will have an LTV of 20c-to-40c
- A casual game will see a value of $1-to-$3
- A mid-core game’s LTV typically sits in the $2-to-$5 range.
- The best we’ve seen is a $15 LTV which was for a social casino game; but they, of course, come with much higher CPIs too.
Before you go
There isn’t an easy way around it – building a comprehensive and detailed LTV model is essential for user acquisition. It will allow you to make informed decisions about your dev sprints, live ops and UA campaigns.
Then you have to think about what to do with it once you have it nailed down. If you’ve got a hit on your hands, your metrics will be telling you to scale up, which means ramping up your UA to buy more and more profitable users. This means you need to think about implementing and financing it all. And that’s where Sugar can help.
And be sure to check back for part-two of this detailed analysis, where we’ll consider how to think about cash-flowing your UA; a process where you’re newly gained knowledge about modelling and calculating LTV will come in very handy indeed.
For more infromation on this topic, please reach out to Matt Frenchman from Sugar.