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.


  1. It is what I was searching for is really informative. It is a significant and useful article for us. Thankful to you for sharing an article like this.qr code text message


Post a Comment

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

The Crucial Role of Service Level Agreements (SLAs) and Service Level Objectives (SLOs) in Software Applications

In today's digital era, software applications are at the heart of business operations and customer experiences. From e-commerce platforms to enterprise solutions, the performance and reliability of software applications can make or break an organization's success. To ensure seamless operations and meet customer expectations, having robust Service Level Agreements (SLAs) and Service Level Objectives (SLOs) in place has become paramount. In this blog post, we will explore the importance of SLAs and SLOs and how they contribute to the success of software applications. Defining SLAs and SLOs A Service Level Agreement (SLA) is a contractual agreement between a service provider and a customer that defines the level of service expected. It outlines the metrics and targets the service provider commits to achieving, such as uptime, response times, and resolution times. SLAs establish a mutual understanding between the parties involved and provide a framework for measuring and managing s

Using HTML tables for website layout

I first became a front-end web developer in the year of our Lord, 1998.  Back then, the HTML specification had just reached version 4.0; Internet Explorer 7 was the dominant browser; and, the mantra of separation-of-concerns  was still being preached to web developers.  (Back then merely uttering the phrase CSS-in-JS  would've gotten you killed, professionally speaking.)  What's more, back then, HTML tables were still de rigueur; in fact, many websites used them for layout purposes ( DIV-itis hadn't caught on with the masses as yet; that would happen several years later.) Yes, it was the stone ages of the web -- in comparison to today.  Today, there's a wealth of newer technologies for developers to choose from when building websites, i.e. HTML5 , CSS4 , ES9 , etc.  Long gone is the mantra of separation-of-concerns and in its place sits CSS-in-JS, mockingly.  And, long gone are table-based layouts too; they gave way to the aforementioned DIV-itis phenomenon and t