If you’ve used Google Tag Manager on the web, then you probably have an idea of how it manages your Analytics data on a mobile app. Forget that idea… it’s completely wrong. This post will explain how GTM works with Firebase Analytics and why you should consider using it.
The Elephant in the Room
First of all, if you do a web search for the title of this post you will find a million different ways to say this: GTM allows you to make changes without having to rebuild and resubmit application binaries to app marketplaces. This means you can modify your marketing tags after the app has shipped, and it’s the main reason mobile app developers use GTM. That’s great… but this guide is about Google Analytics for Firebase and the rest of this post will describe the interaction between GTM and GA4.
Different Value Proposition on Mobile
The reason tag managers are popular on the web is because they’re easier to install and maintain than raw Analytics and Marketing tags. Instead of adding Analytics tags to track every single attribute and action a user can take, the web developers just put one line of code on the top of every page, and build a data layer to provide the events/attributes that the tag manager needs.
GTM on a mobile app has a different value proposition, which Analysts often find confusing. The developers start by adding Analytics tags to track every single attribute and action a user can take. Then, GTM intercepts these and uses them to build a library of triggers and variables. So Firebase Analytics becomes your data layer for Google Tag Manager.
It’s lunch time right now, so I’m illustrating the two different systems as tacos:
The Meat. In both web and app, the most fundamental ingredient is your events, attributes and user properties. This is the meat, and it must be built by the development team always. Your web developers do this by building a data layer, and your mobile app developers do this by installing Firebase Analytics.
The Cheese. Google Tag Manager is the cheese that sits on top of the meat. GTM receives events and attributes from either your data layer (web) or Firebase Analytics (mobile app), and uses them to create the variables and triggers that you later manipulate in the web interface.
Can you have a taco without cheese? Debatable. Should you? No.
The Toppings. In both web and mobile, you have the ability to send data to other marketing tags using GTM. But here’s where Firebase Analytics (and GA4) differs from Google Analytics: on the web GTM creates Analytics tags, but on a mobile device GTM only modifies or blocks Analytics tags.
As a result, the mobile app taco has meat on both the bottom and the top, but you can make the meat on top taste different (this is where the analogy breaks down).
The Painful Limitation
Now, here comes the kick in the pants. Currently, GTM cannot be used to modify automatically collected events, suggested events, or user properties in a mobile app (source).
As a result, the only real use case that I’ve seen clients use is to ensure your custom event and parameter names are identical across data streams. For example, if your iOS developers named the event “promo_impression” and your Android developers named it “promoImpression,” you can use GTM to clean this up.
So is GTM Even Worth the Trouble?
So let’s be clear: GTM does not reduce the amount of work your development team has to do to install Analytics in a mobile app the way it does on the web. Also, it does not allow you to add new tracking after the initial implementation is over without the help of your development team. Instead, it has two benefits:
- It does prevent your development team from needing to install other marketing tags just like it does on the web.
- It makes your Analytics implementation less rigid (at least for custom events), because it allows you to make certain modifications without involving your dev team after the initial deployment.
If you don’t think #2 above is important, it’s probably because you don’t remember the time before tag managers were available for the web. Before about 2012, after you finished your initial Analytics implementation on the web your dev team moved on to other priorities and you were left with no ability to modify the work that they did.
This was extremely painful, because typos usually slipped in that you didn’t catch in QA, and things began to break as the website continued to evolve over time. Today, installing Firebase Analytics without GTM can create the same problem.
Finally, developers won’t tell you this, but the level of effort to add GTM on top of your Firebase Analytics tracking is very small, so my recommendation is always to include it. The benefits outweigh the costs, even if you don’t end up using it much.
.png)
