Analytics 101
Think about ir. You are an homo ludus elitthat has lived inside its cave the last few months. You dream in source code and when you look outside there is a very weird shader that hurts your Main Camera. But you get used to it, because it's time to evolve, because FINALLY, you and your fellows have finished your game.
You take the usual picture showing your euphoria, that will be probably retweeted by NaN hundred people. You make a feas. You party wildly. All of it on the account of all the extensive bunch of money you are getting with yourgame. The usual story. The life of a game developer. Cave and excess alternated, like grizzly bears.
And what now? Is it over? We forget and start another game?
Nope.
Launching is only one milestone in the lifetime of a game. An important milestone, for sure, but it's not at all the last one. When we launch, that game stops being our game and starts belonging the player. His experience redefines it. We could have designed an experience and developed something that -we believe- truly transmits it, but that's never going to happen. Every user's experience will be always unique and our aim can only be to deliver something roughly similar to our expectations.
No matter how much we have polished the game, we will always find use cases that we didn't foresee. A good testing will detect most of the problems, but probably not all of them. A user that knows he is "testing" won't behave the same way a final user will.
At EducaGames, our aimed experience, putting aside unique details of each game, can be summarized in giving a fun time to children while making them review and strengthen some concepts by the way. Our designs must guide the player through the game to prevent them from passing over some parts we think are important for their learning or to contribute to the fun, so keeping their attention.
Our two first games, Monster Numbers and Dino Tim, follow a somewhat linear scheme, with a history to complete, while it's true that Dino Tim gives some freedom to choose the order in which the levels are solved. On the other hand, Buddy School, has a more open model. Its menu is offered as a playable stage from which other puzzles can be accessed.
That's an idea we love and that's why we did it, but we take the risk of divert attention from other features are important as well. The mini-game in the menu is the less educational part of the game. Is a skill test that allows you winning stars to unlock further puzzles or stickers for the album. Those puzzles, the educational part of Buddy School, can be accessed through buttons integrated in the stage.
A tester will study the stage and, probably, will recognize the buttons and will enter every game at least one time. But a user that has installed the free version and is still deciding wether if keeping the game or not, could think that the menu is all that the game has. Perhaps he won't take his time to discover that the buttons open an entire world of puzzles. Or that the button on the top-right corner shows a fantastic card collection, all of them playable as well.
Although Buddy is far from the million downloads of Dino Tim or Monster Numbers, the amount of users is already high enough. This allows using analytics and events to obtain statistical data from real users and draw conclusions and answers to our questions, that are primarily two:
- Do users like our games? They get engaged? Which ones they like the most?
- Do they even try all the games?
The fist question is highly influenced by our difficulty adjustment system trying to maintain the "flow". This is something we will discuss other time. As Groucho Marx would say, answer the second question first. To keep players playing first we need to get them playing, so this is the first question we have to answer.
As this is an ongoing work, we will talk about our analysis and result later. For now we will focusing on the technical stuff, hoping this will serve as a "howto" guide for those thinking about including analytics in their game.
El apartado técnico 🙂
We have chosen Unity Analytics, because they are very easy to integrate if the game is made with this engine. The first step is to open "Services" window (menu Window; Services). Among the available services we chose Analytics and enable it. Perhaps we have to create a project and associate it to our Unity account. We'll need also to declare the target audience in order to comply with personal data protection regulations.
With this simple step we have achieved a lot. Once activated this service in the project, with no further actions needed, we will start receiving information. The Web Unity Analytics viewer (accessible through the link "Go to Dashboard" in the previous screenshot) will provide user acquisition and retention metrics such as DAU, MAU, DAU/MAU, active users, number of sessions o session times. If we have also in-app purchases implemented with the plug-in provided by Unity, it will also show revenue metrics.
For a more detailed analysis of the game, adapted to our needs, we have to add custom events. The following code is an example of how to send the CustomEvent that we have called "EdadIntroducida" (age entered) with a numeric parameter called "edad" (age). There's no need to previously create the event anywhere or declaring its parameters. Unity Analytics console will receive and create the events and will categorize its parameters, both numeric or strings.
public static void EnviarEdadIntroducida(int edad)
{
Analytics.CustomEvent("EdadIntroducida", new Dictionary<string, object> { {"edad",edad} });
}
This method is part of a class called AnalyticsManager. To send the event we call it, from the appropriate part in another script. For example:
AnalyticsManager.EnviarEdadIntroducida (edadParseada);
The correct transmission of custom events can be checked running the game from the editor itself. To do that we have to open Unity Analytics console using a web browser and go to the tab Integration and the step Advanced Integration.
This page, along with some code examples, offers a checking area. Every event that are sent from the editor will be sown in that area, in the bottom of the page. To check the correct integration we run the game (in Unity Editor) and we force the custom event to be sent, in this case changing the age of the player.
The event shows in the checker after few seconds.
By creating events this way we can store statistical data about the usage of different parts of the app. How many users pass a certain level? Hoy much time it takes for them to arrive a certain point? How many of them abandon a part of the game before finishing it?
We will later tell how we used custom events to answer our own questions, what decisions we made and the outcome of this all.