With the release of Google Analytics: App + Web, Firebase is suddenly all the rage. The new App + Web property can combine data from your website and mobile apps, as long as the latter uses Google Analytics for Firebase, formerly known as Firebase Analytics.
In this guide, I’ll walk you through the steps of creating an extremely simple Android application, and we’ll then create a Firebase project, and for good measure add Google Tag Manager to the mix.
Google recently released a new version of Google Analytics called App + Web. Clumsy name aside, this really is for all intents and purposes Google Analytics V2 or Firebase Analytics for the Web. We’re not talking about a charming way to do roll-up reporting between Google Analytics for Firebase and Universal Analytics, nor are we talking about an enhancement to Universal Analytics.
No, we’re talking about a new measurement model for web traffic, which has the convenience of being compatible with Google Analytics for Firebase, which you might already have running in your apps.
Google Tag Manager is strictly a tag delivery system, and it’s very careful not to collect any analytics data on its own. This is most likely a deliberate choice, because if GTM was to start collecting data, it would introduce additional barriers to adoption.
Nevertheless, being a tool that consolidates the design, development, deployment, and testing of all the marketing and analytics pixels, code snippets, and utilities running on a website or a mobile app, lacking the necessary features for auditing and monitoring has always seemed like an oversight.
One of the cool things about Enhanced Ecommerce deployments in Google Tag Manager is that you can use a Custom JavaScript variable to generate the necessary data.
There are many reasons to do so, with the biggest one being the flexibility it offers for manipulating the dataLayer object in case quick changes are required on the site, and it would take too long to wait for a new release of the site JavaScript.
Last updated 12 August 2020: Added details about server-side tagging.
As I have finally managed to pick up my jaw from the floor, it’s now time to tell you what’s got me so excited. Google Tag Manager recently released a new feature called Custom Templates. Actually, it’s not fair to call it a feature. It’s a full-blown paradigm shift in how we use Google Tag Manager. It’s a suite of features designed to help brands, companies, and users create and share their own custom JavaScript and HTML setups with ease, while taking care that the code is optimized for delivery in the web browser.
Some four years ago, Google Tag Manager released a new trigger predicate named matches CSS selector. Slowly but surely, it has evolved into one of the most useful little features in GTM.
Even though I’ve written about CSS selectors many times before, I wanted to compile all the relevant information into a single guide. For an external resource, I recommend bookmarking the w3schools.com CSS Selector Reference. But for your day-to-day use of CSS selectors in GTM, this guide will hopefully prove useful.
Trigger Group is the newest trigger type you can add to a tag in Google Tag Manager. It allows you to establish dependencies between multiple triggers, not firing the tag until every trigger in the group has fired at least once.
This establishes an interesting new paradigm in Google Tag Manager, because until now it wasn’t possible to create triggers that relied on earlier values of a given key (event in this case).