Skip to main content

Five common mistakes that websites make with Google Tag Manager

Google Tag Manager (GTM) is one of Google's best products - second only to its ubiquitous and feature-rich Google Analytics product.  GTM, as its name implies, is a tag manager that's used to embed JavaScript, HTML, and/or CSS code into websites.  Such code can include, but is not limited to, analytics scripts like Google Analytics, tracking beacons from online advertisers, and proprietary content from websites themselves.  There's no denying that GTM is a powerful tool; one that represents a major shift forward from the bad old days of self-hosted, spaghetti-code.  But like most technology, if it's not used correctly, GTM could end up causing more problems for a website than it solves.  Problems having to do with slow performance, mostly; but also tag misfires, data corruption, and quota limitations.  In this article, we'll be discussing solutions to such problems by exploring the five (5) common mistakes that websites make when setting up GTM.

Mistake #1: Not implementing a dataLayer.

The first mistake is one of the most egregious, i.e. not implementing a dataLayer object.  A dataLayer object is the recommended mechanism for passing data into GTM.  It is a global JavaScript object that's typically populated with user, session, page, product, and/or event data from the backend.  The GTM script on the webpage then interpolates the dataLayer object and uses it to embed various other code into the website.  Surprisingly, some websites don't even use the dataLayer - either by choice or through ignorance of its usefulness.  Instead, they cobble together several schemes like using cookies and/or events to send data to GTM.  Such schemes are not only tedious to implement and maintain but can result in an increase in both the payload size and the number of network requests.

Mistake #2: Using events to send generic data.

High on the list of mistakes is using events to send user, session, and page specific information to GTM.  Such data belongs in the dataLayer, period.  What's more, since user and session information doesn't change very often throughout a visit; and, page-level information doesn't usually change with each unique event that occurs on a page, it simply doesn't make sense to transmit that data using events.  By misusing events in such a way, it also makes it difficult to share generic data across multiple tags, as is the case with the dataLayer object.  Lastly, the firing of multiple events can cause some vendor tags to misfire and/or bump into quota limits, as is the case with Google Analytics' 500 hits per session collection limit.

Mistake #3: Not leveraging built-in variables and triggers.

Did you know that GTM has a wide array of built-in variables and triggers that can be utilized by your tags?  Well, it does; they just have to be enabled first before you can use them.  GTM's variables span the gamut from click events to form interactions, video metadata to scrolling depths, element visibility to JavaScript errors to page URLs.  Similarly, its built-in triggers can make use of many of the aforementioned variables in order to fire tags.  Together, GTM's built-in variables and triggers can save websites time and resources by not having to reinvent or re-implement common functionality.

Mistake #4: Loading third-party tags with the pageview trigger.

This mistake is a biggie, so take heed.  Did you know that it's not at all uncommon for a website's performance matrices to take a hit after implementing GTM?  Why you ask.  Well, it's because most websites inadvertently use the pageview trigger to fire third-party tags like AdWords, Facebook, Twitter, Criteo, Outbrain, Pinterest, etc.  The pageview trigger tells GTM to fire a tag immediately when the browser starts parsing the page.  Doing so with third-party tags, in essence, prioritizes them over a website's own content.  This error, when coupled with the fact that most third-party tags are poorly written, buggy, and slow, causes a website's performance to become negatively affected.  The solution to this problem is to use the Window Loaded trigger instead.  The Window Loaded trigger tells GTM to fire a tag after the page has been fully loaded, including embedded resources such as images and scripts.  The trigger ensures that a webpage is fully functional for a user before any third-party tags are loaded.  As a result, website performance matrices -- especially those related to page load times and time-to-interactivity -- are greatly improved.

Mistake #5: Not monitoring and removing problematic tags.

Not all vendors are created equal!  Some vendors are great at writing good (fast) code, fixing bugs, and guaranteeing up-times -- even going so far as to offer SLAs.  Then there are others who're just in it for the money; they don't care about your website's performance or its users.  You should do your best to identify this latter group of vendors and stop using them.  You can start by monitoring the performance of your vendors' tags using a tool such as SpeedCurve, Soasta, or even WebPageTest.  Then, you should take action to systematically remove those tags that are negatively affecting your website's performance.  Remember, why monitor a problem if you don't fix it!  To make the case to your marketing department, remind them that one bad apple can spoil the bunch; that's the case when a slow or buggy vendor tag starts to affect other tags or even worst your users.

In conclusion, I highly recommend reading the GTM Developer Guide.  Yes, that's right!  A lot of the aforementioned problems can be avoided by simply reading the documentation and following the recommended guidelines.  After all, it's Google's product; they built it and know better than you or I how to use it; so listen to them.

Comments

Popular posts from this blog

A better UI/UX for Cookie consent banners

I'm sure you've seen them before; those pesky, inescapable  Cookie consent banners !  They typically appear at the top or bottom of websites -- often obscuring important content.  For example, if you were to visit  CNN ,  Zara , or  Unicef  today; or, any other news, e-commerce, or charitable website for that matter -- especially those with an international presence -- you'd likely see one; a UI / UX eyesore.  Such Cookie consent banners, ubiquitous and omnipresent, have become the defacto solution for complying with an important part of the European Union's (EU) ePrivacy Directive  (ePD). If you're unfamiliar with the ePD, it basically mandates that websites first obtain a user's consent before storing and/or retrieving any Personally Identifiable Information  (PII) about them in and/or from HTTP cookies.  ( HTTP Cookies are small pieces of data stored by websites in a user's web browser for easier retrieval later.)  The Cookie Law, as the ePD has becom

Happy Father's, Mother's, Sister's, Brother's, Son's, and Daughter's Day

Today is Father's Day in the US. And to celebrate it, my wife and kids got me 6 pairs of socks, 2 shirts, several packs of sour candies, a $25 Domino's Pizza gift card, and a mug emblazoned with the phrase "Good Man, Great Dad". I'll probably never use any of those things; they're all crappy IMHO. (Well, maybe I'll use the gift card and eat the candies; I love sour candies.) But this post isn't a Father's Day rant about the crappy gifts that men receive in comparison to women on Mother's Day; rather, it's about a conversation that I had with my son Kyle about why there isn't a Brother's or Sister's Day too. To quote him: "The world should really have a Brother's Day and a Sister's Day. If not, they should get rid of Mother's Day and Father's Day. I know it's traditional but It's really not fair."  Clearly, he felt left out! Not wanting to let a good opportunity to have an in depth conversation w

A case for WordPress; or, not your own CMS

I've worked at several major companies thus far in my career; and, at each of those companies, I've had to use an in-house Content Management System (CMS)  to create and modify digital content.  For a long time, I couldn't understand why those companies would choose to allocate time, resources, and ultimately money to create a customized CMS in spite of having functionally equivalent, open source solutions readily available in the marketplace.  What was their rationale for doing so, I often wondered?  Was their businesses so unique that an off-the-shelf CMS simply wouldn't cut it; were the security risks associated with an open source CMS too great of a burden to bear; or, was it because the software engineer(s) in charge at the time simply wanted to showcase their PHP, Java, Python, etc. programming skills by building yet another CMS from scratch.  Well, in the years since I first pondered that question, I've come to realize that the answer is often the latter rea