What is important to know when you are going to start working with data?
Greetings to you, friends and subscribers, and everyone else who by the will of fate has wandered onto this page=) Today we will talk about analytics. More specifically, about how to work with analytics in the game, what data is important to track and what to do with it.
Note: the issue of connecting and setting up scripts and analytics services is a separate topic that will not be discussed now. There are a million and one more ways to do this. You can read about them in numerous sources. However, if you want to see material from me specifically about how, for example, to connect GA to a game on Steam, or how to set up events on a web platform or on a mobile phone – write in the comments, and I will try to answer your question in one of the following articles =)
Now let's get down to business.
A game is, first and foremost, a product that is developed for your users, for players. Therefore, from the first minute of its release, it is important for you to know what they are doing there, what emotions they experience, whether they are ready to fulfill your target actions etc.
A target action (this term came to us from marketing) is any activity that you encourage the user to perform to achieve your final or intermediate goal (to increase retention, to increase profit from the game, to increase some metric that is important to you). Target actions in the game can be anything: from buying items to completing certain quests. Everything depends only on your personal goals, business goals and the product.
There are a few steps that are important to take before diving headfirst into metrics and numbers.
1) Determine the type and features of your game: genre, target audience, platform, etc. That is, thoroughly study the product, think through every detail, play, imagine every detail. You must understand what can be done in the game, and most importantly, what can be changed in it in principle (for example, you will not completely change the genre or redraw a flat isometric view into a full-fledged first-person 3D).
2) Determine what data you want to receive, and most importantly, why. To increase profits, gain universal recognition and world fame, you must be able to explain this first of all to yourself and your team.
3) Make a list of the main events that exist in the game. This list will help you mark up for analytics when it comes time to do so.
4) Based on the list of events and the data list from step 2, describe what data collection results you want to see. Be sure to include all the details: type of diagrams, frequency of collections, wishes for metrics, etc.
5) View the results obtained, compare, analyze, and draw conclusions.
6) Improve the product, collect data again, analyze, draw conclusions and so on in a circle=)
For clarity, let's look at each stage using an example.
1) We determine the type and features of the game
Let's say you're making a game like this:
Target audience: housewives
Mobile platform
Monetization model: f2p with a store for donations
Duration of one session: 15-30 minutes
Frequency of visits: from 1 time per week to several times per day
Simple, relaxed plot
Slow paced gameplay
The basis of the meta-loop: investigating a murder through dialogues, searching for and comparing evidence
Core Cycle Basis: Collecting and Merging Items
Main feature: atmosphere in details (locations, music, characters, dialogues, quests – everything is stylized and inspired by the best women's novels and classic noir detectives)
User = detective
You can change:
Rewards for completing quests (type and quantity)
Items within one quest and their quantity
Scene interactivity (what can be clicked besides quest items)
User character appearance/clothing
Economy (cost of items in the store, user's earnings of coins, etc.)
Ease/difficulty of completing the quest
Hints/tutorials in the game
You cannot change:
The mechanics of the ship
Illustrations/Visual Style
History (plot, basis of the meta-cycle)
The logic of earning and shopping in the store
2) We define the data we want to receive
For convenience, we will divide them by types of goals. In the first point, I will describe for example why we collect data, in the rest I will simply list them. Of course, you should be able to justify for yourself the reason for collecting all the data, this is important.
a) For business purposes:
user path to first purchase (broken down by events)
To understand:where users drop off (after what event they leave and don’t return),
how much time passes from the moment of the first login until the first purchase in the game,
what (what event) motivates the user to make the first purchase, etc.
% of paying users from all players
Total paying users (per day/month/year)
in-store purchases (most popular items, types of goods, etc.)
conversions into purchases/tasks (indicating the path from where), etc.
b) For product purposes (for users):
average session duration
retention (rolling retention, full retention, return, range… decide which is more important to count for you or count everything to compare)
completing tasks (what, how, how much…)
skip dialogues etc.
3) Make a list of the main events in the game
At this stage, you need to understand what analytics you use and make this list in the form of a table indicating event_type, event_info, all IDs and other details so that your programmers can use them in the markup. An abstract example will not do here, and I, alas, cannot give a specific one (a closely guarded secret). But I will list the events as an example.
Let's say in our case it is:
Entering the game
Click on the “Start” button
Opening a dialogue
Click on the “skip” button on the lilog
Closing the dialog
Entering the task
Click on the item (with the item ID, of course)
Click on the “Shop” button
Entering the store
Note: clicking on the “Store” and entering it are different events. Your button may break or the interface may be buggy, and you will be indignant about why there are no visits to the store, but there are clicks on the button. Therefore, it is better to log as many events and their parameters as possible.
And so on and so forth – we describe all the events, all the parameters and details that we can.
Once you have completed this stage and your programmers/analysts have connected everything, be sure to test the bounce of all these events. It is important that the names match and there are no duplicates or typos. Otherwise, when creating dashboards and graphs, you will get complete gibberish instead of data.
4) Describe the results of data collection (what we want to see ideally)
We understand that by the word “result” in this case we mean a specific visualization, that is, a table, graph, map, etc.
Here is a description of one such result as an example:
Average session duration per user across the entire game, with the ability to drill down by mechanic.
Chart type: bar chart with grouping by minutes (in steps of 1 minus, rounded up).
The horizontal axis is the time spent in the game per session.
The vertical axis is the number of users.
5) We look at the results, compare, analyze, and draw conclusions.
Let's say, from our data and graphs we saw that:
Users are all skipping dialogs
almost no one finds the revolver behind the nightstand in room A without additional help
82% of users from all donators buy the “Pretty Maid” skin for the butler
Of all those playing the game, only 3% donate now, although 4 months ago 12% donated
What conclusions can we draw here and what decisions can we make?
First, don't rush headlong to cut out all the dialogs. Look closely at the user's path. If this step does not lead to mass abandonment, there is no reason to panic. Check if everything works. Check if there are any typos or bugs. Feel everything yourself and take another close look at the data for different dates. Perhaps you have rolled out an update where, for some reason, dialogs are skipped automatically.
Second, take your time. Analyze data for different types of users, compare indicators for different periods, study the numbers. Try to find the revolver in room A yourself, and then look at the logs. Never exclude the possibility of an error in the data collection process or an error in the event name. Check everything thoroughly.
Third, experiment carefully. If your users have fallen in love with a particular skin or a specific category of goods, do not raise prices, hoping that “they will buy it anyway.” Play with prices smoothly, balance, constantly looking at the results. And if possible, conduct tests (A/B, A/A/B, multivariate, and others, depending on your product and goals).
Fourth, consider real-life conditions. If people suddenly stopped donating to the game, although you did not make any major updates, the reason may not be in the product at all. Look at the regions of the drop, at the types of users, at different periods. Maybe people stopped paying you simply because there was a crisis in the region of their residence, a weather anomaly, or simply because the region stopped paying for purchases (and this happens).
In other words, whatever results you get, don't rush to make decisions based on them. First, study everything, compare data, feel the game yourself to go through the same path as your users. Try to see the whole picture, and not one specific outlier metric (although, of course, different things happen).
7) We improve the product, collect data again, draw conclusions, and then repeat the process.
The main thing when making a game is not to forget to refer to the data. Release an update – see if users appreciated it. Changed the design of the main page – find out if this led to a drop in conversion to the quest, and so on.
In this article, I think we can stop here. As you may have noticed, there were no complex terms, formulas or cases. I will talk about them separately in the article “Game Analytics: Basic Metrics in Game Design”. But for now, I traditionally wish everyone good luck, kindness, and see you soon=)
