Native App - Container Loading

Google Analytics Mobile App Container Loading Recommendation

It’s crazy to think just how much smartphones have changed the way we live. Before the dawn of smartphone technology when driving to a new location we’d copy down directions so we’d know where to go. Now we can look up directions to places on the fly that even take into account traffic conditions. When we wanted to communicate with someone, we would call them instead of using one of many apps to message that person. People constantly have their phones with them and can be reached at any time by other people or companies through native apps. This highlights the importance of making sure our mobile apps have analytics optimally installed to take advantage of that opportunity. There is a timing issue, however, that needs to be considered in Google Tag Manager  (GTM iOS v3, GTM Android v4) to be able to track attribution and guarantee early hits are not lost. Note: This post is NOT for Firebase GTM (iOS v5, Android v5).

The issue has to do with the time between the application launching and when the GTM container becomes available. The container holds a configuration of tags, triggers, and variables that are setup in the GTM interface. This configuration determines what information can be sent to Google Analytics (GA). There are different types of containers and we’ll use the following definitions for the purpose of this blog post:

Default Container
The default container is a binary file that is downloaded from the GTM interface and directly added to the XCode/Android Studio project.

Published Container
The container that is published on the GTM interface and is pulled down from the GTM cloud to the app when the app attempts to refresh the container.

 

Now that we have those definitions in place let’s dig into the issue!

When the application launches, the app has yet to load the published container (or check if it needs to refresh said container). The published container becomes available to the app on the containerAvailable callback (iOS) or onContainerAvailable (Android). During the time before these callbacks, the default container, instead, is utilized. This is significant because it affects which container will handle the dataLayer pushes. There are two scenarios described below:

DataLayer push occurs before the container available callback:
Default container configuration handles dataLayer push.

DataLayer push occurs after the container available callback:
Published container configuration handles dataLayer push.

If the default container has nothing inside of it then any dataLayer push that occurs before the container available callback will never generate any Google Analytics hit. This behavior is significant if you want to track anything that occurs at app launch—such as attribution information via deep links or push notifications. Tracking this type of information is problematic unless this timing issue is taken into account. There are two approaches that we recommend to deal with this issue.

 

Update the Default Container:

The simplest solution is to update the default container within the project. There won’t be any difference between pre/post container available if the default container and the published container have the same configuration. However, this would require a new build anytime the GTM container is updated. This is problematic and somewhat defeats the purpose of a tag management system in the first place. A simpler recommendation would be to update the default container whenever a change is made to a tag that fires close to app launch. While these solutions are simpler, they come at the cost of some flexibility due to requiring a new build. A more elegant solution is the following.

 

Batching DataLayer Pushes:

If the issue revolves around dataLayer pushes that occur before the published container is available, why not wait until the published container is available? Any time a dataLayer push occurs before the published container is available, the contents of that push are stored in an array. Those batched dataLayer pushes are fired as soon as the published container is available. While this solution necessitates additional development resources, it is an overall more elegant solution that does away with the requirement that default container updates need to wait for new builds to be released.

So we’ve discussed the timing issue that needs to be addressed as well as two potential different solutions. These solutions will not only guarantee you’ll get the data you expect but also open up the door for attribution tracking. This information allows us to better understand which campaigns ultimately result in more conversions. Now that we have a solid GTM installation, we can discuss how to track general attribution for native apps in our next blog post!

Be sure to catch our newest post (part 2) about general attribution for native apps!

Leave a Comment