Why Calculating LTV is Key for Game Developers

Niklas Herriger |
2014-05-15
Are you still fooling yourself?

Many game developers measure the financial success of their applications by looking at the total revenue generated on a daily basis. Total revenue, however, tells an incomplete story.

The "total revenue" trap

Consider the following situation: the overall revenue of App X is $100 on Monday. On Tuesday, that number increases to $200. Sounds like we are making a killing, doesn't it? Well, the real answer is "maybe."

In order to judge the financial efficacy of a game (or any app for that matter), the developer needs to take into account more than just total (= aggregate) revenue. Equally important is the total number of users that are responsible for generating that revenue. Going from $100 in revenue to $200 in one day is indeed great if the user base of App X stayed (roughly) the same. But what if the revenue doubled from $100 and $200, while the user base tripled? Would you still consider that a success? We might not be looking at a success-story anymore, but rather at an indication that something has gone terribly wrong. Although one might argue that increasing total revenue is the ultimate goal and hence what is described here is a success story, such growth is not *sustainable*. If the revenue per user keeps decreasing, then the game will likely cease generating any profits in the near future. Especially freemium games often fool their developers in just this way.

The solution: LTV

How can you differentiate real success from impending disaster? Don't look at revenue alone, look at user Lifetime-Value (LTV) as well. Calculating and comparing LTVs is the only way to truly measure the financial performance of your game.

The LTV of a game user is the sum of all revenues that will be collected from that user, minus the costs associated with providing the game to that user. Said revenues and costs are accounted for over the entire lifetime of the user, which starts with the game installation, and ends when the user stops playing the game. Compared to total revenue, LTV provides more accurate information in two dimensions: First, it measures the profitability of users, which helps developers identify more lucrative customer segments. Second, it takes future profits into account, and hence is more farsighted.

The reason to calculate the LTV of your existing players is to predict the net profit one can expect from the entire future relationship with a new player. Of course, different players earn revenues and generate costs in different ways, giving rise to the multitude of variants of the notion of LTV that are used by developers in practice, each involving their own set of calculations.

Once a developer has access to comprehensive analytics, calculating a user's LTV is actually not difficult at all. It is however very important to ensure that only LTVs that were calculated the same way are compared as performance "benchmarks."

5 popular LTV calculation methods:

In order to determine which formula suits what kind of game, we recently reached out to some of our fellow game developers and asked them: "how do you calculate your LTVs?" Below are our favorite answers. Note that CPI (cost-per-install) is subtracted in a consistent way across all the LTV calculation methods, and therefore not specifically mentioned every single time. Note also that none of the LTV calculation methods claim to be flawless or generally applicable. They just serve as a rough overview of how actual game developers do approach LTVs these days:

"Receipt" LTV

Some game developers calculate their LTVs by only taking verified in-app purchase (IAP) revenue into account, thereby ignoring any social contributions (e.g. a user is very vocal about the greatness of a game on Facebook) or advertising revenue. In short: calculate the total verified IAP revenue per active user. Done.

The "receipt" approach makes sense for games that are focused on monetizing virtual economies, because developers want to determine how much money they actually make on virtual currency IAPs (user conversion within the virtual economy). Simultaneously, they have a strong interest in not having their IAP data spoiled by ads or even piracy (corrupted/fake IAP), which is why they are relying on the IAP receipts.

"Weekly cohort" LTV

Other game developers segment their users into 52 cohorts per year, one for each week. Starting from there, they track the week during which a user first installed the game, and then calculate the LTV for each cohort (weekly group) of users separately. For example, users that joined one year ago are grouped together in the 52-week LTV cohort, while users that joined a month ago will be compared in the 4-week LTV cohort. In other words: weekly cohort LTV can be described as receipt LTV controlled for the acquisition time (i.e., the time user starts playing the game). So someone who first downloaded and played a game 4 weeks ago but monetizes today (by making an in-app purchase) will count toward the cohort from 4 weeks ago.

The "weekly cohort" approach makes a lot of sense for games with higher content depth that motivates their users to return for extended period of times (real time strategy games, adventures, puzzle games etc.).

"Multiplier" LTV

Game developers in this group only measure LTVs for a specific (rather short) user lifetime, and then simply apply a pre-determined multiplier to the cohort (time frame) they want to examine. The multiplier LTV method thereby computes observed value (rather than life-time value) and uses it as a proxy for computing life-time value. This is essentially a variant of the "weekly cohort" approach, except that the time frame the game developer takes into consideration for the LTV is very limited, thereby ignoring all purchases that actually occur after the pre-determined cut-off time.

This approach allows developers of games with very short core gameplay loops to start comparing user LTVs very early during a user's lifetime. The high amount of repetition (tens or possibly even hundreds of rounds of gameplay per day) naturally allows them to predict LTVs much earlier than for example in story-based games that really develop (and therefore monetize) over time. Use cases predominantly include casino games where the length of each round of gameplay is not particularly dependent on the user's increasing skill, but rather on chance.

"Average" LTV

Multiplying the average revenue per daily active user (ARPDAU) with the average user retention (ARPDAU x Average Retention) leads to the "average" LTV approach. The first part of the formula (ARPDAU) is a fixed dollar amount, while the latter part is percentage of players that are still active after the first day of installing the game. Average LTV computes an average revenue metric, adjusted with the most recent information on retention. Like total revenue, this metric computes an overall figure for the entire user base.

To be fair, the average retention of all users might not necessarily be a good estimate of a particular user's retention, which is why we are somewhat skeptical regarding this calculation method.

"Weighted" LTV

If given a set stream of receipts from a player, every game developer will choose to monetize a player as early as possible during the player's lifetime. One reason is that only money that has actually been collected can be reinvested back into a business. The "weighted" LTV method discounts later purchases in order to emphasize the preference for "early money". Game developers follow the maxim "A bird in the hand is worth two in the bush" and modify their way of calculating the LTV by putting a multiplicative discount factor that diminishes over time in front of all receipts.

Example: Let's imagine the cohort of interest is "all players who started playing between January 17th and January 23rd." The game developer now needs to calculate the sum of discounted revenues for every player in this cohort. That is, he needs to multiply payments received by a discount factor that decreases with the the number of days between the player's acquisition and payment dates. A player who joined on January 17th and paid $1 on January 18th is therefore generally worth more than a player who joined on January 17th and paid us $1 on January 31st.

The difference is then averaged across all players in that cohort. The result is the average "weighted" LTV for that cohort.

While the "weighted" LTV method initially seems more complicated, it is the only one that applies more weight to players that monetize early during their lifetime. The true challenge is to determine the discount rate. There are many options. Some developers pick an arbitrary rule like "$1 now is worth 2% more to me than $1 one month in the future." This is really dependent on their cash flow needs. A more scientific approach would be to have an accountant calculate a capital depreciation rate. Some developers even match the discount rate to the weighted interest rate on their company's debt. Developers usually look at several different discount rates when analyzing weighted LTV.

Games with high maintenance/cash flow needs like MMOs are prime candidates for the "weighted" LTV approach. The same applies to games that seek to increase their user spending by way of aggressive (and therefore expensive) marketing campaigns.

Conclusion

Short of completely ignoring user LTVs, there really is no right or wrong way to approach the whole business of LTV. The correct calculation method depends on the type of game the developer wants to analyze, as well as the specific circumstances he or she is operating under. We have heard that some developers adjust their LTV calculations depending on the time of the year (July generates different results than Christmas-fueled December). Others switch the LTV calculation to a different model because they need to picture their game(s) in a slightly more favorable way to prepare for a board or investor meeting.

The cardinal rule is this: always make sure to only compare LTVs that were calculated using the same method, regardless of whether you are seeking to understand the financial development of one game, trying to compare across multiple games, or engaging in comparisons that involve aggregate industry data ("benchmarks"). Otherwise, you are truly comparing apples to oranges, and you might think that your game is doing increasingly well when the opposite is actually true.