Posts

One of the things I’ve recommended from the get-go is to always send the Client ID to Google Analytics with your users’ hits. This is very useful for adding a level of granularity to your tracking. At first, I recommended using an Event tag to do this. Then I modified my approach a little so that you could send it with your initial Page View (thus not inflating your hit counts).

However, Universal Analytics recently released a new task API, customTask, which lets you access the model object mid-tag, thus letting you modify the payload that is dispatched to Google Analytics. In this article, I’ll show you how this works by using the classic example of sending the Client ID to Google Analytics.

Let’s face it - most of us use Google Tag Manager for one main purpose: to deploy and configure Google Analytics tracking on a website. I’d wager that once you start using GTM, you won’t be implementing Universal Analytics the old-fashioned way, with on-page code, any more. But running Universal Analytics tags through GTM isn’t yet a perfect workflow. We’re still missing things like proper plugin support and the option to properly differentiate between the tracker and the hit - both of which are easy to do with an on-page implementation.

This is, by no means, a novel topic in this blog. I’ve covered Google Tag Manager’s event tracking and triggers numerous times before (see below).

• Auto-Event Tracking In GTM 2.0

• #GTMtips: Track Outbound Links In GTM V2

• #GTMtips: Fix Problems With GTM Listeners

• Trigger Guide For Google Tag Manager

However, based on the number of queries we still see in the Google Tag Manager Product Forums about event tracking, I believe one particular aspect of GTM’s triggers invites revisiting. I’m talking about the way that Just Links, Form, and Timer triggers can be both Enabled and Fired. This can easily lead to some confusion.

Apart from the unlimited number of workspaces, the 360 Suite version of Google Tag Manager didn’t have any differentiation from the free version feature-wise, until today.

GTM just introduced an approval workflow, which allows you to exercise some additional control over what changes are pushed to the live site, or created into versions.

Note that this update also introduced a small change in the regular GTM UI - mainly, the menu that used to have “Create Version”, “Publish” and “Preview” is now changed into a dual button layout with just Preview and Submit as the options.

Autocomplete search is a tricky thing to track. The underlying logic is that when the user starts feeding characters into a search form, the search suggests results based on a limited input. If the user is not satisfied with the results, they can continue adding characters to the search, thus increasing the accuracy. Often there’s also the option to revert to a regular search with what they’ve already written. Tracking this logic in tools like Google Analytics is difficult, because there’s really no way to know if the search was successful.

In this #GTMTips article, we’ll take a look at user permissions and access control levels that Google Tag Manager lets you set today. Doing access control right from a user interface AND user experience perspective is really difficult, and GTM is no exception. Nevertheless, there are several levels of user control that you can modify from account and container settings, and it’s useful to familiarize with these so that managing a big, sprawling account hierarchy would be just a bit easier.

With the release of the latest Google Tag Manager API version, it’s time to release the new version of GTM Tools. Most of the changes have been done under the hood, with the entire codebase refactored for improved stability.

I released the first toolset in October 2014, and quickly released an updated UI a few months later. Aside from a few bug fixes and stability improvements, the tools have remained largely unchanged since then. Now with the new API version, it was time to update the tools again.

Google Tag Manager has a very nifty programmatic API that lets you do almost anything that’s also possible within the GTM UI. I’ve used the API a lot, most notably for my GTM Tools, which might be getting a new release soon, too!

The API was recently updated to its second release version (V2), and in this article I want to go over the additions, removals, and changes that the new version introduced.

To be fair, this tip isn’t just for Google Tag Manager but for regular old on-page Google Analytics as well. It’s one of those little things that’s corroding your data quality without you ever realizing it. Namely, this tip is about how to handle cross-domain tracking in situations where you are sending data to multiple Google Analytics properties on the same page.

It’s a very typical scenario - you have a “local” property, which tracks only the traffic of the current site, and then a “rollup” property, where you send data from all your organization’s websites. The rollup property would need cross-domain tracking enabled, since you want to track users across your organization’s many website domains.

I’ve always been proud to avoid the typical headline clickbait of “Ultimate guide to pigeon care”, “All you need to know about the Great Vowel Shift”, “Did you know that you’ve been smoking peyote wrong your whole life?”. I’m ready to make an exception now by adding a BIG WHOPPING NUMBER to the title. You see, the amount of knowledge one can accumulate about anything they do on a daily basis is mind-blowing. It helps if you write a blog about the topic, since creative output is a great way to organize your thoughts. It also helps to be active in community support, since problem-solving is an excellent way to accumulate new skills and to hone the edge of your existing talent.