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 from 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: 

Warning: You cannot add custom parameters to standard events; you have to create custom events to assign custom parameters to. 

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 step's ID or name.
 

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 it is beginning properly for all players.

The more custom events you add to track within the FTUE, the more you can understand user drop-off and where to optimise your game to improve player retention.
 

An item is bought
 

Every real currency transaction in the game, you should always use the transaction standard event. It is used to populate the revenue dashboard and metrics in the Data Explorer. The transaction event contains many useful parameters to register what the player purchased, how much they spent and what they received. All the parameters under the productsReceived and productsSpent objects inside the transaction event provide the details on what 
 

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

The standard transaction event can also be used to record virtual currency transactions or item exchanges, but you cannot add additional custom parameters to the standard transaction event, so you may want to create your own custom events for these purposes if there are additional parameters that you want to capture. 

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, pop-up 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 a custom inGameTransaction 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 visits to the shop in the player’s lifetime
• shopVisitSession: Total visits to 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 values stored over the player’s lifetime. A parameter can help you keep track of a user's history in the game.
 

Feature adoption
 

Using both standard and custom events is 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. 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 drop-off points that need work to optimise. Analyzing the 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.