Mobile Analytics - Setting up data collection for mobile apps. The limitations and workarounds.

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;

1. Send data directly using Google Analytics Measurement Protocol
2. Use Google Analytics Software Development Kit (SDK)
3. Use Google Tag Manager (GTM) SDK
4. 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.

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)
• 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 + Firebase 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.
Warning messages:
- [Firebase/Analytics][I-ACS035001] Cannot create Value type with unsupported value. The Value has to be NSNumber or NSString. Value: ...
- [Firebase/Analytics][I-ACS016000] Event parameter value must be of type NSString or NSNumber. Type: __NSDictionaryI

To solve this, one approach could be to flatten complex data trees (i.e. converting application.version into application_version), 

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.
Again, roadmap here is unclear, so someday it may stop working or it may become officially supported.
I recommend ignoring the warning message for now.

Event Parameter Value Length

Up to 100 characters

Same as 

Tag Manager + Firebase SDK

Large than

Google Analytics limits

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. 
See FirebaseAnalytics.Event for the list of reserved event names.

The "firebase_", "google_" and "ga_" prefixes are reserved and should not be used. 
Event names are case-sensitive. Cannot use DOT in the event name.

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. 
The "firebase_", "google_" and "ga_" prefixes are reserved

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:

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.