Remain Calm! Addressing Google Tag Manager’s Security Risks

/

blog-remain-calm-gtm2

We hear it all the time – marketers love the idea of Google Tag Manager but aren’t sure that they can talk their development/IT team into it. The conversation can often veer into the dangerous territory of us vs them, complete with finger-pointing and authority-challenging.

We address these concerns often with new clients, explaining the benefits of Google Tag Manager while at the same time reassuring the dev teams that GTM will not break their sites.

The reality is that Google Tag Manager is an excellent technical tool that can make tagging and tracking websites extremely efficient when used properly. It becomes an even more powerful tool when used collaboratively by multiple teams or vendors with open communication.

Let’s break down the issues that have come up most frequently and outline some strategies to help manage your implementation.

Communication Is Your Most Important Tool

Among the many benefits of Google Tag Manager, one of the most attractive features is the ability to publish new Tags and changes instantaneously to your live site. This often flies in the face of the standards and protocols that have been so carefully put in place regarding development and testing schedules.

In reality, I see this as a communication issue rather than a technical issue. As you’ll see later on, there are plenty of ways to control who can do what with various settings and permissions. More valuable than any setting will be discussing these issues upfront and developing a plan agreed to by everyone.

I would suggest that Google Tag Manager should not be immune to standards and procedures, but I would argue that it should have its own dev cycle that is agile and flexible. Take advantage of the settings and the built-in tools to check that everything is working, then Publish to your site, sometimes within minutes.

Develop Your Plan

Work with your teams and vendors to address the questions below. It’s important to think of this plan as a fluid procedure, and to build in redundancies. You may switch Paid Search vendors or Analytics partners *gasp*, but that should never mean starting over or losing the work you’ve accomplished together.

Things to decide:

  • Who should be able to create new Tags?
  • What types of Tags can they create?
  • What types of internal reviews are necessary?
  • Who can hit the Publish button?

Things to consider:

  • How will different internal teams need to use GTM?
  • Which vendors should have access, and what type of access?
  • What type of training (internal or external) should all GTM users have?

Separate Site Operation from Site Tracking

I always like to joke that when you start this process, you should immediately buy your IT staff a case of beer. In all seriousness, there is usually a significant amount of dev work for an enterprise GTM installation, so it helps to have everyone on the same team.

The dev team has one of the most important roles, keeping everything running smoothly. Website performance is always top priority and often we’re reminded of this when we ask to add new tracking to a page and get an estimated completion date that is weeks or months away.

With Google Tag Manager, I like to separate some of these tasks into “things I can do” and “things I shouldn’t be doing.” I can take responsibility for marketing and analytics tagging, and I’ll call in the big guns when I need help with the complicated tasks. But first, I need buy-in from the dev team.

Google Tag Manager Won’t Break Your Site

At the most basic level, GTM is a fancy code injector. It takes the Tags, Triggers, and Variables that are configured in the GTM interface and sends it all as JavaScript onto your site. This probably sounds frightening to an IT professional, so let’s expand on this a little.

Google Tag Manager, like any other plugin or extension, should be tested when you add it to your site. The tool itself won’t break your site, it’s how you use the tool that needs to be governed.

Google is so confident in Google Tag Manager’s reliability that they have included it under the Service Level Agreement for Google Analytics Premium customers, which should bring you a least a modicum of relief.

I’ve even heard people ask about what happens if Google Tag Manager fails completely or goes down. If you think about it, when’s the last time your website “went down” or had loading issues? Now think about the last time Google “went down.” If any company is prepared to handle a task like this, it is Google with their distributed networks around the world.

Hackers Won’t Take Over Your Site Through GTM

how-works-img-1Again, let’s go back to the previous comment. This is Google. Whose security do you trust more, Google’s or your own site?

Google Tag Manager has the same risks that you’ll have with any system where people need to log in. In this case, GTM requires a Google Account to log into GTM, which can be a Gmail address or any email address that you associate with Google. I’d recommend you stick with company email addresses rather than personal email addresses, so you can easily tell who has access and you can remove access later.

GTM actually goes a step further and allows you to turn on two-factor authentication for certain types of Tags, namely the Custom HTML Tag and Custom JavaScript Variable that I’ll discuss in a bit. Two-factor authentication is a setting with any Google account that requires a password and a numeric code that you get from a text message, voice call, or mobile app. If you’re using your Google Account for business purposes, this setting may already be turned on or should be considered.

With this setting enabled, only users who have signed in using the two-factor authentication will be able to edit or create custom Tags/Variables. If they do not have this extra level of security on their login, they’ll see an error message when trying to save.

permission-denied

You Control The Access

This next part requires a bit of GTM structural knowledge, but the main takeaway is that you have options. Within GTM, there are Accounts and there are Containers. Accounts are generally your company name, or your parent company name. Containers are the parts that go on your individual websites and are generally one container per site. Even if you have dev or stage environments, I would handle all of that with one container per site.

You grant permissions to people at both the Account level and at the Container level.

Account Permissions

  • View only
  • View, Edit, and Manage

This is where the IT team can stake their claim and “own” the account. It makes sense that the team that owns the website also controls who can add Tags to the website. The owner(s) of the account should have the Manage permission so they can edit Account and Container settings, but more importantly, so they can give out Container permissions to the other users in the company.

Container Permissions (more info)

  • No access: The user will not see the container listed in the account.
  • View only: The user will see the container listed and may browse the tags, rules, and macros in the container.
  • View and Edit: The user may add and edit tags, rules, and macros in the container.
  • View, Edit, Delete and Publish: The user may add, edit, and delete tags, rules, and macros in the container as well as publish changes to the live site

This is where you can fine-tune permissions for the different teams and vendors. Again, the Publish permission should be reserved for the few people/vendors who have proven their knowledge of the tool and have earned your trust to add Tags to your site.

Template Tags Reduce Risk, Custom Tags Should Be Monitored

ga-tag-templateInside of GTM, there are three different types of Tags – Google’s pre-built templates, third-party templates, and then a Custom HTML Tag. The template Tags ask for a few small pieces of information, then throw that info into some default JavaScript for Tags like AdWords, Analytics, and Tags from certified vendors like AdRoll, ClickTale, and more.

For instance, Google Tag Manager isn’t the same as Google Analytics, it’s the way that Google Analytics is delivered to your site. Google’s common Tags are included, and they’ve started building in integrations with other Google products to automatically push Tags to GTM, which then can be approved or denied. I see this as an area that will continue to improve in the near future!

In general, the templated Tags actually reduce risk! The users that add these Tags don’t need to understand the JavaScript or the complicated mechanics behind how the Tag works, they just need to find the correct pieces of information and enter them into the correct fields. This is great way to reduce complexity and to help standardize common Tags.

The Custom HTML is exactly what it sounds like. With this Tag, you can add anything to your website. JavaScript, HTML, CSS, you name it! (Check out this handy post I wrote about adding custom advertisements to your site.) This is what you’ll use for any Tags you would like to add that don’t have a pre-built template.

This Tag is clearly the most powerful and most dangerous Tag. These Tags should always be monitored and checked before publishing on a website, and a basic level of web development knowledge is necessary. JavaScript must be included inside of <script> tags, for instance.

Again though, this question comes back to how your team will work internally. With the right person or vendor at the helm, they’ll be able to control who is creating new Tags and make sure that everyone is knowledgeable enough to be working in this environment. They’ll also be able to test Tags before adding them to the website!

Google Tag Manager Features Calm Fears

Often the GTM features you hear about are geared towards marketers. It makes tagging your site so much easier! You can publish in minutes!

Let’s discuss some of the excellent features that make GTM great for development teams.

Built-In Error Checking

Google Tag Manager has a built-in error checker to help catch some of the most common problems. Try to Publish or Preview a Custom HTML Tag with syntax errors and you’ll get an error message like below, letting you know what went wrong and where it happened.

custom-html-js-error

Live Site Debugging

This is a huge! While the dev cycle is important for site upgrades and site features that interact with multiple dependencies and environmental concerns, often we just need to see a marketing Tag is action to confirm that it was added correctly and is firing on the correct page or action.

While you’re working on your current container draft, Google Tag Manager will let you preview and debug all of your current Tags and Triggers on your actual live site. It does this by setting a cookie on just your computer and your browser and then showing only you the most recent, non-published version of your container. These are live Tags, meaning they’ll still send data to Google Analytics or whichever third-party Tag you’re testing.

Additionally, you can share unpublished versions with others via a custom link, so they can also live debug.

Version Control

Speaking of versions, GTM comes with built-in version control. It shocks me how many fully functional websites don’t even have this capability. Every time you publish a new change, it creates a “version” of your current container, which is like a snapshot of all of your Tags, Triggers, and Variables. At any point, you can restore a version and re-publish that.

Standardizing Communication Reduces Risk

I’m a big fan of standards, processes, and efficiency. I’m not just dropping in a few buzzwords, I’m referring to GTM’s use of a “data layer” to communicate information from the server and the page to GTM and back. It’s a JavaScript object that gets added to your page before the GTM snippet and it’s where we put anything that is important to GTM. This is where the teams really need to work together.

Anything placed on the data layer can be pulled into GTM with surprising ease. This helps eliminate confusion and makes communication much easier. If I need a piece of information, I can just ask for it and the dev team knows exactly where to put it and in what format it needs to be in.

Server-Level Control Over Allowed Tags

User level permissions, two-factor authentication, internal staffing decisions, and best practices all still rely on the employee using the tool properly. There’s always the question about worst-case scenario. What if the unthinkable happens? What if someone somehow gains access to your Google Tag Manager account and tries to use that take over your site?

Luckily, there is a way to control which Tags or Variables you even allow on your website. If you needed to lock it down and say that you will allow the marketing team to use GTM for Google Analytics and nothing else, you could do that.

You can set up Whitelists or Blacklists by adding some commands to your data layer on your website. This is controlled by the website server, so even if GTM gets compromised (which it almost certainly will not) you’ll have final say over whether or not those Custom HTML Tags are allowed to run on your site. Keep in mind, this will limit the functionality of GTM, but is great for companies that need that high degree of security.

Advanced Triggers To Aid in Testing

This point is more a suggestion for using GTM than an actual security feature. The more you use GTM, the more you’ll learn the nuances and the tips and tricks. GTM should make tracking your website easier, more consistent, and with less chances for errors. It should not be burdensome or adding unnecessary complexity.

Questions often arise about development cycles or staging/dev sites. I’ve seen companies struggling to manage multiple containers, importing and exporting as things get approved and tested. This is definitely one way to do it, but I’d much prefer to reduce the number of moving parts and keep everything in one container. You can use Triggers and Exceptions to control which Tags fire on which sites. Exceptions, formerly Blocking Rules, are your best friend and can help handle the multiple environments question.

Instead of telling GTM where to fire, you can use some double negatives and tell it where it should NOT fire. You can create great Exceptions like “Not on Dev Site” or “Not on Live Site.” This lets you keep your Triggers exactly the same while just changing on which environment they’ll be deployed.

Using A Common Tool For Greater Flexibility

I’ve worked on a lot of websites over the years and I’ve seen a lot of “custom solutions.” These solutions can be brilliant and inspired or tangled messes of spaghetti code and syntax errors. Your site may have some such solutions and they may be working perfectly fine. Sometimes though, I think it makes sense to use tools that are tested and supported by teams of people. Not only is the tool your using potentially better for the job, but it comes with a few added benefits:

  • GTM is a learnable skill. New employees can come in already having worked with Google Tag Manager, or can take online or in-person courses to better their skills.
  • GTM can be collaborative. Going with the previous point, you can also use GTM with vendors and outside employees who have experience with the tool. Google clearly has user permissions worked out already, and makes sharing access a breeze.
  • Support is available. Google Tag Manager comes with an development guide, has a very active user base that always helping out, and you’re most likely facing challenges that have already been solved.
  • Consulting is available. If you’re looking for Google Tag Manager consulting, you’ll find Google Analytics Certified Partners all over that have been working with Google Tag Manager for years. For complicated installations or to even get your site tracking off the ground, you can look up reviews, case studies, and work with experts to help you accomplish your goals. And, depending on the company you work with, you’ll hopefully get some training and a coordinated “pass of the baton” at the end of your engagement so you can manage your site going forward.

Final Thoughts

The decision to implement Google Tag Manager is significant enough to warrant a thorough review of the security issues and the ways that GTM addresses those issues. Hopefully this article helped to debunk some fears and provide resources to help you make an educated decision!

About

Jon Meck is our Technical Marketing Manager, promoting our services and trainings to the world. He has a jack-of-all-trades background, working for companies large and small in social media, website design and maintenance, and analytics. He is an Excel enthusiast, he loves efficiency, and he is strong proponent of the “Work Smarter, Not Harder” mantra. Jon is also the author of two number puzzle books.

  • Jurre Krijbolder

    Hi Jon, you state: “Additionally, you can share unpublished versions with others via a custom link, so they can also live debug.” I remember that link being available in GTM v1, but can’t seem to find it in GTM v2. Are you able to show/share were I can find that link? Thanks in advance!

    • Jon Meck

      Hi Jurre,

      In V2, you can only share versions. This isn’t a huge deal, you can make many versions without publishing; you can also delete versions.

      Head over to the Versions tab, then click on the Actions button next to one of your created versions and you’ll see a “Share Preview” option. Then it’s just like the original version.

      Hope this helps!
      -Jon

  • Dan Wilkerson

    I would just add to this one thought: when properly understood and implemented, the benefits far outweigh the costs. Developers can spend time developing, and don’t need to try and understand the abstractions Google Analytics uses. Marketing, who is responsible and vested in the data collection, now can audit and adjust that collection mechanism. The time and cost savings can be tremendous.

Contact Us.

LunaMetrics

24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us

1.877.220.LUNA

1.412.381.5500

getinfo@lunametrics.com

Questions?
We'll get back to you
in ONE business day.