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.
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.
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:
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.
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.
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.
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.
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.
Update. Recently I did a tech talk about app tracking with some more implementation details. Slides were published at Speakerdeck, find them below.
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.