Mobile game analytics, if utilized properly, provide insight into how your app is used, what works, what doesn’t, and where you as developers can optimize. These analytics are based on the foundation of game events being sent to you from your player’s devices. When initially looking at creating the taxonomy for your game’s events it can seem overwhelming as there is a massive amount of data that can potentially be tracked and there is a perceived need to track everything you can. Collecting data for data’s sake doesn’t lead to informed decisions about your game and can lead to analysis paralysis. In addition, collecting everything you can isn’t always scalable. The goal is to collect data that provides insight and context into your player’s intentions and what levers there are to impact those decisions.
The key to wrangling this data into a manageable level is to segment your events into a few sets, and I’ve found that the most impactful events fall into the following groupings: economy (both real and virtual), core gameplay, social/marketing, and device/user information. In addition to these core sets you’ll want to also think about which parameters you’ll want sent with every event regardless of category. These would be called your persistent parameters and should be limited to only a select few fields that will ideally be used in normalizing the data as well as making it easier to analyze the data for an end user.
This set includes real/virtual currency and inventory transactions to ascertain the economic flow of the game as well as the valuation of players. To adequately track these, you’ll want to include both incoming and outgoing transactions, also known as your sources and sinks.
In app purchases are the most vital events of this set as these are used to determine the value of your players and contribute to your bottom line revenue. Ensuring the accuracy of these events is crucial so any revenue/receipt validation events should also fall into this set.
In terms of virtual currency, typically a game will have two; one that is purchased in the store with real money (premium or hard currency) and one that is solely used within the game itself for virtual transactions (soft currency). The latter of which is typically acquired through gameplay.
Inventory tracking provides insight into how the players interact with the game. It lets you know which items players utilize the most as well as when and where they use them. This aids in balancing the core gameplay with tweaks to the experience points handed out and the difficulty of levels/stages.
Altogether, the economy events help developers create and manage the in-game economy by knowing the value proposition of virtual currency and items so both app store and virtual pricing can be adjusted accordingly.
CASE: “Why aren’t players purchasing more resources even when I put them on sale?”
It could be that your in-game economy is flooded. You’ll want to look at the average currency balances of players at different points in the game, and if necessary start putting currency sinks into the game to drain the economy. It could also be that the game is too easy at points. To answer that you’ll need to combine the economy events with gameplay events.
Core Gameplay Events
Gameplay events are used to track how players progress through a game. This set is the most versatile as it can change from genre to genre, but the core concept is the same. You want to know how far your players have progressed through your game and in what manner did they get there.
For saga style games or other linear based progression systems you’ll be tracking the start, finish, and abandoning of levels or stages. In other genres such as some FPS, CCG, and RPG style games these events are used to track the levels of experience, skill and items. These forms of progression metrics help determine how players at different levels interact with similar features within the game.
These events will not only tell you where players are in the game but also help determine the difficulty of specific levels/stages which can be used to head off any potential churn points in the game. These also let you know how many players have reached the end of content which will help determine your update schedule for new content aiding in retention. When tied to economy transactions, they provide insight into when a player makes their first purchase or where in the game the most transactions are occurring. All of which helps ensure the game is challenging yet rewarding for your players.
This set will also include the FTUE (first time user experience) which should detail player progression through your game’s tutorial. This data is vital when honing the player’s introduction to the game. These events can range from level-based tracking as mentioned above to a simple stage gate instruction process based on key topics and mechanics. Regardless these events should be labeled specifically to identify tutorial steps even though they may be redundant with other progression events. This is to ensure that you have complete visibility into the onboarding process for the game.
CASE: “My retention in my match 3 game is low, but I don’t know what I can do about it.”
This is where having progression events comes in handy. This way you’ll know where the churn points are based on the last level end event that was sent. By looking at whether your players are failing or abandoning those levels gives insight into whether the level was too difficult or not. To impact retention, you might decide to either provide players with more accessible boosts or reformulate those levels to make them easier.
Social & Marketing Events
The social events help determine the level of interaction amongst players in your game. Events in this set include gifting events and invites along with any connections to external social groups such as Facebook or Google +. This section would also be used if your game contains guilds or any other type of social grouping mechanisms. These events drive any k-factor analysis which determines the viral capacity of the game.
The marketing events on the other hand show the level of interaction between the players and you. This includes the tracking of marketing initiatives and various other channels of communication between the developer and the player. These can range from interstitial and drop-down preferences to whether or not they have rated the game, clicked on support, or accessed the FAQ. All of which can lead to insight into a player’s engagement with the game and the viability of marketing campaigns.
CASE: “I want to determine what my game’s k-factor is.”
Having the invite events is vital to accomplishing this. Without them you’ll have no idea how many have been sent out let alone how many have been accepted. Having these types of data points allows you to determine in part the impact that paid installs have on organic installs and how viral your game is becoming.
Device and Settings Events
These are used to describe the status, settings, and demographics of players’ devices. Typically, the demographics include the device IDs, manufacturer, platform, operating system, language, and country info of the device. These are necessary to know the basics of your target audience: who’s playing the game, on what type of device, and where are they from.
Events tracking the user settings and status can come in handy when the developer wishes to make tweaks to the default settings or do comparison analysis on game client and SDK versions. The latter of which is vital to understanding the effects of version updates and code changes.
CASE: “I’m updating my game client and questioning whether or not to cut support for a particular operating system version.”
Device and setting events can assist in this endeavor. If you have the game client version being sent as a device setting event you can quickly see how many of your players are playing on specific OS versions and plan accordingly. You may find that ending support for that version would cut too deep into your DAU. In addition, these events allow you to see how many players have adopted the new client version once it’s released.
Persistent parameters are considered those fields that you would want to always include in each event, and while not a core set, they are vital to data organization and analysis down the road. Examples would be user ID, game ID, event ID, client & SDK version, session ID, timestamp with time zone offset, platform, OS, user level, payer & account status, and possibly currency amounts.
When these fields are sent with every event you can more easily do comparative analysis across a broad range of data points. This can range from comparing how payers vs non-payers interact with the game to seeing if the latest update has impacted retention and engagement.
CASE: “My game is on both iOS and Android, but I don’t know if I should be treating them differently or not.”
If you have the operating system and device type listed as a persistent parameter, you can attach all kinds of good data to create profiles of your two types of players. You can determine which of the two has the longer session length, plays more frequently or has the stronger revenue stream. Combined with marketing events you can tailor your marketing campaigns to suit a particular group.
These sets should provide the contextual data needed to dig deeper into KPIs to determine why they move the way they do. They should provide insight into the product quality, retention indicators, economic flow, bottle necks and churn points, and the overall traffic flow of your game. Additionally, they can provide levers that can be used to influence and impact your bottom line.
Do know that the fine tuning of this list of events is an ongoing process. Events may arise that you’ll want to track as the game progresses through its lifecycle, but these core sets should get you the insights you need to start analyzing the who, what, when and where’s of your game effectively.
By Sean Walter