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.
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).
One of the myths surrounding Google Analytics is that the first hit of a session should always be a pageview. It makes sense - sessions are initialized with a landing page, and thus need a page view to have one. However, in this article I want to show you empirically how this myth is just that - a myth. There is little discernible impact if the first hit of a session is an event, and GA is more than capable of stitching the first event together with the subsequent pageview into a session entity.