(This short series is written to give some guidance on the basics of working with game data. Get in touch with us if you’d like to know more.)
In parts 1-4 we’ve gone through what to measure, when to measure, how to focus data on actionability and assess it for quality and relevance. For our last part let’s look at a case study that brings these lessons together.
Let’s say the design team of a world class fighting game is introducing a new character. Their hope is that the new character will help improve both revenue and engagement, meaning that players will like the new character enough to want to acquire and play with it. To stimulate that, they plan to introduce the new character alongside some live events that allow players to earn a character-specific currency, which perhaps can be converted for customization items for the character. The character can be won through live events by collecting character fragments or purchased through packs using hard currency or soft currency. All of which will only be available for a limited time.
What should be measured, when, why, and how will it be assessed for quality.
As the developer is interested in how the character will improve both revenue & engagement, the simplest starting point is where those numbers currently stand in comparison to other new character introductions in the game. That might give a sense of expectation as to performance for the new character, but equally it’s important to look at how multiple instances of such events might have changed in performance over the long term. Does introducing new characters tend to give a steady result, for example, or is the audience responding less and less. Are they bored of seeing the same thing and need to see something new? Do you need some qualitative data to understand this? Maybe.
As to what to track, it’s probably a good idea to obtain these:
- Unique users that played the game when the character was live.
- How many users engaged with character content (through live events or buying the character specific packs).
- How many users managed to own the character.
- How many users managed to acquire character customization items.
- How many users further used the character or the items. Did they like the addition of these elements or did they quickly lose interest?
- Total purchasers, purchases & quantity of character specific packs (hard currency & soft currency) and conversion.
What kind of event hooks should you use to find out these sorts of numbers? Here’s a potential list:
| Sl. no. | Trigger | Char | Char 1 | Char 2 | Char 3 | Num1 | Num2 |
|---|---|---|---|---|---|---|---|
| 1 | Player views any character specific events | Character name | View | Event Name | |||
| 2 | Player engages in live events by clicking on fight | Character name | Engage | Event Name | |||
| 3 | Player wins character fragment | Character name | Fragment earned | # of fragments won | Total fragments | ||
| 4 | Player wins a whole character either through event or by combining fragments | Character name | Character earned | Fragments/whole character | |||
| 5 | Player earns character specific currency | Character name | Currency name earned | Quantity | |||
| 6 | Player spends character specific currency | Character name | Currency name spent | Item name purchased | Price | Quantity | |
| 7 | Player purchases a customization item | Character name | Customization item name purchased | Currency spent | Price | Quantity | |
| 8 | Player purchases character from the store | Store | Pack id | Pack name | Real money/ other in game currency spent | Value | |
| Player obtains soft currency from conversion of character specific currency | Soft currency | Earned | Character currency conversion | Quantity obtained | Quantity of character Currency spent |
Are they all actionable? Do we really need all the data hooks? Probably not. Data hook 1 is likely not actionable, for example, because a player could view multiple live events associated with the same character and that would be tracked each time. It would generate tens of records for a single player in a single session, probably telling us very little as a result. Hence the data hook should not be placed, and similar questions should be asked of all of the above hooks.
Is the data of high quality? There are probably some redundancies that we can reduce. Data hooks 3 and 4, for example, might be telling us essentially the same thing twice. If a player needs to collect 20 fragments of a character to own the whole character, for example, then hook 3 is likely just a denomination of hook 4. Unless, that is, there turned out to be a significant game design imbalance in earning those 20 fragments causing players to fall out before completion. Then it might make sense to place those hooks back in to check. You should, however, avoid over-anticipating what might be a need as it will likely obscure your other data.
Similarly for data hooks 6 and 7, character specific currency can only be spent on customization items and customization items cannot be obtained by any other means. While data hook 6 tracks character currency spent, data hook 7 tracks customization items purchased. Either of the data hooks can be used to derive other information and it’s probably redundant to specifically know both.
As for checking for quality, in this case it’s important to run checks that identify skews in the data or incomplete data. It’s usually worth using both a combination of statistical checks (as mentioned above) as well as visual spot-checks on individual records to assess whether there are problems. What happens if half the results from hook number 9 return a zero value, for example? You can’t just assume that the monitoring event is working fine. Take a good look. Through such simple exercises carried out at the data hook design stage, you should be able to ensure data quality. Play the game, track your in-game actions and get a slice of your raw data, this will help you understand if the data is consistent with the in-game actions and is a true representation of a player’s game state. Additionally, it will help correct data type issues where integers could be captured as strings, thereby making simple manipulations more complex in queries.
Conclusion
This is just the tip of the data iceberg, but I hope that it’s helped you understand some of the things that you need to consider when working with data. Data skills are only becoming ever more important, especially in the world of bigger and bigger data sets operating in more complicated platforms. Again, please get in touch with us at Mobile Game Doctor if you’d like to hear more.
