<http://schema.org/articleBody>
"Julian is a heavy-duty number cruncher for Wooga, a mobile games developer based in Berlin.\u00A0\r\n\r\n\r\nThere\u2019s one unfortunate truth about mobile game development. You cannot make a great game, offer it for free and depend on the masses downloading it. The app marketplace is packed, with every publisher desperately vying for players\u2019 attention. This makes that attention all the more costly to acquire.\r\nMost developers will, at some point, face the problem of getting people to use their app without dangerously overspending while doing so. They need to buy users at a price where they get a positive return on their investment (ROI). Working out ROI, in essence, requires just two key variables:\r\n\r\n\r\n\tcost per install (CPI) \u2013 how much it costs to get a user to download your game, and,\r\n\tlifetime value (LTV) \u2013 how much each user spends on your game\r\n\r\nIn general, ROI is roughly LTV minus CPI \u2013 what the user spends on your app minus what it costs you to acquire them. (You can also account for ad revenue and viral effects, but I will disregard this here for the sake of simplicity.)\r\nWhere CPI is fixed by supply and demand in the mobile advertisement space, LTV depends heavily on the product. How well does the app monetize? What variety of in-app purchases does it offer? How well does it retain users?\r\nIt is impossible to perfectly know the value of a user before they stop playing the game. You can only estimate it, i.e. make a statement about the probable value of a user. This is where the Golden Curve comes in.\r\n\r\nHalf a year strikes the balance\r\nIn early summer last year, I wanted to estimate the LTV of users in our games. Not through some sophisticated approach, but something that intuitively made sense and everybody could understand.\r\nI started hacking the data and methods. One of the key questions around LTV is how long you give your users to reveal their value. A user\u2019s LTV accumulates by days in the game. If you give it a year, you\u2019re on the riskier side because you have to wait so long until you earn back your spending on user acquisition. This can be especially tricky for small companies.\r\nIf, on the other hand, you only give it a few weeks, you end up with a low LTV and can hardly ever run profitable user acquisition campaigns. A commonly accepted compromise is half a year.\r\nSo, what I was actually interested in was the cumulative spending of a user on day 180 of gameplay. Put a bit more formally, I wanted to estimate LTV (day 180).\r\n\r\nKeep the cohorts coming\r\nWhen you run user acquisition campaigns, you never buy a single user, but groups of users. This is done by setting a bid price with a certain ad network in a certain country for users with a certain device.\r\nA prediction can also best be done in terms of what is expected on average from a group of users. LTV (day 180) for a user can be conveniently estimated by dividing the cumulative spending of their cohort until day 180 by the number of users in the cohort. \r\nCohorts are subsets of all the users that enter your game, e.g. \u2018daily cohorts\u2019 are the users that joined your game on a particular day. You may also segment your new users by country, ad network and/or device and look at each segment\u2019s cohort separately.\r\nThe blue dots in figure 1 show the actual figures for cumulative spending by day in the game for a day\u2019s cohort in a big freemium game. You can nicely see how the cohort spends less and less the longer it is playing the game. The main driver behind the decreasing spending is retention, i.e. that less and less users from that cohort are actively playing.\r\n\r\nFigure 1: Cumulative spending along days in the game for a daily cohort of a big freemium game\r\n\r\nThe pitfalls of curve fitting\r\nHave you ever just played around with an Excel chart to get a clearer idea of your data? If so, you\u2019ve probably come across trendlines at some point. It\u2019s that nice function that lets you fit a variety of curves to your data (figure 2).\r\nIt turns out that it is pretty easy to find a well-fitting curve ex post, i.e. when you already have data right up to day 180, but it definitely has its problems. The blue line in chart 1 shows a power function fitted to the actual spending data points. The red curve shows what happens when you fit a power function for the same cohort with only seven days of data.\r\nIn this case, it could lead to you underestimating the actual LTV by almost a third. Not good.\u00A0\r\n\r\nFigure 2: Curve fitting in Excel\r\nOf course, you can also apply curve fitting to other metrics, such as retention. Day-x-retention tells you the share of a user cohort that is still using the app on day x after download.\r\nRalf Keustermans, CEO of Plumbee, outlined in a recent presentation how using curve fitting for retention prediction had fooled them into believing their LTV would be $9 USD \u2013 it later turned out to be $2.50 USD (slide 2 of his\u00A0presentation).\r\nThe key point here? Regular curve fitting for retention and monetization predictions can lead to serious misperceptions.\r\n\r\nMoving a tiny bit beyond Excel\r\nSo, it seemed like I would have to put in some more work to get more reliable estimates. The first thing I decided to improve on was precision of the fit.\r\nThe curves that Excel allows you to fit mostly have two parameters. In the linear case, this is something like LTV (day x) = a + b*x.\r\nYou can use high order polynomials, but this runs a high risk of over fitting and generating ridiculous predictions. The curves that had produced the best fit so far were power and logarithmic functions. So, I needed a program that allowed me to increase the number of parameters and also use combinations of different functions.\r\nLuckily, there are a bunch of freeware tools out there that happily fit functions of higher complexity to your data. Generally, there is a trade-off between departure from a simple functional form and increasing fit. The more complex your function is \u00AD\u2013 i.e. combining three classes of functions and having tons of parameters or a polynomial of degree eight \u2013 the better it will fit to your data.\r\nHowever, this also means it will perform poorer\u00A0for out-of-sample predictions. For a very accessible and highly informative tract on this, see page 6 of Hal Varian\u2019s recent contribution\u00A0(I would heartily suggest you read the whole thing.).\r\n\r\nThe Golden Curve\r\nYour prediction will also get more precise, the more data you have. In our case, the further our users proceed in the game, the better we can predict what their LTV (day 180) will be. Fitting a power function on day 90 will get you a better prediction for day 180 than fitting it on day 7.\r\nFrom my experience, it makes sense to wait until the cohort under study has reached day 30 in the game. Then you can really start betting on your predictions.\r\nYou should also\u00A0make sure that your sample is of a sufficient size. There should at least be a couple of hundred users in the cohort. \r\nAfter fitting a number of functions on a number of games, my Golden Curve ended up being a logarithmic function with three parameters. So far, it has been the most robust in producing predictions on only a few days of data while still providing a convincing fit over a longer period of time.\r\n\r\nDo you really strike\u00A0gold from this curve?\r\n\r\nSure, if you have a great product. But what I described above is an intuitive and comprehensible approach for estimating lifetime value in freemium. You will not have a hard time convincing anybody that it kind of makes sense. However, this comes at the cost of precision.\r\nRunning a real data science model will give you more precise estimates \u2013 and empty faces from product teams when you try to explain it to them. Also, small developers may find it hard to provide the resources for a data science model.\r\nIn any case, it pays to use several methods. I like to triangulate forecasts. That is, use three different approaches and compare results. If variance between them is very high, they are likely all wrong. If not, that\u2019s a good sign. For estimating lifetime value, another simple approach is the spreadsheet method.\r\nBack in summer last year, we already had a data science model in place. So, there were my three values to triangulate: data science model output, spreadsheet method and curve fitting.\r\nIf you don\u2019t have data science estimates at hand, you can tap the industry. Ask your peers what their LTV is. If you cannot do that for whatever reason, check Chartboost\u2019s insights.\r\nThe cost per install (CPI) in the segment that you target shouldn\u2019t be awfully different from the LTV estimates that you get. I\u2019m sure there are other ideas out there to get quick LTV estimates or at least an intuition on what your LTV might be \u2013 so let's discuss: how do you do it? What\u2019s your Golden Curve?\u00A0"^^<http://www.w3.org/2001/XMLSchema#string>
<http://thenextweb.com/dd/2014/06/12/golden-curve-determining-player-value-freemium-apps/>