When the Google Analytics Settings variable was introduced in May 2017, it resulted in a significant change in the Google Analytics tag user interface in Google Tag Manager. The default UI for editing a tag was stripped down of all GA-specific settings, and the new Google Analytics Settings drop-down was the replacement.
Unfortunately, the bulk of Google Tag Manager articles online (including those on this blog) still refer to the old interface in screenshots and instructions.
Google Tag Manager should be relatively easy to implement. Just paste the container snippet to the <head> of the page and you’re good to go! However, at some point you’ll want to configure the dataLayer structure, too (read more about dataLayer here). There are two ways to do it: the right way and the wrong way.
In this article, we’ll see what happens if you do it the wrong way, how to identify the issue, and how to fix it.
I’m back with another customTask tip, but this time I’m exploring some new territory. Snowplow just introduced their latest version update, which included (among other things) an adapter for processing Google Analytics payloads. Never heard of Snowplow? It’s a collection of open-source libraries designed to let you build your own analytics pipeline, all the way from data collection, through ETL (extract, transform, load), using custom enrichments and JSON schemas, and finally into your own data warehouse, where you can then analyze the data using whatever tools you find preferable.
First of all, check out this article for an overview of how custom event listeners work in Google Tag Manager. The reason I’m writing this #GTMTips article is that I want to upgrade the solution slightly, and I want to bring it back into the spotlight. Why? Because it’s still one of the most effective ways to customize your Google Tag Manager implementation.
A custom event listener is a handler you write with JavaScript.
A while ago I posted a #GTMTips post where I detailed the steps you can take to opt-out of all Google Analytics tracking and the DoubleClick redirects that often follow. It was a fun exercise, but because it relies on preventing requests on a tag-by-tag basis (using the ubiquituous customTask), it can be a chore to handle in large containers.
In this article, we’ll continue with the theme of opting out from Google Analytics tracking by leveraging a solution provided by the tool itself.
Update 5 March 2019 due to GTM not supporting negative lookbehinds any more.
Google Tag Manager makes it fairly easy to do cross-domain tracking. Basically, you list the hostnames you want to automatically decorate with linker parameters in the Auto-Link Domains field of your Page View tag, and that takes care of decorating the URLs with the necessary parameter. It’s dead easy, even if there are a bunch of traps you need to watch out for (see my post on troubleshooting cross-domain tracking issues).
One of the challenges in working with Google Tag Manager (or any JavaScript-based platform for that matter) is what to do with race conditions. A race condition emerges when you have two resources competing for execution in the browser, and there is a degree of unpredictability to which “wins” the race.
A prime example is working with jQuery. It’s one of the most popular JavaScript libraries out there, and websites utilize it for a multitude of things, many useful for Google Tag Manager, too.