Setting up event tracking for a mobile app
Monetizing and analyzing your app can be a challenge. But an even greater task is making sure your users enjoy your app and know its worth. To do this, you need to know how users navigate through your app and interact with its features.
This is where analytics and event-tracking platforms come into play.
Analytics help you answer important questions about your users such as what do they like about your app, where are they struggling, which features need improvement, which features are hindering the user experience, and many more.
The foundation of analytics is data collection. Every analytics platform comes with a software development kit (SDK) that you can integrate into your app to send events. Developers add code that calls special application programming interfaces (API) in the locations where an event must be fired (for example, when users launch the app for the first time or when they send a message). If event logging is set up poorly, you will be blinded when working on your product, or you will work with erroneous data, which in my opinion is even worse than not having any data.
Why do we even need to track events in mobile apps
Mobile app analytics are usually based on events. As users interact with the app and perform different actions, events are sent to and stored in the analytics server. Developers then study the collected data to find answers to their questions.
An event is any action that a user performs (clicking on a button, opening a specific screen, adding a comment, making an in-app purchase). When the user performs the action, the app sends an event to the analytics system’s servers. Together with these events, the system also collects a set of default event and user properties (such as the user ID, app version, device model, etc), as well as a number of additional custom properties that you set up yourself (e.g., number of days since the user started using the app, number of app launches, etc).
This approach is more exhaustive and complicated than setting up standard analytics systems such as Google Analytics, which are designed for websites. But it gives a much better understanding of what happens with the product and allows you to answer many more questions.
Common mistakes in setting up mobile app analytics
When developing a mobile app, product teams often don’t invest enough time and resources in properly designing event structure and integrating analytics. An incorrect or low-quality analytics setup will considerably complicate subsequent work with the product, and sometimes leave your product flying in total darkness without any navigation devices to lead it.
There are noticed the following common mistakes when setting up analytics:
Last-minute setup of events: Product teams postpone analytics setup until the very last moment. When it comes to releasing the app, analytics is just one of the many problems the team has to take care of. Consequently, analytics setup loses priority and importance, and the team doesn’t allocate enough time and resources to thoroughly think about what data should be collected and why.
- Logging too many events: Sometimes, the app logs too many events, regardless of whether the data is useful or applicable. This is not an optimal approach. The data you collect might be suitable to answer the future questions you will have—or it will require a lot of additional work to transform it so that it will be able to help you. Also, collecting too many events increases the chances of making mistakes at the integration stage. Additionally, it will be more challenging to support the integrity and reliability of your data in the future when you roll out new updates.
Logging too few events: At the other extreme, you might log only the most important events based on the team’s opinion. And then it turns out that the data you collected doesn’t answer your key questions.
Disregarding the features and limits of analytics systems: When setting up the analytics, product teams sometimes don’t take into account the restrictions imposed by the functionality of the used system, which again makes it impossible (or difficult) to get the needed answers once the product is launched. For instance, some analytics systems set limits on event properties or the number of steps in funnels. These characteristics can affect your event deployment plan.
The process for creating the events structure for a mobile app
Step 1: Define key questions you want to answer
First, you need to decide which questions you want to answer with the data you collect from your app, and which hypotheses you want to validate. Imagine the app is already out there, and it’s time to conduct an analysis. What do you want to know?
We recommend the following approach when formulating key questions: Write down the main user scenarios, and then imagine the user going through them. What are some of the interesting questions you would want to ask?
The final list usually consists of a general section that contains common questions applicable to most apps, and a set of questions that are specific to this particular app.
Step 2: Specify the events and properties you need to answer the questions from step 1
Now that you have an understanding of what exactly you want to know, you can proceed to designing the structure of the events and their properties. Don’t spend too much time on it at this point. Quickly create the first version of events structure and move to the next point.
Step 3: Make sure your analytics system conforms with your event structure
Functionality, capabilities and limitations vary across different analytics systems. You must take all these factors into account when you create the events structure for your app. You are probably well aware of the features of the analytics that you use. Nonetheless, let’s take a look at a few examples that make it clear why this is important.
Step 4: Revise the previous steps
After going through steps 1-3, take another close look at your list of questions and event structure. In most cases, you’ll realize that you’ve missed some important pieces. You’ll also find plenty of opportunities to optimize the event structure to simplify the subsequent work with data.
Step 5: Set up your analytics system
At this stage, you need to explain the idea behind every event and event property to the developer team. Tell them when and under what conditions each particular event is sent, why you need it, and what you want to understand/find out/check.
This is important because many mistakes happen during the integration step. There are different reasons for these mistakes, but one of one of the most common is developers misunderstanding the logic behind a specific event or event property, or having an interpretation that is different from yours.
The conscious setup of events in your mobile app will pay off in the future by saving a lot of your time.
Step 6: Test events before the release
To make sure your analytics setup functions properly, you can simply verify that the system collects the events and their properties.
But to be completely sure that everything is working correctly, I recommend using the following approach.
Open the tool that allows you to see the new events from users in real time (most analytics systems have such a feature). Download and install the app with integrated analytics, and start testing all the events. Check that all the events are logged at the right time, and that all event properties change in accordance with the logic you have come up with.
Some more useful tips for your in-app events:
Supporting your event structure
Google Sheets is a great tool for storing and maintaining event structures. Create a new tab for every version of the app and color the events added in each of them. In this case you will always be able to track changes in the event structure.
How to name events
In order to avoid confusion in the event names, it is handy to name them based on the “Object + action” convention.
For example, the start of a new game level can be called “Level started,” and a purchase in the store will look like “Premium purchased.”
This will make it easy for anyone to map actions to events. It will also help you categorize and browse through your events, because all actions with a specific object will be shown next to each other in the interface.
If you have your own ideas and insights on embedding mobile analytics, feel free to comment or DM us. Thank you!
