(This short series is written to give some guidance on the basics of working with game data. It gives you some idea of the fundamentals, such as what data to track and when, how to figure out whether data is actionable or of good quality, as well as a final case study. Get in touch with us if you’d like to know more.)
In the previous post in our series on data basics we discussed some of the typical problems with game data and what to measure in order to understand how your game is working. Now let’s talk about when and how you should be taking those measurements.
Most data hooks trigger from either a user action or game event. For example, to capture the number of users entering into an in-game store, you could track every time they clicked on the store icon, or followed a notification about a new item added to the store. You could also measure how many times users returned to the store in a session, a day, a week etc, and even get a sense of whether your user population contains a few very active store-visiting users, or whether store visitation is a common occurrence. Capturing this particular type of data whenever it occurs usually makes sense because it relates directly to monetization.
However, some other data sources can or should only be collected only at a particular frequency. This prevents massive data dumps, where an event generates so much information that it becomes impossible to make sense of. For example, tracking changes in player stats might happen so often that you only want to check for changes a few times a day, to avoid having the event generate so much data that it overloads you. Keeping such data clean and in a usable format really helps when evaluating its worth.
It’s also important to consider data in relation to the maturity of a game. For example, if your game is still in beta then data is often muddied by balance changes, technical instabilities, A/B tests, or feature polishing. And so comparisons across game versions create the possibility of making large errors in analysis. Games in beta also often attract slightly different audiences than launched games, and sometimes player activity in beta can skew assumptions about how players will behave post-launch.
Even post-launch data sometimes needs to be considered in this way. It’s very common for mobile games to soft-launch in smaller territories like Ireland or New Zealand, for example, to see how a sample population reacts to them. This allows developers to judge what changes might need to be made before they launch into much larger and more expensive markets like the USA and spend a lot on user acquisition. From a data perspective this practice is often very helpful, but the developer should have a sense of what they’re trying to measure and what’s not super important to know during this phase.
At the alpha/beta phase analysts are often looking to ensure that the data is being generated correctly for the major KPI triggers like install, DAU, purchase, etc. For soft launch the goal is to validate KPIs and create benchmarks to test whether the product will be stable and sustainable. Hence metrics pertaining to player engagement, FTUE funnels, etc. should start to be tracked. But at this phase it’s probably futile to spend a lot of time trying to understand the finer lifetime value of the soft launch audience (because the game is too new), or get too specific about audience segmentation.
Some metrics simply have to wait until a game has matured enough to have generated enough data. Once the game has matured, more complex and intricate data can help find opportunities to grow KPIs, such as current win to loss ratio of fight systems, assets in player inventory, user preferences from multiple live events, etc. But it’s rare to be able to achieve that in the early days.
Now that you know what data to collect and have some idea how to collect it we’ll next cover how to determine if your data is useful and how to make use of it in part 3. Watch this space for a link, or check back on our main page.