To begin analyzing your project, you need to start sending information about user actions to the analytics platform. This information is sent in the form of events and is one of the key elements of analytics platforms to track metrics and build reports.
In this article, we are going to talk about creating an event structure that is necessary for the analysis of your project.
Types of Events
An event is any action that a user performs in a project. Many of the analytics platforms are designed in such a way that creating reports requires minimal effort from you and covers the maximum of your analytics needs. That is why most platforms provide their clients with a list of basic events that are easy to integrate. However, there may be situations where basic reports are not enough. Then the developers themselves can determine the important events to send and add shape the necessary parameters around them. In devtodev, such events can be sent as custom events.
Basic events are events already implemented in the platform, associated with pre-written standard event handlers. They also have predefined parameters that should be sent. Basic events typically include sessions and payments. However, in platforms like devtodev, the list of basic events is supplemented with events created specifically for games. This is, for example, a virtual currency event, a level-up event, a progression event, etc.
For example, devtodev already has an event for the tutorial. By integrating this event, you can see the ready-made report, and you don’t need to collect additional funnels for analysis.
Custom events are any actions that your client performs. Reports on custom events must be built manually.
Examples of custom events:
- Onboarding completion, sending of the tutorial steps;
- Interactions with the shop: opening a shop, browsing items;
- Ad interactions;
- Authorization method or registration steps;
- Adding an item to the wishlist;
- Opening certain app screens, etc.
Get familiar with the basic events offered by the platform of your choice. Perhaps some events that you wanted to implement are already taken into account by the analytics platform, which means that you can build reports on them in one click.
Events to Track
It would be a mistake to set an event for every application control element. As a result, there are hundreds of event names in the database, of which only a few actually get into the reports.
Most likely there will be events that you will never analyze (either they are useless or there are no resources for analysis).
The other extreme of event customization is to assign events to only a few key points in the project, and then find out that this amount of data is not enough to answer important questions about user behavior. You need to find a balance and keep track of really important events.
To do this, it is worth defining the goals and methods of analysis:
- What information is important for business: the number of in-app purchases, conversion, etc.?
- What are the next directions of development? If there is not much time left before the release, it's worth setting up events for key points in your product that align with your business goals.
- What decisions can be made based on the received data? Do not focus only on what information you will collect through events. Think about how you can make the best use of it.
How to Create an Event Map
To begin with, formulate key events based on your tasks and goals.
Let’s say, the task is to understand how promotions and bonuses affect user behavior. Therefore, the key event that we need to track will be promotion views.
Next, we should find out the surrounding events of the key events. What precedes them and what events will follow after? In our case, the preceding events are shop opening, browsing an offer, and clicking on items.
The next step is to add a subsequent event – the purchase of an item. Here you can add an unsuccessful purchase to understand what went wrong, and why the user failed to complete the purchase: whether it was a technical issue or they changed their mind while completing an order.
It is also worth adding parameters that define events. These details will help us analyze the reasons behind user behavior: country, traffic source, registration date, payment segment, etc.
To make it easier to use events, they are often named in the format of element_action. For example, the start of participation in an event is event_started or the opening of a store is store_open.
Sometimes you can add a screen, and get screen_element_action. Such a structure is not always suitable. For example, it won’t work if the event can be sent from several screens. In this case, it would make more sense to leave “screen” out and name the event after what it accounts for.
The most common tool for storing and maintaining the structure of events is an Excel file. It can contain the conditions for sending each event – parameters, values, and correlation with application versions.
Most often the file will contain:
- A version of the app the event is sent from;
- Screen: home screen, shop, etc.;
- Trigger, that is a condition for an event to be sent;
- Event name and its parameters;
- Some comments to make the information about the event complete.
After you have generated an event map, you should once again make sure that you will be able to answer all your questions and that you will have enough data to make a decision. You need to check if you have added all the parameters to the events.