Delivered at Casual Connect Asia 2017. In this session, GameDesire Vice President Maciej Mroz will show GameDesire’s approach to predicting the future revenue of a game given a limited amount of data and a model based on historical data that they constructed. He will also give insights into how they managed to incorporate their model into the product management process – from high level budgeting to setting goals on product KPIs.
2. About GameDesire
• Game developer in Kraków, Poland
• ~100 people
• Social casino and casual games, web and mobile
• Free 2 Play model
3. Platforms
• Mobile - Android and iOS
• Social integrations - Facebook, VK, others
• Web portals
• GameDesire.com, Poker4Chips.com, 20+ white label
partnerships
4. Technology
• Multiplayer backend platform
• Implementing most common multiplayer features and streamlining the
development process for our teams
• Mobile and web games, multiple client technologies
(currently Unity, Qt/C++)
• Our own data engineering/analytics
5. The Challenge
• How do we know if a game will do well financially given only
basic KPIs?
• Tapping the potential of data you already have (hopefully )
• Minimizing the risk of failed investments
• That also means killing projects early
6. F2P game is always a service
• Both sides of P&L are continuous in nature
• Before launch it’s a lot simpler: just a cost side
• Launch is when things get really interesting
• Product gets improved: new content, new features, UX improvements,
difficulty tuning …
• Operations are optimized: pricing, promotions, community events, user
acquisition, infrastructure …
7. From LTV to product revenue
• Use multiple overlapping cohorts
• Every day (or week/month) start new cohort
• Calculate the sum of revenue for all cohorts created so far
• Repeat …
8. Simple LTV model
• Sum of geometric series:
𝑎
1−𝑞
• Assuming constant spending (ARPU) and cohort survival rate
(retention) over some time period we get:
𝐴𝑅𝑃𝑈
1−𝑅𝑒𝑡𝑒𝑛𝑡𝑖𝑜𝑛
• Shows value of retention and monetization
• Not very practical but ok for “back of the envelope” calculations
9. Better “back of the envelope”
• Still theoretical
• Sum of daily cohorts
• Assumes static DARPU and registrations
• Varying retention with separate control of D1-D360
• We built it as interactive website
• It’s important to have something people can play with, even knowing
it’s not very precise
10.
11. Meet Reality
• Theoretical models are good to demonstrate concepts, but real
world is messy
• Variables change over time - and vary per cohort of users
• Every product is different - and continuously evolves
• Not everything can be reliably known or tested at small scale
13. Developing your own LTV models
• Start with simple things
• Use historical data when you can
• % of cohort value over time is very practical but strongly depends on
the game
• If you can't, have it on your roadmap
• At the very minimum you need session/payments history
• Iterate
14. Our model
• Based on vast amount of historical data
• Both web and mobile - suprisingly portable
• Condensed in an Excel spreadsheet
• Inputs: D1, D7, ARPU, Churn
• Month by month KPI values to account for product improvements in
soft launch period
• These are numbers that product managers can easily measure
• Enough to build and update product P&Ls as we get more data
15.
16. Getting this to work
• Tracking and data analytics essential
• At the very minimum, make sure you own your data!!!
• Keeping data engineering and data science internal helped us a lot
• This is not only about tools
• It takes a lot time and effort to get everyone aligned
• Long term project – took us years to truly “get it”
17. Final thoughts
• Data exists to help make correct decisions, not to replace
people
• Not everything can be measured easily/economically
• This doesn't make measurement useless
• KPIs shouldn’t be just numbers in product report
• Educate people on the relationships between KPIs and revenue
• Use them to set team goals
• Correct balance of data vs intuition is a process, culture and
knowledge problem