The majority of modern analytical systems work on the basis of events. An event is any user action in an app fixed by an analytical system. Analysts usually choose the following events:

  • user registration or the first visit
  • app entry
  • payment (virtual or real)

The three events are enough to calculate user retention metrics, activity and monetization, i.e. to answer 80% of analytics questions. But is it enough?

Vasiliy Sabirov answers the burning question in his article.

The majority of projects say “no” and they are right. For a more detailed user discovery information on the following events is needed: button clicks, a tutorial completion, a game fight and so on. Such events are called custom ones and are set up separately for each app.

Custom events setup is an essential task as correctly set up events simplify work with a product and demonstrate problems that a user experiences. An event system helps to find narrow places and growth points in an app, so we’ve decided to share some tips on how to set up data collection for analytics.

 

Tip 1. Don’t put off event setup

It’s a widespread situation: we release an app to a store and watch the result and then we can add event tracking. Don’t do it! Iteration of event adding to an app is a slow process, taking into consideration store updates, so it should better be launched on a development stage. Otherwise, if indices after a launch don’t impress, you won’t be able to make the right conclusions and make timely changes to your app. You know key points that a user is to go through beforehand during development, then why do you put off adding events?

 

Tip 2. Use event parameters

Along with event information you can pass many parameters of this event to an analytical system: time for a level walkthrough, a fight result, the number of attempts, amount of virtual currency spent and so on. Then you can use these parameters in any reports including funnels.

A parameter setup allows to decrease the number of events transferred. For example, instead of Battle_Win and Battle_Lost events, you can pass Battle_Finish event and Result (0/1) parameter as a result. Such an approach will make a further analysis much simpler.

 

Tip 3. Use global parameters

In an event you can pass both event and user parameters. For example:

  • Registration date. You can carry out a cohort analysis later on: compare behavior of users registered in different time periods.
  • Level. It helps to balance level complexity, amount of currency sold, etc.
  • Traffic source. You can create funnels on users from various sources. For example, compare an activation funnel for those from Facebook and Google.
  • Paying/non-paying marker. You can divide behavior analysis of paying and non-paying users and it will answer the question why some do pay and others don’t. Maybe, there’s too much currency? Maybe, there’s some technical mistake on a payment stage?

Global parameters are called so because analysts recommend to use one and the same set in all tracked events.

 

Tip 4. Draw funnels beforehand

At least on paper. If you know beforehand what reports you want to create, it will be easier for you to define key events. You will be able to bring near mentally the most important apps and imagine what precedes these points.

 

Tips 5. Analyse your first session as detailed as possible

The first session is very important as it’s where a user get answers to the following questions: what is this app like? how it differs from others? do I need it? why do I need it? how much does it cost?

A basis for user retention and monetization is created during the first session. Each smallest step here is a point where a user decides whether he/she stays in the project. We recommend to track the first session in a very detailed way in order to remove all narrow places from it.

 

 

Tip 6. Only confirmed payments

It’s a common mistake: a user clicks “Buy” and an app sends a system information about a purchase. But a person can cancel a payment later on. As a result, server data and system data differ and it’s even worse than data absence.

 

Tip 7. Duplicate information to 2 systems

On of them can be paid and the other – free. You just place 2 code lines (instead of 1) in key points. You’ll be able to check analytics correctness this way.

 

Tip 8. Test, test and test once again

As we have already said, adding events to an app will take some time and should be done thoroughly. If you forget to pass one parameter, you’ll have to wait one month, before it will be added. One more month for users to update their apps.

You’d better do it beforehand. Make your own session and check whether all events are passed correctly, or there are some evident mistakes, or you have forgotten some parameters.

 

Tip 9. Approach an event system structurally

It happens frequently that almost every managing element on each form is full of events. As a result, there are hundreds of event denominations in analytics but only 5-10 will get to a report. Moreover, the majority of analytics systems build their pricing on the basis of data points. Each line passed to an analytics system is a data point. An event is a data point. Such a thoughtless approach may cost you a lot in the end.

The other extreme is to set events only for several key points in a project and to find out in the end that such data isn’t enough to answer important questions on user behavior. Just like anywhere else, you need to find balance and track really important events.

An event setup is an important task for product management as custom event tracking allows to find problem places and growth zones.