One interesting thing to track as the mobile app economy has evolved in the past few years is the way in which measurement and analytics have matured into a discipline that renders real competitive advantage. It could be argued that a lack of sophistication around analytics is the root cause of the fallout that occurred between the first mobile cycle and the second mobile cycle; certainly this argument is supported by the state of the mobile 220;plug-and-play221; analytics industry. What if “broken app discovery̶1; was really just a symptom of a broader problem: the inability of many (most?) participants of the first mobile cycle to institute actionable, reliable, budget-worthy analytics to support paid user acquisition?
Central, or at least “central-adjacent”, to an analytics team’s value in mobile is its ability to calculate an actionable LTV metric upon which user acquisition can be executed. And much has changed in the past few years — but especially the last 12-18 months — with respect to how LTV is thought about and injected into a broader, company-wide process. Much of this change is the result of evolutions in the mobile advertising space that have necessitated new models and approaches to doing user acquisition, but some of the change can be attributed to the higher caliber of analysis that has been committed to the topic of LTV, both in academia and industry. The topic has developed into a respectable destination for serious data science effort.
- The curve matters more than any specific number. With the introduction of Facebook’s AEO and VO bidding types and Google’s subsumption of all ad formats into its UAC bidding strategy, marketers think less about any specific LTV metric (day 90, 180, etc.) than they do about day-valued ROI. Unit economics and the “LTV > CPI” paradigm are still important, but given these new bidding strategies against in-app events, the cost element of acquisition (CPI) is less relevant than it once was (if a marketer is bidding against the occurrence of a specific event, the cost of an install isn’t the primary concern of the campaign);
LTV is comprised of many diverse inputs. The thawing of the Top Grossing chart marked the accession of a new mobile monetization champion: subscription pricing. The Top Grossing chart is far more diverse than it was two years ago; as of this writing, 5 of the top 10 grossing apps (US / iPhone) are subscription streaming services:
Advertising revenues (which aren’t reflected in the Top Grossing chart) have also become material for many developers. All three of these inputs — revenues from advertising, one-off IAPs, and subscription IAPs — must be accommodated in a robust LTV model in 2018. And since advertising revenues and subscription revenues are structurally different than those of one-off IAPs, the fundamental shape of LTV models has changed;
- LTV calculation is too complex to handle in a spreadsheet. At Slush in 2013, I gave a presentation called “Two methods for modeling LTV in a spreadsheet” (a video of the presentation is linked in the comments to that article). While modeling LTV this way in 2018 could still be a valuable exercise for planning or budgeting purposes, a production LTV model should probably not be contained entirely within an Excel workbook: too much data and too much dimensionality is required to produce something meaningful and actionable. It also means that any of the general formulas and diagrams that pop up in blogs or in presentations from time to time should be taken for what they are: high-level abstractions that can’t be acted upon. An LTV model should be specific to a developer’s app: trained on that app’s data and built with the focused purpose of describing the monetization behaviors of its users.
The field of mobile marketing has grown to encompass an applied, distinctive form of data science (“marketing data science”) concerned with, among other things, the calculation of LTV for the types of behaviors that different apps elicit. This is a positive development, and it’s a modern development; any app developer with a modern operating outlook should be aligned with it.
thanks you RSS link