Mobile Analytics - Setting up data collection for mobile apps. The limitations and workarounds.
Posted 23 months ago by Dmitry Klymenko
14 Minute(s) to read
What do you know about your mobile app users?
Unfortunately, there is not much analytical data available from app stores and if you are same as me (and do believe in data-driven decisions) it is time to implement Google Analytics into your mobile app(s) and start collecting that precise data!
If you are new to the mobile apps development, please read this article first: Mobile Application Development Presentation reference links and useful materials to get you started.
Setting aside a Measurement Plan (what data is being collected), let's talk about HOW you can collect the data, as gathering data is a bit more complicated for apps than it is for web. However, there is an answer: you can use the following mechanisms to setup tracking;
- Send data directly using Google Analytics Measurement Protocol
- Use Google Analytics Software Development Kit (SDK)
- Use Google Tag Manager (GTM) SDK
- Use Tag Manager + Firebase SDK
Personally, I recommend #4 - utilising the Tag Manager + Firebase SDK library, but let's look at the pros and cons of each approach so that you can make up your own mind.
Options two and three are about to be deprecated in the favor of Tag Manager + Firebase and might not be supported in the next couple of years.
It is important to note that SDKs, as listed above, were not created for developers to solve their data hunger. Google Analytics is a Marketing and Business Intelligence toy. While developers can collect crashes and exceptions in Google Analytics using SDKs, there are zillions of tools doing it better.
Google Analytics is a Marketing and Business Intelligence toy. It was not created to satisfy developers data-hunger
Google Analytics Measurement Protocol
Send data directly to Google Analytics. Full control and responsibility.
Truth to be told, there is no other way (except for Data Import) to deliver data to Google Analytics. All other methods use Measurement Protocol at some point, even the Google Analytics web libraries (such as analytics.js and gtag.js) do.
Using Measurement Protocol is very similar to the server-side tracking implementation and in some cases, you can even re-use your existing server-side tracking code in your apps. In short, GA Measurement Protocol is nothing more than a simple HTTPS request to Google's data collection end-point with a well-documented set of parameters.
I usually recommend this approach if there are no library available for the app platform (such as some of the TV boxes or Arduino/Raspberry Pie), or in other very specific use-cases. Whenever possible, please try to use one of the dedicated libraries.
Besides the obvious fact that you have to do everything yourself (well, that's not new for developers), there are situations when it becomes a bit more challenging. Firstly your Measurement Protocol wrapper code should guarantee delivery, thus implement a delivery queue and deal with hits delay. You have absolutely no guarantee that the device always has a stable Internet connection or your app is active. Internet connection speed may vary and an app can be deactivated for the time being.
Guess how long the app will be on the client's device once they figure out it is using their battery as a hunger beast: every network request would use around 50 mW of juice, which is a lot! To avoid this, you will be responsible for batching requests, scheduling and delivering. Making sure requests do not exceed limits, etc. It's all doable of course but it is effectively re-inventing a wheel all over again.
Additionally, adding a tracking for a new event or a new screen can take a significant amount of time and will require app re-publishing to the Stores.
For the brave ones: Google Analytics Measurement Protocol Reference.
Google Analytics SDK (legacy)
For quite some time this was a preferable choice (before we got Tag Manager SDK). Analytics SDK takes care of zillions of nuances and has multiple bug-fixes and workarounds for edge-cases. Due to this fact, it is currently utilised by millions of apps.
The only downside to this approach is that it is not a "build once, use multiple times". Each time business measurement requirements changes, developers need to change the code (and synchronise changes across various platforms, if they don't share this code). And update the app version in distribution platforms.
Links:
- Google Analytics SDK for iOS (v3)
- Google Analytics SDK for Android (v4)
- Google Analytics SDK for Xamarin platform
- Google Analytics SDK for Window Phone
- Google Analytics plugin for Unity. Yep - gamedev is covered too!
- I am not sure if any of the mobile apps are still using C++, but there was an official library for the language as well
There are lots of good (or not so much) third-party libraries in different languages including .NET platform, PHP, Python, JavaScript, C++, C, etc. so the library coverage is quite wide.
While Google Analytics SDK still works and is sometimes even supported, it was superseded by the next generation of libraries solving the main inconvenience of this approach: the need to re-build and re-publish your app if your data collection requirement changes.
Meet Google Tag Manager or simply GTM!
Tag Manager SDK (legacy)
Also known as Google Tag Manager SDK or GTM SDK. The library includes Google Analytics SDK and builds what essentially is an external configuration support for data collection. This is a widely used approach on WEB which brings a great flexibility into an app world as well. With this library, you can "code once, use as you wish later". Well, almost.
The Tag Manager SDK includes GA SDK and wraps it inside an engine executing Business Logic built by a non-technical marketing and/or analytics professional in the Google Tag Manager interface. Every once in a while SDK would download external configuration and apply tagging as per new definitions (which is both fully controllable in the code and automatic).
You would need to use the legacy GTM containers as this was superseded in Sep 2017 by Tag Manager + Firebase SDK (see below). If you do not use legacy containers the library nothing would work.
Links:
- GTM SDK for iOS (v3)
- GTM SDK for Android (v4). API Reference
- GTM SDK for Xamarin platform is a bit tricky, but start looking from this link
Tag Manager + Firebase SDK (recommended)
This is the latest option and my recommended approach. Please do not be confused with the Firebase platform or Firebase Analytics. The Firebase platform (which includes basic analytics) is a mobile development-centric platform, just a standalone analytics framework. It is important to understand the difference, as Firebase SDK gives access to a wide range of cloud-based tools, such as Cloud Functions, Cloud DB, Cloud Messaging, which are not related to analytics at all. The Tag Manager + Firebase SDK, on the other hand, is the analytics-centric solution representing the latest versions of app usage data collection.
A few years back, Google acquired Firebase and slowly moved functionality from the Tag Manager SDK into this new one. Less than a year ago it received support for Enhanced E-commerce and became my #1 recommendation when tracking analytics data for GA. This process is not complete yet and there are a few details you need to be aware of before starting to use this SDK. Deep inside the Tag Manager + Firebase SDK, the Tag Manager SDK (and therefore Google Analytics SDK) and Firebase SDK is installed and a message queue is established between them.
When creating a container in Google Tag Manager you must choose Firebase (iOS) or Firebase (Android) container. If you pick legacy - it would not work.
The new Tag Manager + Firebase Container offers more built-in tags (and the number is growing!) and provides a neat integration with the Firebase automatic events. The weakness of Legacy GTM is the lack of automatic triggering events. Everything requires a manual dataLayer push with a specific triggering event. With the latest Tag Manager + Firebase SDK we can trigger a tag when the app is opened for the first time, when a session starts, or when the user purchases an item automatically. One thing to keep in mind is that these are based off Firebase Analytics definitions. For example, when an in-app purchase is recognised by Firebase Analytics, a trigger event will be sent automatically.
The table below outlines some challenges which you might meet during the implementation.
|
|
Tag Manager + Fir ebase SDK |
Vanilla Firebase SDK |
Tag Manager SDK |
Implementation Notes for the Tag Manager + Firebase SDK |
|---|---|---|---|---|
|
Data Layer Support |
No |
Same as Tag Manager + Firebase SDK |
Yes |
Yes, they removed much loved Data Layer which means we have to supply all contextual (relevant to the event) information together with the event. Except for a user-scoped data which can be set once (and will be available even if app restarts) using setUserProperty() method |
|
Event Parameter Value Supported Types |
String, Number (Decimal), Boolean |
Same as Tag Manager + Firebase SDK |
String, Number (Decimal), Boolean, Collection |
Passing collections (NSDictionary, AnyHashable, Map) is actually working, however, a warning appears in the console and future behaviour (roadmap) is unclear. another - just pass nested collections. They (top-level and nested collections) will not be available for Firebase SDK, but will be available and be working as they are expected for the Tag Manager SDK which is actually delivering hits to Google Analytics. |
|
Event Parameter Value Length |
Up to 100 characters |
Same as Tag Manager + Firebase SDK |
Large than |
Passing string longer than 100 characters actually works, however, a warning appears in the console and future behaviour (roadmap) is unclear. Warning message: - [Firebase/Analytics][I-ACS013000] Event parameter value is too long. The maximum supported length is 100: I recommend ignoring the warning |
|
Event Names |
Should contain 1 to 40 alphanumeric characters or underscores. The name must start with an alphabetic character. The "firebase_", "google_" and "ga_" prefixes are reserved and should not be used. |
Same as Tag Manager + Firebase SDK |
Passed as is to Tag Manager SDK |
I recommend obeying these limitations |
|
Event Parameters Names |
Parameter names can be up to 40 characters long and must start with an alphabetic character and contain only alphanumeric characters and underscores. and should not be used for parameter names. |
Same as Tag Manager + Firebase SDK |
Passed as is to Tag Manager SDK |
I recommend obeying these limitations |
|
Number of Parameters per Event |
Up to 25 |
Same as Tag Manager + Firebase SDK |
Passed as is to Tag Manager SDK |
Passing more than 25 parameters with event actually works, however a warning appears in the console and future behaviour (roadmap) is unclear. Warning Message: - [Firebase/Analytics][I-ACS016001] Event cannot contain more than 25 parameters I recommend ignoring this warning for now |
As mentioned, the new Tag Manager + Firebase SDK offers automatic events;
- session_start - when session starts
- app_remove - app is removed (Android only)
- app_exception - when app crashes
- app_update - when app is first launched after version update
- first_open - when app is opened for the first time on the device
- in_app_purchase - when a user completes an in-app purchase that is processed by the App Store on iTunes or by Google Play
- os_update - when the device operating system is updated to a new version
- screen_view - when a screen transition occurs (this one is a bit tricky, please see documentation)
- You can find more here: https://support.google.com/firebase/answer/6317485?hl=en
The events above can be used and you can define your own events matching your current (and future!) Measurement Plan.
Links:
- How to guide
- Tag Manager + Firebase SDK for iOS
- Tag Manager + Firebase SDK for Android
- Tag Manager + Firebase SDK for Xamarin platform
- Implementing Firebase SDK for Unity Projects
When to choose what:
To further simplify the options, here is a table of what you need based on where you want to do your reporting:
| Where you want your reports | Tracking Library |
|---|---|
| Firebase Analytics | Firebase SDK |
| Google Analytics | GTM SDK (recommended) or GA SDK |
| Firebase Analytics and Google Analytics | Tag Manager + Firebase SDK |
HYBRID APPS
Some mobile apps are built differently and instead of taking a classic platform-specific approach (coding for each platform individually) they heavily utilise HTML+CSS and JavaScript, basically wrapping website pages in them. There are a number of pros and cons for this app's architecture although it is commonly used. Such apps look normal to end-used (you would not even be able to recognise them on your phone), however tracking such apps is a bit different.
SDK libraries (explained above) can only work inside a platform native code and have no visibility into what is happening inside HTML. On the other hand, we have a great analytics library for HTML (and Google Tag Manager) but they again work independently from the native tracking. While we can track both of the components, they are completely separate and will look like two different sessions in your Google Analytics reports.
The solution is to utilise the Client ID (or User ID - see slide #60 in my slide deck to understand the difference https://www.slideshare.net/DmitryKlymenko1/understanding-user-journey-using-google-analytics-360) to tell Google Analytics that hits arriving from the native part of an app and HTML part actually belong to the same session and same device / user. The implementation is pretty straightforward, you ask your native analytics library for a Client ID or just generate it and then pass it to the web library. Please comment on the blog if you require more guidance here.
Tips and Tricks
- Save GTM Container versions as a Hit or Session Scope Custom Dimension. This way you would not have to wonder why specific events introduced in the latest version of SDK are not being tracked
- Log as much as possible and dispatch hits every second while you are in Debug mode
- Try and use dryRun option when available
- Does not make a difference if you use autogenerated ClientID or generate your own one (GUID for example) and supply it to analytics library used. If you can't do that, just use UserID field
- Save your ClientID and UserID as a Session-scope Custom Dimensions. This will make debugging so much easier!
- Test your implementation. Error in apps data collection are hard to catch after the implementation and there is nothing worse than making a data-driven decision based on data which does not make sense. These errors are costly and definitely justify extra implementation time
- Be comfortable with not necessarily getting every single piece of data because of the dispatch process and the realities of mobile devices
- To ensure your app doesn’t exceed limits and quotas it is not recommended to measure things like how many times a player presses the jump button.
You can however set a Guinness World Record with Google Analytics. - Push to Data Layer as much as [reasonably] possibly, but only collect data which answer your current Analytics questions. Using Tag Manager you can modify how much data is being collected even in earlier versions of apps. Besides an expensive mobile traffic usage for your customers - the less data you sent - the less battery juice your app will take from your customers. Be good to them
In the next blog post I will cover the marketing component of analytics tracking. How to set up acquisition campaigns, why use deep-linking, AdWords tracking, so stay tuned!
Want to know more about the specifics of Google Analytics? Internetrix has been a Google Marketing Partner (previously Google Analytics Certified Partner) since 2007 and offer expert knowledge and servicing on Google Analytics products. Get in touch with us today if you any further questions regarding Google Analytics.