We live in a time when 3.5 billion people are using smartphones – that’s almost 50% percent of the world population. The enormous number has led to a staggering 204 billion app downloads since last year, and brought in more than 120 billion dollars revenue.

In such a competitive market, all players are trying to reach as many users as possible, engage them continuously, and retain them for as long as possible. The key to success is knowing what app users want and using this information to improve the apps.

In-app event data is the source of that information for you.

From the moment the user installs the app, their actions can be monitored and recorded as in-app event data, such as the record of registration, login, or in-app purchase.

By discovering users’ actions, it’s possible to make data-driven decisions that can help bring more users to the app or retain the existing ones and make them happier.

To make sure that we have a quality and consistent stream of data being collected from an app, we need to make sure to write an excellent event-tracking plan which will be the cornerstone of our data collection.

However, the first step in creating a solid event-tracking plan is determining where to send the in-app data.

According to the research from May 2020, out of all Android apps that use analytics SDKs, 95% have integrated Firebase, as opposed to 40% of iOS apps.

It’s a powerful analytics tool that measures everything from user engagement to app crashes. It’s also practical for quick tracking setup, as some events like screen views and session start are tracked by default as soon as the SDK is implemented in the app code.

Besides automatically collected events, Firebase offers great features such as Cloud messaging, In-App Messaging, and easy-to-use Crashlytics.

One of the most useful and regularly used features at Infinum is its integration with Google BigQuery. It’s a serverless, highly scalable, and cost-effective data warehouse designed to help to turn big data into information.

Also, having data in BigQuery gives the possibility to integrate it with almost any popular visualization tools like Tableau, Qlik, Sisense, or Google Data Studio.

In the words of HP’s former CEO Carly Fiorina, “The goal is to turn data into information, and information into insight.” Having access to raw data is a must because it isn’t possible to make a deeper analysis in every mobile analytics tool.

When it comes to building event-tracking plans, here are some of the most used analytics terms to be aware of:

Event – User’s each interaction within the mobile app.

Example: A song played, user invited

Event property – A parameter containing additional information about the event sent along with that event.

Example: If an event triggers when the user plays the song inside the app, song name and artist name can be sent as event properties

User property – A parameter that can give information about each user individually.

Example: User that opted in for analytics or user that opted out for analytics, users using the app for free or premium users

Screen – The name of each screen that exists in the mobile app.

When it comes to naming events and properties, one naming convention should be followed through the whole event-tracking plan. We prefer the object-action framework in combination with snake case convention, but there are lots of options out there.

There is also the camel case, Hungarian, or kebab case. You can also use your own naming convention, as long as you are consistent.

Being consistent and following conventions are two out of the three important Cs when it comes to building event-tracking plans.

The last but not least important is clarity because every defined event name should be clear to anyone who reads the event-tracking plan or analyses the data.

The event-tracking plan needs to be understood not only by the data analyst who is creating it and the developer who is implementing it, but also by the business stakeholders who want insights from collected data to make data-driven decisions.

Documenting each event and property is very important. This way, you know at each moment what data is being tracked. There should be a central document, excel table or a file on GitHub, containing all details of what is being tracked in one place.

To make the event-tracking plan easier to read for business stakeholders, we’ve come up with an idea of making the tracking plan more visual through user journeys and mobile app screens.

We create user data journeys in a tool called Overflow, which our design team sometimes uses for visualizing mobile app flows.

Whenever we make changes in mobile apps, we update our tracking plans and the visualizations of user journeys. This way, it’s easy to see which information we are collecting for each part of the app, as well as to see whether we are missing something or if perhaps the data we are collecting isn’t aligned on all platforms.

This can be crucial because, if something is different, the wrong data is being collected and the results of any analysis we undertake are incorrect.

Everyone wants to know how their app is performing, what are the most and least used features in the app, and why. But to have all answers and to start making data-driven decisions, everybody needs to understand the importance of defining and implementing analytics correctly.

No events set up means no data, and no data means no answers. Consequently, it means you are making decisions in the dark. Even worse, poorly defined tracking can lead to wrong insights, and ultimately, to wrong conclusions and decisions.

Finally, here are the most important takeaways: