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.
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.
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
ReplyDelete