One of the most versatile triggers in Google Tag Manager is the Custom Event trigger. As its name indicates, you can use it to fire your tags when an event is pushed into dataLayer. This process is at the heart of GTM’s dataLayer system. And it’s not just custom events. Every single trigger type in Google Tag Manager uses the event key in a dataLayer.push(), which is why you’ll see events like gtm.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
With the proliferation of gtag.js implementations, we can see that there’s a small-ish paradigm shift in how to implement Google’s stack of marketing tools. As adding gtag.js snippets to the site code becomes more and more common (to cater to things like early Optimize loading), you might be at a point where you have lots of interesting information stored in the gtag.js queue but no way to access it in your Google Tag Manager tags and variables.
I’ve covered the more pervasive issue with tags not firing in Google Tag Manager in my article on the “Still Running” status. However, there’s an additional problem you might face with Google Analytics: tags that show status Failed, and which refuse to send any data to Google Analytics. There are a couple of possible reasons for this, and we’ll explore them in this article. Note that any tag type in Google Tag Manager can signal Failed.
With so many people working from home or remotely in these turbulent times, it’s time to revisit one of my oldest articles, and discuss the options you have for excluding or segmenting internal traffic in Google Analytics. The traditional method of IP address exclusion is not necessarily the best option anymore, unless all your employees use a specific VPN to connect to the site. In this article, we’ll go through some of the tools you have at your disposal.
With the enforcement of SameSite settings in the latest versions of Google Chrome, it’s become a mad scramble to get cookies working across first-party and third-party contexts. I’ve covered this phenomenon before in my SameSite article, as well as in my guide for setting up cookieless tracking for iframes. Recently, Google Analytics updated its libraries (App+Web, gtag.js, and analytics.js) with a new setting: cookieFlags (analytics.js) or cookie_flags (App+Web and gtag.js).
With iOS and Android containers available for Google Tag Manager, it’s tempting to add GTM as an integration into an existing Firebase setup for your apps. It’s also a fine way to get acquainted with Firebase in the first place, as it has a plethora of features to make application development easier. Furthermore, with the advent of App + Web, there’s even more incentive to integrate your app with Firebase.
One of the hard-and-fast rules in Google Analytics is that once hits have been collected and processed into your data properties, those hits are untouchable. This means that if you mistakenly collect duplicate or incorrect transactions, PII traffic, or referral spam, for example, it’s extremely difficult, if not downright impossible, to purge or change this data in Google Analytics. Another staple of Google Analytics’ strict schema is that displacing hits in time is also very difficult.