Understanding Event Tracking in Games

What do I need to track in my game?

Think of it this way: whenever you design something in your game, you should have an intention - a reason why you are doing it. You should track how players interact with your game to validate your intentions and answer any questions you might be asking yourself when designing the game.
 

• How difficult is this level?
• Is my tutorial easy to follow?
• Have a lot of players purchased this cheap offer? 
   

For any intention that needs validation, you should orchestrate one or more events to answer all your questions. Using the same example, “Is this level as hard as I think it is?” Here you could track player death, where they die in the level, how many tries it takes on average to complete the level, how long it takes, what are the most popular items used to finish, etc. Back to the basics though, let’s dive into how analytics works before starting to track data points.

Custom events and Parameters

A custom event is the action or the result of an action by a player or your system in your game. Virtually, an event can be anything and everything you want : 

• A player finishes a dungeon
• A player joins a guild
• An offer is displayed to players
• A player buys something
   

Now that you have your events, you can use parameters that are basically details of the event that give you specific information. For example, a player finishes a dungeon; this event would be dungeonCompleted. The parameters, depending on what you want to learn out of this event could be: 
 

• dungeonName: indicates which dungeon was finished
• time: Indicates how long it took for the player to finish the dungeon
• playerHealth: Indicates the health of the player at the end of the dungeon
• potionsUsed: Indicates how many potions the player consumed to finish the dungeon
   

Any detail about the event you need should be a parameter and you should always ask if an event could actually be a parameter inside another event. This will make creating visualizations easier and unclutter your event schema. An example of this would be the missionCompleted event, which should have the parameters missionName, missionID, etc

Standard events

The good thing about Unity Analytics is that it collects standard events automatically once you have integrated the SDK into your project -  events which every game needs. In addition to being collected automatically, these standard events are used by dashboards that are out of the box and metrics that you can use in the Data Explorer. (link)

These standard events include: 

Tip: you can add custom parameters to standard events so you don’t have to create other events if you need custom details on standard events. 

Common tracking scenarios

First time user experience

In this case you usually want to check how many players complete the tutorial. The simplest way to do it would be to use the standard event, newPlayer and one custom event that will trigger once a tutorial step is completed like tutorialStepCompleted with the parameter stepID to indicate the ID or name of the step.
 

If you want more granularity in your tutorial analysis, you can also add an event that tracks when the tutorial begins so that you can determine if the tutorial is beginning properly for all players. You can also add an event when the tutorial ends when a step is started to follow every second of the player journey in the tutorial. 
 

The more custom events you add to track within the FTUE, the more you can understand user drop off and where to optimize.
 

An item is bought
 

For every virtual or real currency transaction in the game, you should always use the transaction standard event and add custom parameters to accommodate your needs. The transaction standard event is used to populate the revenue dashboard (link) and metrics in the Data Explorer (link). You can validate your revenue using the transaction event and the unity IAP plugin. The transaction event already has many useful parameters to register what the player spent, how much they spent and what they received. All the parameters under productsReceived and productsSpent will help you get set up.
 

When tracking purchases, it is imperative that you track purchases in USD as separate parameters as well as local currency in order to normalize data and to have accurate revenue metrics. The transaction event is a standard event and can be either triggered manually by the customer or automatically fired if the Unity IAP is integrated into their game
 

Let’s say you’re developing an RPG where the player can buy and receive heroes, gear and resources from multiple points such as the shop, popup offers and a daily reward system. The following parameters will help register most of the information of your transactions. 
 

You could add a few parameters to the transaction event:
 

• source: on which point the item was bought (shop, popup offer, daily reward) 
• heroLevel: the level of the hero the player bought
• gearLevel: the level of the gear the player bought
• dailyRewardDay : If the reward is received from a daily reward, gives the day number
   

If the player buys something in the shop, you could analyze how fast the user bought this item after seeing it for the first time with those parameters:
 

• shopVisitTotal : Total visit of the shop in the player’s lifetime
• shopVisitSession : Total visit of the shop in this session 
• offerImpressionSession : Total impressions of the offer this session  
• offerImpressionTotal : Total impressions of the offer in the player’s lifetime
   

Notice here that some parameters like shopVisitTotal are a value stored over the player’s lifetime. A parameter can help you keep track of a user history in the game.
 

Feature adoption
 

Using both standard and custom events are key to measuring the success of new features within the game and how users adopt them. For example, say we introduce guilds into the game, a feature which is very important for long-term engagement and player interactions, especially for RPGs. Implementing the following events would be important to tracking guild engagement:
 

• guildJoined - user joins a guild
• guildLeft - user leaves a guild
• guildMessageSent - user sends a message in guild chat
• guildRole - user has an admin role within the guild
   

Analyzing each of these events will help you determine how active users are with the guild feature and they can also be used with existing events to determine their overall engagement with the game as a whole. Try comparing users who join a guild versus those who do not, it’s possible that users in guilds spend more money or play more often. These are all experiments that you can do to help optimize everything in your game. 
 

Player lifecycle
 

Tracking the user’s lifecycle throughout the game is very important to determine when they stop playing the game or to identify any other issues with the game. Using our current game example, you can track users by the following events:

• characterLevelUp - the current level of the user
• Transaction - when a user makes a purchase
• guildJoined - when a user joins a guild
• currencyGained - amount of in-game currency gained 
   

Using a variety of these events will be extremely useful to see how users are engaging with the game and if there are any dropoff points that need work to optimize. Analyzing level distribution will show what level users are getting to before they stop playing. Additionally, tracking their transactions is important because you want users to purchase since spenders tend to be more engaged in the game and last longer.