Game analytics: turning player data into decisions

Game analytics is the practice of turning what players do into decisions a team can act on. The tools are common and the discipline is rare, because most of the difficulty lies not in collecting data but in asking it a question worth answering. This is how we approach analytics so that a dashboard informs action rather than decorating a slide.

Begin with a question

Data answers questions and invents none of them. A team that collects everything in the hope that insight will emerge usually ends up with a lot of numbers and no direction. We start from the decisions the team needs to make, and work backwards to the events that would inform them.

This inverts the usual order and saves a great deal of wasted effort. If a team is not going to act on a fact, it does not need to collect it, and every event that is not tied to a decision is a small ongoing cost for nothing.

Designing events that mean something

An event is a sentence about player behaviour, and it should be written as carefully as one. The name should say what happened, the point in the loop should be obvious, and the properties should record only what a decision needs. Vague or overloaded events produce reports nobody can interpret and questions nobody can settle.

• Name events for the player action, not the screen.
• Record the state the player was in at the moment.
• Keep the vocabulary stable once it is in use.
• Retire events that no decision depends on.

A clean event vocabulary is worth more than a clever dashboard, because every later question is only as clear as the language the data was written in.

The questions worth asking

Most useful analytics work asks a small number of recurring questions, and asking them well beats asking many shallow ones. The table below is the set we return to on almost every project, from a prototype to a live game.

Dashboards for people, not for pride

A dashboard exists to help someone decide something quickly. If a chart cannot be read in a few seconds and cannot lead to an action, it belongs in the archive rather than the top of the screen. We build dashboards around the questions above and keep them small enough to stay honest.

We also make sure each panel names the decision it supports. When a number has no decision attached to it, it tends to be admired rather than used, and admired numbers quietly drift out of date until the whole board is suspect.

Reading data with the play in mind

Data shows what happened and never why. A retention curve can show that players leave at a step, and only watching real players can show that the step is confusing. We keep the two readings together, because numbers without observation lead to confident fixes that address the wrong cause.

This is why we often ask to see a session recording alongside a set of events. The pair is what produces a real finding; either one alone produces a guess, and a guess dressed as a finding is how teams spend a month repairing the wrong thing.

Turning insight into change

An analysis is only finished when it changes something. We end each piece of work with a short list of actions, ordered the way the team can actually ship them, and we make clear which finding each action comes from. A report that ends in insights rather than actions has stopped one step short of its purpose.

We also revisit the change once it ships, because a decision informed by data deserves to be judged by data too. That loop, small as it is, is what separates a studio that learns over time from one that simply collects figures and hopes the numbers will make the decisions for it.

Privacy and doing right by players

Collecting data carries a responsibility, and a studio that forgets it eventually pays for forgetting. We keep what we collect tied to the decisions it serves, we avoid anything that identifies a player unnecessarily, and we make sure the game is still enjoyable for someone who shares nothing at all. Good analytics should not require knowing who a person is.

Treating players with that care is also good practice for the data itself, because a team that is deliberate about what it collects tends to be deliberate about what it concludes. Restraint in gathering and restraint in interpreting come from the same habit, and both make the numbers more trustworthy.

Analytics as a habit, not a project

The best analytics in a studio is not a one-off audit but an ordinary habit: a clean set of events, a few honest questions, and the willingness to look at the answers before deciding. Nothing about that is exotic, and it quietly decides which games improve release after release and which keep repeating the same mistakes with better dashboards.