The key concepts of app tracking for developers
If you have a mobile application or are going to develop one, it is important to remember about one thing on the side — mobile analytics, and a process behind it — application tracking. Simply put, tracking means collecting, enriching, formatting and passing data about your app to your analytics tools. In this blog post I will describe the key principles of application tracking every mobile engineer should know about.
Why do you need tracking?
Some time ago, our team migrated one Android application to Material Design and introduced a FAB button following the Material Design Guidelines from Google. This button was now used for the primary action of the screen. Soon we noticed that the traffic in the app decreased dramatically. We started to check the mobile analytics reports, and discovered that more than 20% of active users have never clicked on the new FAB button. Probably they didn’t found that button because after rollback of changes app traffic increased again.
This type of insight wouldn’t be easy to discover without detailed app usage information provided by analytics tools. These tools can help you to understand user behaviour in the app, see the time spent on every screen, collect crashes and a lot of other data. To feed analytics tools with a data we are doing application tracking.
When the data should be tracked
From the developer perspective, a tracking system is just another SDK to integrate into your mobile app. You should call some API of this SDK in particular use-cases or user interactions with the app. Obviously you need to set up proper keys and other configurations to make it possible for analysts and yourself to understand the tracked data, displayed by the user interface of your analytics tool or accessed as a raw data.
Below you can find common use cases when the data should be tracked:
- Click on something. For example, button, list item etc.
- Screen view. Discover which screens of the app users are visiting, with possibility to analyse how often and see the navigation flow.
- Application install/uninstall/reinstall. Yes, this is also possible. Moreover, you can even track from which source the user entered the app store which could potentially lead to an install!
- Open app from push notifications and other sources like URLs, web-browser ads, and even Google search results.
- Application Performance. How fast in average you can load the certain screen, specific content or even a custom timing output.
- Sessions. How long the user stayed in your app, at what time/day of week etc. And how long does it takes until he comes back — if he ever comes back.
- System and Account information. To understand who your users actually are (age, gender, interest groups).
- Exceptions and Crashes. Some tools provide SDKs to additionally collect bread crumbs or even integrate crash data with the tracking output. This helps to analyse in detail, what the user did before the app crashed.
Which tools to use
This post is not intended to promote any of tools available in the market, so I’m not going to make a full-scale comparison. Let’s just enumerate some SDKs with brief comments.
- Google Analytics, also known as GA. Free to use for small and medium businesses. Can be used in both web & app environment and by that can combine web & app traffic in one tool. Could be extended by enterprise-level Google Analytics 360 platform.
- Firebase Analytics. A new tool by Google. Free for use. The key differences from GA are more tracking features available out of the box, mobile-only approach in event design, and integration with other Firebase tools Crash Reporting.
- Flurry Analytics. Free tracking system acquired by Yahoo. Mobile only, available for all platforms. One of the oldest platforms for mobile analytics, redesigned with new feature set in 2016.
- Adjust. Trial available. Mobile-only tracking and mobile marketing platform. Can act as a data proxy and pass the tracked data to each marketing partner server2server to avoid installing and maintaining further SDKs on the app side.
- Self-Made tools for tracking. In some business cases, it makes more sense to define your own endpoints and tracking parameters, but be careful to not re-invent the wheel.
- Other tools. You can easily search on the web for some more tools available on the market and also find the comparison of them.
Let me mention that it is quite common to integrate SDKs from several analytics tools on a common tracking platform, and there are tools provided by some vendors for this use case. See for example Google Tag Manager.
First of all, you should always make sure that tracking output doesn’t contain any sensitive information about the user. It also makes sense to check if your tracking SDK keeps IP addresses of users. I think this breaks the concept of anonymous tracking data and should be forbidden. For example, you can enable option to remove the last octet of IP address in GA settings, but by default it is disabled.
Another thing you should take into account is data usage agreement you sign when start to use the tracking SDK. For example, Google asks if you want to share your data with them in GA and Firebase Analytics.
And the final point about privacy is providing user an option to opt-out tracking in your app and an overview about the used tracking tools. This can be regulated by law in some countries and usually is a good developer practice.
Common design patterns and challenges
From the developer perspective, the first thing is to expect tracking feature request to come from the product team. This should be taken into account starting from early stages of the application design. I saw several applications designed and estimated without any analytics tools integration. Later on an unexpected time and efforts were required to add tracking feature for these apps.
Another thing to check is a proper performance configuration. For the most of tools mentioned above, you are able to set up batch size or time how often to send the analytics data. To reduce the network overhead, make sure you are not sending data immediately. Also, ensure that data is collected to the internal storage of the tracking tool in case if device is offline.
The next challenge is to make your architecture scalable enough to expect 2nd, 3rd and N+1 tracking tool to be integrated to your application. It means that good practice is NOT to call the tracking SDK code from your UI classes or MVP structure. A possible solution can be a dedicated bus to process tracking event types and dispatch them to the appropriate tracking SDK.
How to debug and test tracking output
This is the most annoying side of tracking for both Android and iOS developers. The first thing you can do is enable logging of tracking events in the corresponding library APIs. But does it cover all cases? Take into account that during QA you can’t access all debug logs, tracked data can sometimes be modified by the tool just before sending to the server, and printing logs slows down the app. The better approach is to monitor network traffic being sent from the app to the tracking endpoints. To do this you should use HTTP(s) proxying tools like Charles or mitmproxy. See my blog post about network traffic monitoring for more details.
Firebase Analytics team has recently announced DebugView mode which can be a game changer in debugging of analytics output. This tool is integrated to Firebase console and shows real-time tracking events coming from the selected device. Looking forward to see it available for developers.
How to analyse data provided by tracking
The first outpost of the tracking data processing is usually a web application provided by the analytics SDK you are using. Usually you can find here a set of dashboards and graphs with some data filtering functions available.
Some tools provide sharable webpages with analytics dashboards. Just select the data you want to share and get your URL. It can be useful to see real-time stats of crash reports and key measurements in your browser or dev team TV.
Obviously this is not enough for big projects with several tracking tools being used. Here is where data analysis algorithms come to the scene. Or, just a text sort/search in MS Excel :) But let’s leave this conversation for another blog post.
State of the art in analytics data processing is a real-time change of the application UI or behaviour (for example, some background colors) based on the analytics criteria. Such criteria could be age of the user, screen views or other data provided by a tracking system.
Above we discussed the key principles of application tracking every mobile engineer should know. We looked at the common use cases when to track data, some popular tracking/analytics tools, and a way to test the tracking output. Lastly, we discussed common developer challenges in this process. I hope this post will help you to design applications with a tracking concept in mind and increase the amount of happy users of your app.
Update. Recenly I did a tech talk about app tracking with some more implementation details. Slides were published at Speakerdeck, find them below.