This content originally appeared on DEV Community and was authored by RudderStack
GTM is a code injector. Browsers generally view code injectors negatively because they can easily become a weak link through which hackers can plant malicious code in a website or app. As a result, GTM is blocked by most ad blockers and browser privacy tools. It is estimated that 42.7% of internet users use ad blockers, meaning you could be missing anywhere from 8% to 25% of user traffic data if you're using GTM. If your entire mar-tech stack is delivered through GTM and it's blocked, you'll run into some serious challenges.
For years, Google Tag Manager (GTM) has made it easy for marketers and analysts to install and manage third-party analytics and marketing tools on their websites and apps. It provides a centralized platform allowing non-technical team members to add, edit, and disable tags without having to touch the source code. This means they don't have to bug you to add new tags or edit existing ones in the event of an update.
But, as you know, putting such power in the hands of non-technical teams has the potential to backfire. Whatever they inject into the app or website via GTM bypasses your usual development and QA processes, which could result in a mess the data team has to clean up.
So, while GTM is a useful tool, its shortcomings are quickly apparent to modern data-driven companies. Data engineers hate GTM and for good reason. Its susceptibility to ad blockers and proneness for misuse are just a start. Here, we'll detail four of the driving reasons GTM and data engineers don't get along, and we'll offer a better solution.
1. GTM is a code-injection tool prone to security vulnerabilities
Since GTM is a code injection tool, it's not only blocked by ad blockers. It also opens up your site to exploitation because its ability to insert code could open the door to hackers. If a hacker gains access to your GTM account, they can wreak havoc behind the scenes by adding a few lines of seemingly harmless code. Often, this code will go unnoticed because it doesn't affect the look or functionality of the website/app.
In some cases, your site or mobile app could be used to display unwanted advertising to generate revenue for the hacker, or they could redirect visitors to other sites filled with ads. In worst-case scenarios, your site/app could be exploited to steal PII. Both Joom team and Securi documented many instances of this among their clientele.
Security exploitation like this causes loopholes that will affect your ability to deliver quality data to the teams that need it, and fixing these issues is time-consuming and expensive.
2. It has limited support for the variety of tools data-driven businesses need
Google Tag Manager provides native support for ads and analytics networks. While it offers more support options for websites, it supports less than 12 tools for mobile apps. So, when it comes to integrations with tools across your stack, GTM simply falls short. To send events to tools for things like A/B testing, nurturing, customer engagement, and support, you'll have to come up with workarounds to integrate unsupported tools.
For example, if you're managing an event-driven tool like Mixpanel via GTM using custom code, you may want to use another event-driven tool like Intercom down the line. Using GTM means you have to write custom code yet again to send the same sets of data to Intercom. And whenever any tool updates its API, you'll have to go back in to update your code.
3. It slows site performance
If not properly managed, GTM can add a serious performance burden to your digital properties. This can happen if the tag manager container has accumulated tags over time, perhaps through experimentation with different publishers or asset integrations.
The implementation directions from a lot of third-party tracking pixels are just "make sure it fires on every page". So, less experienced GTM users often add more and more of those tags with the default "all pages - pageview" trigger which runs very early in the browser's rendering process, while it is still loading and parsing critical resources for the actual website ( such as HTML, CSS, JS, images, videos, etc.). What makes this worse is that, by default, tags are essentially treated as separate scripts. So, if there are 50 tags managed via GTM, the browser now tries to load a webpage and 50 different scripts simultaneously each time a user visits a new page.
While users on midrange machines with a fast internet connection may not experience severe performance drops, users on older/weaker machines or mobile devices with slower connections will. For every page load, these weaker devices will do as much as their CPU power permits and then queue up the rest, locking up the browser window and rendering the website inoperable until all of that processing is completed. This not only results in a terrible user experience, it also affects your Core Web Vitals scores (especially the First Input Delay), which will inadvertently affect site ranking on Google.
Maximilian Werner, founder of Obsessive Analytics Consulting, who has significant experience working with GTM, has seen this firsthand. "I had a client once where GTM caused the web pages to freeze for about 10 seconds on load because they had more than 120 tags firing on page load. Mobile devices basically crashed."
4. It's difficult to manage user state at scale
GTM uses a global JS window variable called a dataLayer to maintain something similar to an intermittent state. It can only keep track of variables on the current page. This means it cannot persist user state across pages on the same domain, let alone across domains.
For example, assume that the checkout process of an e-commerce website is spread out across four pages: cart, personal info, payment info, and confirmation. When a user enters their name and email on the personal info page, and you use dataLayer.push({name: 'john doe', email: "johndoe@domain.com" }) to store that info either manually or through code automatically run by the ecommerce site (if they offer integration with GTM), then you can use that info on that page.
However, when the user navigates to the next page, the dataLayer is wiped clean since it's just a window variable, and you will no longer have access to that info. To carry the data over to the next page, you must persist the data yourself by writing custom JS to store it in a cookie or localStorage, and then read it out on the next page. This adds many more points of failure and stops you from adequately accounting for users joining funnels at different stages.
There's a better alternative to Google Tag Manager
GTM simply can't meet the demands of the growing data-driven business - especially as data stacks become more complex. For a flexible and scalable solution that unlocks advanced use cases, you'll need a more robust tool like RudderStack for data integration.
With RudderStack, you don't have to worry about security exploitations because RudderStack does not inject code into your website. You also don't have to worry about ad blockers---RudderStack uses a proxied RudderStack and server-to-server integrations. And when it comes to support for tools, RudderStack offers integrations for more than 200. With integrations ranging from ad networks and corporate communications to attribution and marketing tools, RudderStack enables you to easily integrate the tools you already use, and it gives you flexibility as your stack grows to meet new business demands.
RudderStack also makes your life a lot easier when it comes to keeping user session data intact, especially across different visits because it persists user state and makes it accessible anytime via rudderanalytics.getUserProperties().
In a nutshell, RudderStack gives you the ability to give every team the customer data they need. Instrument once with RudderStack's SDKs, then automatically send data to your warehouse and business tools. No more dealing with API changes and broken pipelines. You can even use GTM through RudderStack. So, if you want to keep using Google Tag Manager to manage your ad pixels and other Google-related tools, you can integrate it with RudderStack.
Try a better data integration solution today
Test out our event stream, ELT and reverse-ETL pipelines. Use our HTTP source to send data in less than 5 minutes, or install one of our 12 SDKs in your website or app. Get started.
This content originally appeared on DEV Community and was authored by RudderStack
RudderStack | Sciencx (2021-11-15T12:53:36+00:00) 4 Reasons Why Data Engineers Hate Google Tag Manager. Retrieved from https://www.scien.cx/2021/11/15/4-reasons-why-data-engineers-hate-google-tag-manager/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.