Open up your favourite note taking application. It can be a google spreadsheet, a Sublime Text 2 file or, if you are like me, a new Evernote note. We are going through the process of starting to define your game’s event taxonomy. My challenge is that we define the most basic set of events any game needs. Together!
Maybe you have done this in the past, maybe you haven’t. If you have, you might be so used to do it that you don’t even think about the process. If you haven’t this might be trickier than you think. On second thought, it might be trickier that you think, even if you have done it in the past. In fact my objective is not to tell you what are the basic events but to introduce you to the thought process that is much more effective than just to write down all events you can think of.
And by doing that, defining the basic events. Cool, huh?
First rule of defining events: you don’t speak about events!
What is a blog without a lame reference to Fight Club?
Sometimes I’m asked if tracking an event is interesting. For instance “would it interesting to have an event when the player closes the retry level window?” My answer to those questions is always “if you don’t know if it is interesting then it isn’t.” Let’s use this example to go even further. We track the event and after a week the average number of times a player closes the retry level window is 3.2. What are you going to do about that?
You can argue this logic can be applied to any event and I will agree with you. The difference is that many other events have an actionable question backing them up. That’s why we shouldn’t be thinking about events but questions from which we take action depending on the data we gather.
Another argument that can be made is that it’s safer to collect everything. That is a dangerous fallacy. It involves vast resources to define, implement and test a huge list of events. Most of them won’t be used, many others will be missing, incorrectly defined and/or implemented. It’s better to have few events that do exactly what we want than it is to have “all” the events which brings high resourcing, high overhead and low data quality.
The base questions
Now that we are not thinking about events but about questions… what are the questions? The fundamental ones?
How is the game performing? This is about reporting KPIs (Key Performance Indicators). Often called vanity metrics, they are not actionable in the context of The Player Lifecycle but on a product/company level. If you are a stakeholder or a producer, these are actionable to you but of less relevance for designers and analysts. The following are the base questions which reflect performance indicators and the underlying reasons why they are relevant:
- How many players start playing the game? The KPI is New Users. From a strategic point of view, there are no users without new users. As I’ve stated in Acquisition 101, discoverability is a major concern in mobile metrics. Observing the trend of new users in the game is very important and will impact UA and cross promotion decisions. Likewise, observing New User trends when changes are done on virality may also be relevant but there are other, more sophisticated ways of measuring virality.
- How many players play the game? The KPI is Daily Active Users (DAU). DAU is used mostly as a denominator for other metrics but it stands out as a KPI on its own. It has impact on commercial deals, decisions on UA depending on monetisation KPIs, etc.
- What is my revenue? The KPI is Revenue. Knowing a game’s revenue is important. Many decisions are be based on it. However it is my view that The Holy Trinity should be more important for making decisions than total revenue.
I presented these KPIs as daily KPIs and that is how I present them in our dashboards. Monthly KPIs are also common and we have dashboards for them at Miniclip also. Monthly KPIs serve to understand each game as an evolving service. We do not have weekly KPIs. I have a gut feeling that weekly KPIs are more or less relevant depending on the company’s reporting hierarchy and often exist in depending on the context.
KPIs are mostly vanity metrics. There’s not much we can do about them but there are a lot of decisions that can be made by observing them and their trends. The next questions are in the context of The Player Lifecycle. They are the first actionable line for producers and designers.
- What are D1, D7 and D30 retention rates? Retention is king so that is our top priority. If you recall from Retention 101, one of the measures of “good retention” is the 40-20-10 rule. If you don’t have prior experience in your games retention, this is a good standard starting point.
- How is the game monetising? Assuming your game has in-game monetisation (downloadable content, advertising, etc) you want to measure The Holy Trinity of Monetisation: Average Revenue per User (ARPU), Average Revenue per Paying User (ARPPU) and conversion rate.
And that’s it as far as basic questions are concerned
Take a leap of faith and trust me on this one: less is more. I’ve read books that mention dozens of KPIs, blog posts about more and more KPIs and the only thing those produce are many dashboards of metrics that no one ever looks at.
With all due respect for hard work of the authors of those books and posts, my personal experience over dozens of games, millions of daily active users and billions of events is that if you can answer the above questions, you will know how your game is performing and with a bit of experience you will know what are the next questions and the next events.
And now for the big finale: the events
Now you have the questions. The trick is to transform the questions into events to be sent by the game. If you are new to game analytics this will sound to simple to be true. The good news is that it really is. As long as you make the right questions you will always have the clear vision of the events you’ll need to implement.
- Daily New Users is the count of distinct user ids on an given acquisition date where acquisition date as the minimum session date of a user id.
- DAU or Daily Active Users is the count of distinct users ids grouped by session date.
Daily Revenue is the sum of revenue grouped by purchase date.
- DX Retention Rate is the DAU that had a session on acquisition date + X days divided by the daily new users on acquisition date.
- ARPU is the Daily Revenue divided by the DAU.
- ARPPU is the Daily Revenue divided by the number of payers. The number of payers is the count of distinct users grouped by purchase date.
- Conversion Rate is number of payers divided by the DAU.
Underlined are the events. Session and Purchase are the only events you need. But it’s not so simple as sending the events. Each event should have these parameters:
- User ID: The unique ID of the user.
- Date or Timestamp: Most 3rd party analytics systems sort this out on their own. If you have a in-house analytics system or the 3rd party doesn’t sort this out (which I’ll find odd), you need to add it yourself.
- User ID: The unique ID of the user.
- Date or Timestamp:Most 3rd party analytics systems sort this out on their own. If you have a in-house analytics system or the 3rd party doesn’t sort this out (which I’ll find odd), you need to add it yourself.
- Product ID: This can be many things at the very least a distinction of the type of product (downloadable content, advertising, etc) should be made.
- Revenue: The revenue in a standardised currency.
And that is it. Two events and seven metrics is all the basic information you need to generate from your game to measure its performance. More important than this, you now have gone through the process of making questions to define the events.
This is not even the tip of the iceberg. It is a good starting point. I’m very happy with this post and I hope you took something from it.