I read an interview about VC investment in gaming companies recently in which a quote surfaced with which I very deeply disagree. The question was about what VCs look for in a gaming company; the response was this:
You need to have a great game, to know how to get users and have a finely tuned system to make the most of their customers. You can always rent features like analytics.
Obviously I can’t disagree with the fact that investors look for games of the highest quality as investment targets. And having never made a monetary investment in a gaming company, I’m not totally qualified to say whether the above is the best possible position to take when evaluating investment opportunities. But I can, from a very ground-level position in the gaming industry, say with the utmost conviction that analytics is not a feature, and it can’t simply be rented; analytics is a core component of a free-to-play game and it must be considered from the earliest stages of development. Analytics is as important in free-to-play gaming as art or server-side engineering; a free-to-play game shouldn’t be released without analytics in place.
This isn’t to say that 3rd-party tools can’t fulfill the analytics requirement for a free-to-play game: great companies like Swrve, Game Analytics, and Keen are building hosted, cloud-based analytics solutions that will outperform many companies’ in-house solutions. But these tools can’t be “rented out” at the end of a game’s development cycle, just before release: integrating these 3rd-party tools to the fullest extent requires the same amount of focus and attention as integrating an in-house analytics stack. The only difference is where the data is hosted, how it is accessed, and, sometimes, how it’s analyzed – but from the very beginning, some very serious decisions still must be made about formatting and storage.
This requires an events library – some sort of dictionary of what in-game events are stored and how exactly they’re categorized when they’re stored. Where these events are stored is irrelevant; this system still requires careful consideration during the development phase. This kind of consideration isn’t “renting an analytics system”; it means an analyst attends daily scrum meetings and works closely with the engineering team to create meaningful, coherent event signals that capture enough information to be useful.
Here’s a case to consider:
Company A decides to make analytics an integral part of development from the earliest stage of the development cycle. Each new feature is assigned a number of events from an events library, and these are tested as part of the QA process. By the time the game launches, the analytics system (they’re sending their events to a 3rd-party system, as Company A is small and doesn’t employ a full-time analytics engineer) has been tested for load and completeness. When its game launches to limited Beta, Company A is able to adjust gameplay mechanics and economic balance based on simple queries to the analytics system; Company A uses only SQL queries and Excel to analyze its data, but it is still able to derive some high-level insights into how its players use its game. By the time it launches its game globally, it has adjusted its game to player behavior and optimized the experience significantly.
Company B believes analytics can be “tacked on” at the end of the development cycle. Because of this irreverence for analytics, it doesn’t develop an events library during development; instead, it merely tracks revenue data. When Company B launches to limited Beta, it knows only when players buy items – and nothing about their behavior after purchasing those items, or, more importantly, prior to buying those items. Company B knows its Day One retention and some metrics about engagement, but not much more than that. It decides to launch globally after a month in Beta, knowing nothing about retention beyond day one or customer segments.
Which company, given equally high-quality games, is better positioned? Company A, without a doubt – not because it has more data, but because it can react more easily once in-market to poor performance and better understand its players. Company B enters the market blind: it can’t understand how different groups of players interact with its game. This is a problem, because free-to-play mobile games shouldn’t be designed for whales: they should be designed to bring in the largest number of players and – using the data they collect about behavior – tailor those players’ experiences to their preferences. Company B can’t do that; it can’t successfully execute on the free-to-play imperative.
Mobile- or Web-first development is a high-level strategic decision; analytics-first development is a practicality. Any studio not developing games analytics-first is assuming a massive liability: if its game doesn’t perform well in-market, then it will have no recourse to improving the user experience beyond intuition. And intuition will be what got that company into trouble in the first place.
Recent