Modern analytical systems mostly operate on the basis of events. An event is any user action in the application recorded by an analytical system. Most often these types of the events are selected by the analysts:
- user registration or his first visit;
- login to the application;
- payment (whether it is in virtual or real currency).
These three events are enough to calculate the user retention metrics, their activity and monetization – that is to answer 80% of questions to the analytics. But is that 80% enough for you?
Most of the projects answer “no”, and rightly so. For a detailed study of the users, the information about other events is needed: click on the button, the battle in the game, the passage of the tutorial, and so on. Such events are called custom events, and they are set separately for each application.
Setting custom events is a very important task because the events set in a right way make it easier to work with the product and demonstrate the challenges that the user is experiencing. Properly set event system helps you to find bottlenecks and points of growth in the application, so we decided to share a few tips on how to set data collection for analytics.
Tip 1. Do not delay setting events for later
It often turns out like this: first, we publish the app at the store, look how it goes, and then add event tracking. Do not do it this way! Iteration of adding events to the application – it is not a quick process, taking into account the update of the application in the store, and it is better to run it at the stage of development. Otherwise, if after the launch the indicators are so-so, you will not be able to make the right conclusions and make changes to the application on time.
During the development you already know in advance the key points the user will go through, – so why to delay setting of events for later then?
Tip 2. Use the parameters of the event
Along with information about the event, you may also pass to the analytical system many more parameters of this event: time of passing the level, the result of the fight, the number of attempts, the amount of virtual currency spent, etc. And then these parameters may be used in any reports, including funnels.
Parameter setting helps reduce the number of events sent. For example, instead of Battle_Win and Battle_Lost events, the event Battle_Finish can be sent and Result parameter (0/1) to send its result. This approach greatly simplifies further analysis.
Tip 3: Use the global parameters
In the event, you may pass not only parameters of the events, but also of the user. For example:
- Date of registration. Later you can make cohort analysis to compare the behaviour of the users registered at different times;
- Level. This will help to balance the complexity of the levels, the amount of currency issued, etc .;
- Traffic Source. You may create funnels for users from different sources. For example, compare the activation funnel for users coming from Facebook and Google;
- Tag paying/not paying. You will be able to split the analysis of the behaviour of paying and non-paying users, and it will answer the question why some pay and others do not. Maybe there is too much currency? Maybe there is a technical error at the stage of making a payment?
Global parameters are called global because analysts recommend using the same set of them in all monitored events.
Tip 4. Draw funnels in advance
At least on paper. If you know in advance what reports you want to create, it will be easier to identify the key events. You will be able to mentally bring forward the most important points of application and submit what preceded these points.
Tip 5. Analyze the first session in maximum detail
The first session is really important because this is when the user receives answers to the questions: what is this application? how does it differ from the others? why do I need this? how much does it cost?
In the first session, the foundations for retention and monetization of the users are set. Every smallest step of the first session – is the point where the user decides whether he will remain in the project. We recommend keeping track of the first session in maximum detail to eliminate all the bottlenecks in it.
Screenshot from devtodev system:
Tip 6. Only confirmed purchases
A very common mistake: when the user clicks on Buy, the application sends to the system the purchase information. But the user may then cancel his payment, he may not have enough money on his credit card, etc. As a result, the data from the server differs from the data from the system, and invalid data is even worse than no data.
Tip 7. Duplicate the information in two systems
One of them might be paid (basic), and the other one – free. It does not oblige you to anything, you just put in the key points of the application not a single line of code, but two lines of code, to check the accuracy of analytics.
Tip 8. Test, test and test again
As we have said, adding events to the application – it’s not fast, and it should go thoroughly. Forgetting to pass one parameter will cause waiting a month before it is added. And one more month, until all users update the app.
It is better to do everything in advance. Record at least your own session and see if all the events are passed correctly if you are not forgetting any parameters if there are any obvious errors.
Tip 9. Take the system events structurally
It often happens that events are literally on every control element on each form. As a result, there are hundreds of names of events in analytics, and only 5-10 of them will actually get into the reports. In addition, most analytical systems build their pricing of on the basis of data points. Each line, that is passed to the analytical system is a data point. An event is a data point. And such a thoughtless approach may cost you quite expensive.
The other extreme is to set events only for a few key points in the project, and then find out that this amount of data is not enough to answer important questions about the behaviour of users. As in any matter, you need to find the balance and keep track of the really important events.
Vasiliy Sabirov, Lead Analyst devtodev