How to Plan and Track Events in Mobile Games

At one stage in your career you’ve begun to care about data. You decide that you want to know what your players are doing, so you start tracking gameplay events. You track everything. With a flurry of code your app is sending tracking events for every card combination, move, spell effect and battle stat!

Pat yourself on the back, you have created terabytes of garbage.

“Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom.” Clifford Stoll, Physicist

Data collected without reason is just data. To be able to make informed decisions you need context, and only by understanding your player’s intentions will you start to be informed. There are a lot of similarities between mobile games and therefore there are some very standard metrics you might look at. We’ve created a simple tracking plan that you can use to get started.

Mobile Free to Play Tracking Plan

A tracking plan is the first step to getting useful information. Use it as a guide to help your whole team design and create events. Feel free to make a copy and customize it as you see fit. The code section on the right assumes you’re using FB Analytics and Unity but this can be easily adapted or simply left out. You can open up the template by clicking the image below ????

The plan leans on three ideas and applies them to Mobile Gaming.

1. GQM (Goal,Question,Metric) Model – Wikipedia
2. Pirate Marketing – 500Hats – Dave McClure
3. MVT (Minimum Viable Tracking) – Mobile Growth Stack

The GQM model lays out the right order to think about your events. You always need a goal in mind then to ask a question that can be represented as a metric. Pirate marketing gives you a way of easily thinking of 5 important high level goals that matter to marketing and growing all free to play mobile games. MVT provides a framework for focussing on creating the right events in the right order.

Together these methodologies can help you to plan the lowest number of valuable events. When an app or game is young, it’s more important to understand what’s driving your users to convert to payers. Conversion, or lack of conversion, kills more apps than low retention. If you can’t make money from your game, you have not got a viable free to play product.

You can use the plan as a pure planning tool or you could use it to help track the implementation of the events in an app. The plan comes with the basic events most games would need to make simple marketing decisions. As every game is different, creating goals and questions that are specific for your game will be up to you.

Designing Questions

Using the GQM model you first set a goal for the game. Goals can be very specific or very general, but all apps face similar problems when they are starting out, they lose users and users don’t spend any money. Dave McClure’s Pirate Marketing provides 5 large goals that, if perfected, will drive high growth for your app. These are commonly referred to as AARRR. Say it with a swagger and cutlass in hand! ☠

A – Activation – getting people into your game.

A – Activity – getting people to use your game.

R – Retention – getting people to come back to your game.

R – Referral – getting people to talk about your game.

R – Revenue – getting people to spend money in your game.

Each category provides a clear goal for your app. You want to encourage more actions in each category and you want to know why some actions are better than others. Setting goals for your core gameplay should focus on what is driving players to play my core loop more?

After choosing a clear goal from a category such as Activity, a common question might be “where do players spend most of their time?”. Now, pause a second. Why have you have settled at this question? Is it that you feel you already know the answer, “People spend most of their time fighting!” (feeding a bias) or is it “Fighting leads to higher conversions, people should fight more!” (improve a KPI)? Try to always think of questions in a quantitive manner, where you’re not setting any bias but let the data speak. Perhaps “What actions do people spend most of their time doing?” can reveal some useful information. You could then decide on a set of metrics that work well in your game.

What’s driving your users to convert to payers?

Dave McClure’s Pirate Marketing talk provides 5 good mental anchor categories for most apps and free to play games to focus on. The nature of mobile gaming, in a market which is highly competitive and effectively commoditised, means the Retention category becomes a strong focus for teams to improve. You may want to defer the Referral category until you have built out and got an app that has a stable and monetising user base. During soft launch you want to also focus on the FTUE / top of the funnel actions because this will be where most of your users will churn, there is a separate tab on the plan specifically to map out your FTUE. Remember conversion is king and even if you have a high churn rate of say 80% in day 1, if you have a high conversion rate of >5% then you still have a viable free to play product.

[bctt tweet=”The goal of all tracking is never to tell you what to build, it can only tell you how badly you built it as no feature is 100% effective #gamedev ” username=”GameAnalytics”]

To further aid all tracking I suggest you always create an XP system and provide it as a dimension in core tracking events.

XP is one of the best and simplest ways of segmenting your users. XP is an ever increasing metric based only on actions in game. You should always try to include XP as a system in your game, even if you don’t surface it to the player, as it’s so useful for tracking. Using XP levels as a bucket to separate users who have performed a similar number of actions allows you to detect points in game time where your designs start to fail.

The goal of all tracking is never to tell you what to build, it can only tell you how badly you built it as no feature is 100% effective.

Designing a Tracking Event

Let’s take the classic Base, Battle and Build game, Clash of Clans. As a game designer you may want to know the answer to “How often do people win their battles?”

Firstly, we must establish that battling is the critical element in this question. For now, we only need to know just enough about the battle from the point of view of the defender and attacker. In Clash of Clans people search many enemies before committing to an attack so the first metric should be a count “enemiesScanned”. Next, once an enemy is picked the battle commences, to answer the question we don’t need to know anything about the battle itself such as which troops, how much gold the base contained or what Town Hall level they are, we simply need to know the win or loss rate. Even though this extra information is interesting, stay focussed on your initial question for now.

There are 4 outcomes from an attack in Clash, either 1⭐, 2⭐ or 3⭐, or a loss 0⭐. Therefore we need to record these outcomes as “attackOutcome” we may want to go further than this and also send over the “totalDamage” as an integer 0-100. This might give us some useful information in qualifying what type of win it was.

Here’s how it might look on the tracking document:

KPIs and custom KPIs

A developer should now be able to create an event on any platform and you should be able to quickly check how many battles result in a win (1-3 ⭐) or loss (0⭐). To add some more information to the result the enemyScan/Battle ratio could be important as more scans might have a big effect on BattleWin rate. If you feel satisfied that this has answered your initial question, you can now repeat the process to add more depth. Create a new line and add a new question and try to use as many of the same variables as you have already created. You may want to know if battle win rate varies if the player is a Payer/Non-Payer or changes with XP Level? Don’t go wild here or you will suffer from analysis paralysis and then the outcome won’t be useful. It’s always easier to add than to take away, so start with the minimum.

To make life simple, games use common KPIs to measure themselves against other games. Many KPIs come as standard and are useful benchmarks, DAU, ARPU, ARPDAU etc. Standard KPIs are a great way of comparing games with each other. However, if your game does not fit within normal ranges, you don’t always need to worry. Your game might excel at some KPIs but not others and you should capitalise on that. If all your KPIs are low, you will have a hard time building them back up and you might want to Kill your Project.

Creating a KPI target will allow you to aim for something with your tracking. Coming up with the target requires some research (see the latest Mobile Gaming Industry Reports) for your games genre as each can vary wildly. We’ve also seen many benchmark metrics drop over the years as competition on the app store gets more fierce.

You can and should set your own custom KPIs. These are measures that are specific and matter greatly to your game. When creating a KPI try to think of it as a number that is critical to the well being of my game or users. You can then start to measure and improve it by adding features that help or communicate these functions to your players. Uncommon but generic Events/KPIs that I find helpful are:

• % Tutorial Complete – how many people get to tutorial complete event?
• Completed Views per DAU – (video ad monetisation)
• Min, Max, Median Rounds to complete – (level, world, track, mission)
• 1st gem purchase – what did a user buy after their first IAP?
• Playtime Tracking – count of total number of game minutes inside your app?
• Sources/Sinks – Which actions are providing most currency and most spend in app?

Every game is different but usually when you playtest or watch other people play your game you will notice points where people “get it” or moments of joy where every tester got really excited and wanted to play more or play further. When coming up with a KPI talk with your team and be quite limiting initially. Work hard to establish which custom KPI will help with the project in the next 2 weeks, not one that you think you’ll need in the distant future.

A Good Dashboard

Displaying your data in a simple format is the next step. There are a number of different dashboards you can use or create and many services that provide them. It’s a choice of preference which analytics provider or dashboard you use as they don’t need to be from the same company. The best companies try to own their own data so that they have flexibility in how it can be presented. This is no small task and so only larger studios with strong revenue should consider building it themselves. Free services do provide good dashboards but are less flexible and you will loose or share direct control over your data.

A Good Dashboard

A Bad Dashboard

There are many way to represent data but I like to try to keep the following in mind.

1. Every piece of data needs a comparison period if possible. Usually 7 Days or 30 Days will work best
2. Use colour to represent clear changes in figures when compared to that comparison figure
3. Display real numbers where possible to get a sense of the data.
4. Every chart needs a scale or an axis
5. Flexibility to flip charts to display data by major shared dimension, such as XP or Days since install.
6. Have separate dashboards that answer specific questions or topics in your app, not one dashboard to rule them all.

Dashboards don’t need to be pretty, they need to be informative and they need to be good at revealing trends. No matter what your data is telling you, the trend in your data is more important. If you are increasing your 1D retention by 0.5% per week for the last 4 weeks, that’s much more valuable than a 1D retention being 32%. A dashboard should clearly reveal the trend and allow you to filter or view these trends against time or app version. Versioning is an important aspect of software development as it allows your to clearly know the code that people are viewing. Any dashboard software that makes it easy for you to filter your views by version help you to see trends as your software develops.

Be aware of your Dashboards audience. Some dashboards and KPIs are meant for marketing teams (top level, money orientated) some for your design team (progression, churn, feature usage) and some for your developers (errors, crashing, load times) if you’re creating a dashboard be sure to check that it’s the relevant information for the audience.

Summary

Everyone puts analytics in wrong the first time; we all believe we know how our players are going to play, but once real users use the system things change.

If you’ve not sat down and used the GQM approach before then give it a try. There’s nothing worse that joining a project and realising that all of the data is garbage and that picking through and joining tables will be a tiring a painful process. Starting with the smallest but most useful data points will allow you to stay razor focussed as you develop your game. Using a tracking plan will also pay dividends in the long run as you can go back through and remember why you tried to track something in the first place.

[bctt tweet=”Everyone puts analytics in wrong the first time. We all believe we know how our players are going to play, but once they use the system things change #gamedev” username=”GameAnalytics”]

Tracking needs to work for the project and to do that it needs to be easy and accessible for all. I’m a great believer in sharing your data openly and freely with everyone on the team as it allows everyone to see how their work affects the product. A great set of dashboard is the best way to do this. The whole process of using data effectively is not a simple task in game development, but the best companies use it every day, and the greatest companies create a competitive advantage through it. Start small, focus on events that matter and continue to make informed design decisions.