Some organizations rush into using Google Tag Manager without considering the risks and the amplitude of such risks. Sometimes they treat it as a supportive marketing platform, focusing on the “marketing” side and less of “the platform.” So, take a deep breath and read this article carefully. Pass it along to other members of your organization, particularly security and IT teams, before implementing Google Tag Manager.
#1 – Google Tag Manager is not an analytics tool
Because both products come from Google, and most Google Tag Manager uses today revolve around analytics and ad networks pixels implementations, the majority of new users think that it’s complementary to Google Analytics and such. Well, it’s not.
Google Tag Manager is a developing tool, and it has absolutely nothing to do with Google Analytics. Still, it does save a lot of implementation time for Google Analytics. Instead of someone sending an event or any other piece of information to Google Analytics by writing code on the website, they can do that via Google Tag Manager. But they could just as quickly send that information to other analytics systems. Google Tag Manager is a tag management system, not an analytics system.
#2 – Google Tag Manager is not for everyone
You can use Google Tag Manager for all kinds of things. Some use it just to insert pixels of various ad networks. Some use it to implement advanced Google Analytics tracking, or other systems altogether (not only analytics). Others run complex scripts that take the system to the max.
Wherever you are on that spectrum, you need a different level of knowledge for each type of use. Some things can be easily done by marketers, with the right training. On the other hand, there are some uses for Google Tag Manager that an analyst might come up with or plan, but only a developer can execute. Maybe the analyst has some developing knowhow, or the marketer could also be an analyst or the developer might also be a marketer. In a small company, the analyst or marketer can be the same guy. These are all different sectors with different needs, all using the same system.
Does everybody have to use it? Should everyone in the company with access to analytics, or any webmaster or a member of the site’s development team have access to Google Tag Manager? That’s a great question. The short answer is no. The long answer: someone needs to decide who gets permission.
#3 – It’s a code injection system
In case I wasn’t clear, systems like Google Tag Manager (and Google Tag Manager itself) are categorized as code injection platforms. The term code injection is usually negatively associated with programs or breaches that allow someone to plant malicious code on some website or app, just like a Trojan horse. No matter what you call it, at its core, Google Tag Manager is a tool for injecting external code. Usually, when IT teams hear the term “code injection” they tense up – mainly those in IT security.
For example, the system, as it is today, doesn’t distinguish between different types of tags. Everyone knows that a Google Ads conversion pixel – a ready-made tool – is a simple tag that requires little prior knowledge and can be fully accessible to marketers and campaign managers. On the other hand, the same system, at the same level of availability, allows users to push a complex code that no one knows what it does. This code can change the website’s design, affect its functioning, override and create new values and variables, generate cookies on the user’s computer, and pretty much anything they’d like.
Google Tag Manager has a hard time distinguishing between different levels of complexity or knowledge, and even when it does, this distinction may disrupt the proper running of the system (read more about blocking malicious code in GTM). Either way, the advantage of flexibility might become a disadvantage, and an untrained user might cause damage. I’ve seen it happen more than once.
Google Tag Manager is not a playground. It’s an integral part of the production environment, and as such, it can affect the functioning of the website. Think long and hard about who in your organization gets access to the system.
#4 – What’s written in GTM, stays in GTM
I’ll start with a straightforward example. I created a Google analytics event using Google Tag Manager for when a user clicks a particular button. Sadly, that button had no unique DOM ID or similar, so I got its CSS class name. Everything was working well, and everyone was happy (as much as events can make people happy.)
After a few weeks, the event count dropped down to zero. It turns out that one of the developers made some changes to the page code, and changed the class of the button. In other words, the core code has changed. The developer didn’t know that someone was relying on the class names. The developer couldn’t see on the website code that Google Tag Manager was reading information off that button. Unlike the previous item, where Google Tag Manager could break a site’s code, in this scenario, website implementations can ‘break’ Google Tag Manager implementation.
In a world without Google Tag Manager, we would have created the event by changing the site’s code. Hard-coded, plain and simple. If the developer wanted to change the button’s function, he would have immediately noticed through the code that some function or event occurs when clicking and would have made sure to preserve it. In other words, even if they didn’t know what precisely that command does, it was still visible in the code. When Google Tag Manager takes charge of the information sent from the website, activities are sometimes ‘transparent.’ Invisible to the naked eye. The more Google Tag Manager becomes a central tool in developing and monitoring the website, the more developers have to be involved or at least aware of what happens within Google Tag Manager.
#5 – Too many tags at once – Agile Google Tag Manager
You’ve made your changes, added tags, and variables. Don’t publish everything at once, and don’t wait until it’s all done to publish. Publish and update your container in small increments. Do you have ten variables? Debugging went well? Before you run off to create tags, release that version. Check to see that the variables get the right values and continue to work after they’ve been published. Now you can create tags, but again – don’t create five tags and then publish them; make one or two, debug, then publish. Nothing’s going to happen if you wait a few hours or even days before moving on (unless your client is really stressed). That way, you’ll have enough time for in-depth testing. There are different ways to publish one of several tags, but I think it’s pointless. Too many versions never harmed anyone, but doing rollbacks and trying to figure out which tag didn’t work out could take much precious time. Think Agile. Roll out small and lean versions.
#6 – Still not too great with advanced front-end technologies
#7 – Thinking that it’s simple
There’s something really tempting about the beautiful interface and premade tags, something that could make the average user think that working with Google Tag Manager is a walk in the park. Overly inviting interfaces could make it seem like it’s an easy-breezy system, but that’s hardly the case (go back to item #1 in this article). At my analytics courses and corporate training, I spend about an hour talking about Google Tag Manager before I even present it. The idea is to create a sort of aha moment, or at the very least, a profound understanding of the system’s capabilities (good and bad) and that people would go into it with all seriousness and caution. It’s no child’s play.
#8 – Lack of knowledge
Pretty self-explanatory. There are blogs (few), support groups, and forums. There are bugs, and there are glitches. Don’t pretend to know everything. Ask, research, study, read. Trial and error is a great way to learn, but make sure that these trials are educated and not just guesswork.
#9 – Your site’s code has to be well written.
You want to measure clicks on a specific button or capture a form. You go into the code, find the button, and now you want to teach Google Tag Manager to recognize it. But the developer didn’t put that much effort into characterizing or giving it a unique identity, and you have to use all kinds of workarounds. Maybe identify the button by its color (and class, if it has one), or perhaps if it leads to a particular page or performs a specific action. If only the developer had assigned it a simple ID, it would have taken a second. But instead, you’re looking for some magical combination of conditions to find a simple button.
And so, instead of being an analytics tool, Google Tag Manager becomes a developer’s band-aid. We try to figure out how to extract things that aren’t in the code, and that requires plenty of creativity – sometimes, way too much. Aside from the fact that it could just not work, it also looks terrible and increases the chance for future problems.
Sure, we can ask the developer to improve the code, but there will always be that someone who says, “Wait, didn’t you want Google Tag Manager so that we wouldn’t touch the code?”
#10 – You still need developers
There’s no way around it. You can’t do everything in Google Tag Manager without asking your developer for help. If you thought this was your ticket to independence, think again, and doubly so when it comes to technologically sophisticated websites or the kind that needs server-side information. It’s a mixed blessing. Once you ask the developer to support some of the things and implement others, you come to the next problem:
#11 – Hybrid Google Tag Manager implementation
Your site sends out data to various external tools (Google Analytics, for example). When some of that data is based on Google Tag Manager triggers that you created on your own, and some of them are hard-coded by a developer – you’re in a bit of a bind. If someone were to come in tomorrow morning and log into Google Tag Manager, they would have to know that some of the powers at work are the result of a Google Tag Manager/development collaboration. It’s not trivial, and could certainly pose a problem for future site maintenance.
#12 – Migrating To Google Tag Manager
Anyone who’s implemented Google Analytics using the classic method – hard-coding pages, events, e-commerce, and whatnot – and wants to make the shift over to Google Tag Manager would have to convert the entire code to work via it. Adding the analytics script via Google Tag Manager is hardly enough. As a result, all of your events and hard-coded implementation would simply stop working until you convert them all to Google Tag Manager.
#13 – 2FA
Hold on. A system that injects code but sits on the cloud? If you care about your website, then in addition to removing excess permissions, I recommend that you convert your Google login method to two-step verification – a password plus a text message. There’s no such thing as too much security. You could do that through your Google account settings, or the Google Tag Manager account settings.
#14 – Disorder and disorganization
I was handed what I can only describe as the most convoluted Google Tag Manager account ever created. Over 400 tags, about 200 triggers, and god knows how many variables. Two dozen different people managed the container in the past year, and over 15 company employees have editing and publishing permissions – including at least three external consultants whom I know personally. They can all do as they please. There’s no order and no method, and anyone can tag things under whatever name they choose.
The problem started six months ago when various data stopped being received by different systems. Management realized that changes had been made to the code that prevents Google Tag Manager from running smoothly and that some of the tags are no longer relevant and required updating. The search for the working tags proved to be a nightmare. When a tag that’s supposed to send one system’s conversion code is called Pi_Con_LR10, there’s no chance anyone will find it or figure out that Pi_Con is short for some kind of a conversion pixel. What happens when there are more than 80 of them?
We set out to reorganize and revalidate the account from the ground up. As a first – preventative – step, we took down all user permissions and made nearly all requests go through us. We’re also writing a categorized Google Tag Manager document that anyone can access, explaining what each tag does, what’s the logic behind it, and what parts of the site it should be running on. We also reassigned names according to a set convention. To put things in perspective: we were a month in and still haven’t begun the real optimization work. It’s a whole mess.
Got anything to add? Want to warn us about something? I’m waiting for your comments!