The role of LTV in freemium Customer Value is probably the most fundamental conceptual struggle for freemium app developers. And while calculating LTV and integrating it into an organization’s decision-making apparatus are onerous tasks, these aren’t the root causes of firms’ anxieties over LTV.

The root cause is user acquisition – specifically, its cost – and the inability of all but a small minority of apps to recover their marketing spend when growing their user bases.

User acquisition is an existential concern for most app developers: if their apps aren’t LTV positive, their user bases can’t grow absent the auspices of substantial virality. But the concept is often muddied by intellectually segregating virality and paid acquisition, or by using LTV to drive product development, or by conflating marketing costs with the costs of development.

Defining LTV

LTV is commonly defined as the present value of all future cash flows attributed to a user. In practice, this is rarely how LTV is calculated: for most app developers, incorporating the time value of money into an understanding of the user’s future revenue contributions isn’t pragmatic, for a number of reasons.

The first is that deriving a risk-adjusted discount rate for money earned through operating a mobile app is impractical. Only a small minority of the largest developers are positioned to invest the proceeds from operating their products into short-term, interest-bearing securities like treasury bills or commercial paper; the vast majority invest their revenue into continued development, the return on which is impossible to predict with any accuracy.

The second is that the lifetime of a user and, more importantly, the timing and size of any individual user’s revenue contributions in most freemium settings are stochastic processes, whereas a discount rate is used to adjust known, discrete values on a fixed timeline. Freemium app cash flows don’t resemble cash flows from annuities or bonds, which are consistent and distributed on even intervals.

To be useful, then, LTV should be calculated as a probabilistic sum of revenue contributions on a per-user basis. Discounting LTV is a purely intellectual exercise in this context that reduces its ability to inform the process to which it is most appropriate and applicable: performance marketing. is a marketing metric

The total amount of money a given user can be expected to contribute to a product, as a data point, isn’t useful from a product development perspective; it doesn’t describe product use at a granular enough level to be used to adjust a product’s monetization mechanics. Also, because LTV is aggregated by various demographic characteristics – geography, device type, acquisition source, etc. – it necessarily can’t be associated with the overall product experience.

The sole use case for the LTV metric is determining whether a marketing campaign can be conducted on an ROI-positive basis. This is often expressed in the form of LTV > CPI, which describes a state in which a user’s projected lifetime value is greater than its cost of acquisition. Under such conditions, the return on marketing spend is positive.


The term LTV > CPI is the source of much general confusion around how exactly LTV fits into an app developer’s broader corporate strategy. LTV is a marketing metric, not an accounting metric; as such, LTV describes only one aspect of an app developer’s business, not its entire revenue structure. When LTV is greater than CPI, a firm’s marketing operations exhibit positive return – which, while objectively a favorable position, does not guarantee overall profitability for the firm.

The term that describes overall firm profitability is not LTV > CPI, it is Revenue > Expenses. The two terms are related only in their logical implications; because marketing is only one functional domain within a firm’s overall operations, the return on its use of resources contributes to but does not necessarily exclusively determine the firm’s general profitability.

LTV != Revenue

LTV > CPI is not analogous with Revenue > Expenses because LTV is a projection; LTV is not considered realized at the point of a user’s product adoption but over an estimated lifetime. CPI, however, is paid out at the point of a user’s product adoption. Because the chronologies of LTV and CPI are not the same, it is possible for LTV to exceed CPI while revenue does not exceed expenses.

This is of course not unique to a discussion of LTV or freemium; even firms selling one-time purchase products, where LTV is discrete and realized immediately upon adoption, can profitably conduct marketing yet fail to cover their operational overhead.

What is unique to a discussion of LTV within a freemium context are volume considerations and revenue regularity. Cost per acquisition increases with the size of a marketing campaign as a result of the auction model through which most advertising campaigns are conducted: advertisers submit bids for individual ad placements, and the highest bids are awarded the placement. Given a finite number of placements available at any given point in time, the more placements an advertiser wants to win over a specific timeline, the more it must bid for those placements.

This relationship affects a firm’s understanding of LTV because the total realizable profit from a user base is a function of its size and the spread between LTV and CPI. At high marketing volumes, the decreasing positive spread between LTV and CPI can result in reduced profit past a certain CPI threshold, as in the two scenarios presented below.


From an economic standpoint, the firm should favor the marketing campaign that produces the greatest level of overall profit, regardless of volume. But this perspective must be tempered with the inclusion of another metric that adds depth to the context in which LTV is evaluated: virality.

Virality and LTV

Virality – specifically, k-factor – changes the dynamic of the relationship between LTV and CPI: because virality represents cost-free growth, it reduces the effective price paid for each user in a marketing campaign. Taking the opposite approach – using k-factor to augment LTV – is inappropriate because LTV is specifically interpreted to describe the revenue contributions made by a single user.

Considering k-factor as an element which reduces a product’s CPI has the added benefit of preventing a line of thought from taking root wherein virality and paid user acquisition are considered mutually exclusive.

figure_2_LTV_seufertHighly-viral products can indeed benefit from user acquisition; in fact, they benefit to a greater degree than non-viral products, since a reduced eCPA hastens the point at which overall marketing revenue begins to decline with increased volume. In a sense, virality shifts the profitability curve of a marketing campaign up, increasing the number of users that can be acquired at each level of profitability.


LTV and sunk costs

It’s tempting to think about LTV as an overall revenue function for a particular product – and, in doing so, to dictate that LTV should compensate for the development costs incurred in bringing the product to market.

But this thought model ignores the fundamental role of LTV as a marketing metric. LTV should not, in fact, address development costs: LTV should be used only to determine the return on marginal user acquisition at a specific point in time is positive.

To abstract LTV from overall firm profit, it must be confined within the parameters of marketing operations: LTV > CPI is not a business strategy, it is a marketing mandate, and that mandate operates within budgetary limits. Because LTV is merely a long-term approximation of revenue, it can’t be matched to expenses on an ongoing basis.

The discrete payments that comprise the concept of LTV are revenue items, and those must be used to build forecasts and budget a firm’s operations month to month. Marketing spending should be framed within the boundaries of monthly revenue figures to allocate resources to a marketing budget in the way that best reaches growth targets given expected acquisition prices.

Although LTV can be reasonably estimated in freemium apps through the instrumentation of per-user level acquisition, marketing, as in every other industry, is conducted through budgets that optimize for growth while still addressing the other areas of the business.

In other words, marketing in mobile freemium is not an infinite feedback loop between LTV and CPI, ramping up so long as the spread is positive; rather, it is, as in traditional industries, one component of an operational mosaic that must contribute to a firm-level strategy.

Isolating LTV

Because LTV poses innumerable opportunities with which to be misinterpreted, misapplied, and misunderstood, using it outside of a marketing context — even if to describe the marketing process — is not productive. LTV is too broad of a metric to be helpful in a product development or management setting; rather, product managers should focus their efforts to optimize the metrics that describe user delight and engagement, such as retention and product-specific measures of activity.

The potential for misguided application of the LTV metric in product development runs deep. Most product managers, upon learning that the LTV of a product is too low to accommodate paid marketing, would likely react by implementing more aggressive monetization mechanics because these would be more immediately realized. But retention contributes as much to LTV as does monetization — and product changes instituted to focus on retention are less likely to result in “blowback” in the form of user alienation than are those focused on increased monetization.

LTV — as a probabilistic metric derived from multiple, disparate inputs — is not useful in describing anything other than the conditions under which marketing campaigns are evaluated. Using LTV as a business strategy, or to describe a firm’s general level of performance oversimplifies the dynamics of a business and obfuscates the real factors that contribute to its success. LTV is a complex concept, but its use is not: it determines whether or not marketing should be conducted.