Building a Data Driven Company
2 likes966 views
Ganymede is an online gaming company in Kraków, Poland, focused on data-driven decision-making to ensure player engagement and profitability. The document outlines the importance of a company-wide data culture, emphasizing accessible data analysis for all employees, experimentation, and robust communication strategies. It also highlights the infrastructure and tools needed for effective data management, along with a commitment to creativity and iterative learning in game development.
Building a Data Driven Company
- 1. BUILDING A DATA DRIVEN COMPANY Maciej Mróz CEO, Ganymede WWW.GANYMEDE.EU
- 2. WHO WE ARE • Online gaming company in Kraków, Poland • about ~80 people and quickly growing • big portfolio of free to play games, focused on social casino • Not a large corporation • still try to keep things simple and efficient • cannot operate like a garage company any more
- 3. WHY FOCUS ON DATA? • Happy and engaged players • that’s the only way to make money in the long run! • You can’t do focus tests with 100s of thousands of players • We can build anything, but how do we know what to build first? • Data is our feedback loop and a guide for the future
- 4. IT’S MORE THAN „BIG DATA” • It’s not about how much data you have • worry about limits when you hit them • Extracting value is the hard part • It’s not just a set of tools or a department, it’s a way of thinking
- 5. ENTIRE COMPANY IS AFFECTED • Market research/greenlight • Product development • Operations • KPI optimization (retention, monetization ...) • user research • community management • user acquisition • Portfolio management • ...
- 6. DATA CULTURE • Why are we doing this? • What are our assumptions? • How can we validate? • What are target metrics? • Quicker, smaller scale experiment?
- 7. DATA CULTURE • What have we learned? • If it seems similar to Lean Startup, it should
- 8. INCLUDE EVERYONE • This is not just for data engineers and analysts • Everyone has access to raw data
- 9. INCLUDE EVERYONE • 90% of data analysis problems is simple • Basic SQL or scripting skills are often enough • Give people opportunity to just do it, and not wait for someone else • Benefit of high tech talent density
- 10. TEAMS ARE IN CHARGE • Beyond basic stuff, it’s up to game team to decide what and how to track • tightly coupled game/ui design • typically part of „Definition of Ready” • team maintains their own dashboard with custom metrics
- 11. TEAMS ARE IN CHARGE • Having data engineering/analytics skills embedded in the team is always beneficial • this is what we want in the long run • Basic tasks can be done by any developer • just put these in the sprint backlog
- 12. EXPERIMENT! • A lot of A/B testing • our own tools, but you can use anything • it’s ok to try out different things • you can test much more than button colors • Make sure you learn something new about your players • Experiment on real users, too! • numbers are not everything
- 13. COMMUNICATE • Information should reach right people at the right time • harder than it sounds, especially as company grows • Sprint review • Meetings of interest groups • product Owners, Analysts, Community Managers, ...
- 14. COMMUNICATE • Dashboards • we are working on improving these • Confluence for knowledge base/product documentation • Internal newsletter
- 15. BE SERIOUS ABOUT DATA • It’s an investment, and long term one! • Data engineering team • build and operate our data tools and infrastructure • set instrumentation standards • design data schemas • develop automated workflows • ...
- 16. BE SERIOUS ABOUT DATA • Dedicated analysts • shared across the company out of necessesity • for our biggest games, we are heading towards dedicated analyst per team • Infrastructure • whether you go with cloud or physical, it does not come free
- 17. AUTOMATION • Repeatable tasks shouldn’t be a burden • Standard KPIs across product portfolio • it’s very important to share definitions and calculate them in exactly the same way
- 18. AUTOMATION • Common platform and instrumentation standards • In exchange: • Dashboards with standard KPIs, • Reporting, • A/B testing • All from day one on every game
- 19. OUR TOOLS • Different tools for different contexts • We are using mostly open source • Hadoop ecosystem: Hive, Pig, luigi • Python for complex processing • SQL – still very useful, but often underestimated • Custom dashboards for visualization
- 20. THIRD PARTY SOLUTIONS • Can cover 80-90% of your needs almost instantly • Should be default starting point • pick one that offers raw data access (i.e. through Amazon Redshift)
- 21. THIRD PARTY SOLUTIONS • We still use some of them • Our business is games, not analytics technology!
- 22. INFRASTRUCTURE • Amazon EC2 • Data collection (custom solution, Python + scribe) • Basic KPI calculation (Python, ephemeral instances) • Amazon S3 • Raw data storage (gzip compressed JSON event logs)
- 23. INFRASTRUCTURE • Hadoop cluster for complex analysis/warehousing • used to be a single beefy machine for a long time • way forward because of data volume
- 24. FUTURE DIRECTIONS • CRM functionalities in gaming platform • Predictive models • player life time value most obvious choice • plenty of other possibilities
- 25. FUTURE DIRECTIONS • Standardizing our workflows on top of Hadoop • maintainability and talent availability are issue with homegrown solutions • for us data volume is too big to process in timely manner on single machine
- 26. DON’T GIVE IN TO HYPE! • Start small and ignore the buzzwords • You can achieve a lot on a desktop PC • if you can import CSV into Excel you can do suprisingly much • I suggest using Python or R – easier to validate/maintain in the long run
- 27. DON’T GIVE IN TO HYPE! • Investment in data should have positive ROI • Different things make sense at different scales!
- 28. CREATIVITY MATTERS! • We are in this industry to build great experiences! • If your game isn’t fun, do back to drawing board • data can help you, but will never fix your problems
- 29. CREATIVITY MATTERS! • Gut feeling and experience are still valuable • It’s ok to experiment! • as long as you validate it afterwards, learn from mistakes, and iterate