"You don't need to be a data scientist"

Back in the day, you built your game, shipped it and waited for the results. Your game was either successful, or it wasn't. Fast forwarding to 5-7 years ago, when analytics for games became a thing, most approached it with caution. Fortunately, the mentality has changed over the past years. The industry now gets that using game analytics does not allow for skipping the "fun" ingredient, but it will help you smooth out the kinks you have in your game, discover what is broken and needs fixing, and optimise your KPIs.

Surprisingly though, I still see it being underused. I think that ties into a recurring question we get at GameAnalytics: where do I start my analysis?

First off, I'd like to clarify that anyone can do analytics. All you need is to assign someone at your studio to be the person in charge of data. This doesn't necessarily mean you need to hire a new team member. Anyone from your game designer to your producer are quantitative people, and they'll be able to make sense of the data and use it to make better decisions in their roles.

One important thing is that this person will need to really partner with the rest of the team to get answers based on the data you have, be those for questions about design, monetisation, etc.

For deeper types of analysis or benchmarking, you can always approach outside consultants (like Analytics Ops) that can help out with one off reports, be on retainer, or extend the insight they have handling a wide network of games - something to which an in-house analyst would not have access.

Start out by creating an explicit plan of how you'll use data to inform the decision making around creating, developing and operating your games. My advice when approaching this process is to begin by jotting down information around three major components: the context, the questions and the data & tools.

I strongly believe that this process will help you keep focus on what's important, as once everything is set up you will be inundated with data. Let me walk you through these components, one by one, and explain what each should encompass.

First thing you should be writing down is the context of your game. Something like:

• Where are you in your development?
• What is your competitive landscape?
• What are your KPI goals? What kind of metrics are you shooting for?

The questions you have about your games will most likely fall into the core tenets of running a game as a service: acquisition, engagement and monetisation. You might also have some questions that are tactical in nature.

• Do players get past level 1 in my game?
• How many installs do I have per day and where are those installs coming from?
• What makes players make a purchase in my game?

I start with these 3 big questions:

Of course, these aren't sufficient in and of themselves, but there are a powerful place to start. Once you find out the answers to these, everything will unfold, and you'll know where you need to dig in and drill down with your analysis.

The next part of this process should be documenting the data and tools you have available for answering your questions:

• What events are you tracking in your game?
• What format is your data in, and how can you access it?
• What tools are you using for analysis? Will you be using Excel, R or maybe GameAnalytics?

These steps will help you figure out which questions you'll be able to answer based on the data and tools you have available. As an example, GameAnalytics has 5 event types that we think cover 90% of everything you'd need to track in your game. One of these are business events for tracking real money transactions, which capture the purchase receipt from the app store, to validate the purchases and ensure that your monetization data is reliable. If you have an in-game economy, you should be tracking what your players "sink" (lose) or "source" (gain) their resources on, be them virtual currencies, lives, XP, etc. This can be done with resource events.

I've seen a lot of cases in which very good games, with well-known IPs, were churning players due to what proved to be a very difficult level introduced very early in the game, and which made them lose players before they got to become engaged. Progression is very important to track and analyze, so you can work on level balancing. In the GameAnalytics tool, the player progression event has a 3 hierarchy structure (for example World, Level and Phase) to indicate a player's path or place in the game in a granular manner.

When choosing an analytics tool, the first thing I look at is what type of products it's intended for. Integrating a games specific tool is very important, as this should ensure you'll get most of the analyses you need out-of-the-box, without the clutter of unrelated features. However, each game is different, so you should also look into being able to define custom events that will suit your analysis needs.

Once narrowing it down by these factors, one that is decisive for me is whether the tool offers the ability to download the raw data. This will enable you to drill down as much as possible (user level qualitative analysis) by querying the data yourself. For the latter purpose, I like to use open source softwares, that have strong and supportive communities, such as R.

By the end of this process you will have a comprehensive playbook: you have the context of your game, what questions you want to answer and the data & tools you will be using.

Congratulations, you are now ready to start your analysis! The good news is: you don't need to be a data scientist to make informed decisions for your game. To get a few ideas on the sort of analyses you can start on, you can check out the presentation I gave at Casual Connect last autumn. It runs through the types of analyses, when to use them and "how-to" examples. Enjoy!