4 Helpful Tips to Avoid Risk with Google Tag Manager

4 Helpful Tips to Avoid Risk with Google Tag Manager

Posted by on Mon, Nov 25, 2013
Filed Under | Analytics, Google Analytics


Google Tag Manager (GTM), as well as many other tag management solutions, have been gaining tremendous ground in the past year.  It seems like yesterday we were discussing the idea of implementing Google Analytics code via a tag management solution.

Now, we’ve made Tag Management a part of our daily routine and we’ve seen GTM grow from a simple marketing tag insertion tool, to a more robust solution for handling JavaScript within macros, and just as of late, Google Tag Manager native click event listeners.

This is great.  Now, Google Tag Manager is a complete solution for implementing simple to complex tag code, including Google Analytics and all other marketing tracking tags our clients utilize.  The only bump in the road comes from development teams raising the question of security and testing.

Eliminate Risk of Custom HTML Tags

While the majority of sites may use Google Tag Management to insert marketing tag code via the default Google Tag Manager templates it provides — some of us make heavy use of the Custom HTML tag.

The Custom HTML tag poses a major risk since the custom code inserted could potentially break your site’s functionality.  Some people have found this out the hard way, like Junta Sekimori.

Let us ease your mind…there is nothing to worry about. We have four helpful tips to bring your risk down to near zero.

Tip #1: Catch Any Errors

The majority of the code we implement is JavaScript. In fact, aside from an awesome element attribute framework we’ve developed (blog on this coming soon), all of the code we place in Custom HTML tags is JavaScript.  So right off the bat, we can encapsulate our JavaScript with a Try Catch (error handling).  If anything goes wrong, the tracking code such as Google Analytics will fail, but the site will continue to work as expected.

Tip #2: Test Containers

In most cases, sites being built or updated, have a “development” or “staging” environment, sometimes both, aside from the “live” production environment.GTM Container  We won’t get into the reason why you need these, but in short, think of it as a rehearsal.  You have all of the elements for the performance except for the audience. This is where you make sure EVERYTHING works before showtime.

With Google Tag Manager, you are able to create and utilize a separate test container for these environments.  This allows you to test and make sure everything works, without introducing unnecessary risks to the “live” site — or keeping to our analogy…the “live” performance.

Tip #3: Rules and Regulations

The most important thing in implementing Google Tag Manager and code changes via GTM, is to follow your established rules and regulations for development.  This means that if you have 1 developer for your small site, then you only have 1 person to involve in the process.  But if you have 3 departments and a few dozen people, you need to stick to a standard procedure for making changes to your site.

The big difference here is the usage of resources.  While your development cycle my have scheduled release dates, publishing tags on Google Tag Manager does not need to follow that schedule.  After all, if your Marketing team needs a floodlight tag added tomorrow because it’s the end of the month and their campaign lasts 1 month, it would not help them at all if the next scheduled release is 2 or 3 weeks away.

True, things should not be left for last minute, but we all know the reality of life!  Besides, why wait — when you have a solution that can get their tag up within hours?  In fact, they can set it all up themselves!

Template Tags…Yes.  Custom HTML…No.

Marketing tags for the most part, don’t get in the way of websites, not in a functionality way.  I have yet to meet a Google Tag Manager Template Tag that breaks the site functionality.  This is of course, excludes the use of the Custom HTML tag.  So the rule there would be… Marketing people only get to setup template tags!  No Custom HTML for them.

Currently, Google Tag Manager supports the following tags via a template:

  • AdRoll Smart Pixel
  • AdWords Remarketing
  • Turn Conversion Tracking
  • Turn Data Collection
  • DoubleClick Floodlight Counter
  • DoubleClick Floodlight Sales
  • Mediaplex – IFRAME MCT Tag
  • Mediaplex – Standard IMG ROI Tag
  • Turn Conversion Tracking
  • AdWords Conversion Tracking
  • Marin Software
  • AdAdvisor
  • Bizo Insight
  • comScore Unified Digital Measurement
  • Media6Degrees Universal Pixel
  • ClickTale Standard Tracking
  • comScore Unified Digital Measurement
  • Google Analytics
  • Universal Analytics (beta)

I wouldn’t be surprised if this list quadruples by the end of the year.  New tags are being created rapidly.

Tag Enforcement

If you find it hard to enforce deployment of tags on your site(s), you also have the option to completely block out specific classed of tags by having a whitelist and/or blacklist of tags for each page.  This involves your development team a little bit more than usual but it’s sure to make some folks back in the security team a lot more comfortable.  Send them this technical security reference guide straight from Google.

Tip #4: Careful Testing with Clear Test Procedures

GTM handle with careWithout doubt, something that should never be skipped, is testing.  The last thing you want is to push a change that causes things to break. Google Tag Manager allows for several layers of testing and with the implementation of staging and development containers, the number of testing points grows respectively.

Assuming established experience in using Google Tag Manager, and that the GTM snippet is present on all pages of the site, here is a suggested set of testing procedures for Google Tag Management implementations.

Testing Procedure for GTM Marketing Tags

Marketing tags may be safe for implementation on the site, but that doesn’t mean you don’t need to test them to make sure they’re working properly!

After configuring the tag, along with any Rules and Macros as necessary, GTM allows for putting a browser on test mode or as they call it “Preview” mode.  This preview mode is a tool that allows you to run the site on your browser only, with the updated code.  It has an option call “debug” which will create an iframe at the bottom to show you if and when tags are failing or firing.

For example, this debug option let’s you see if the floodlight tag is firing on the appropriate page. At this point, you’ve just modified the container’s Draft version and would not want to create a Version until you make sure the tag is working properly.

  1. Once you’ve verified this with the “Preview” tool, you can create a Version from the Draft.
  2. Now you can pass a “Preview” link of this version to your manager for her to test on her browser.
  3. Your manager gives you a thumbs up to publish OR she can publish it herself.

Right there you see the need to establish regulations.

  • Who will be the responsible person for configuration of tags?
  • Who will do testing?
  • Who will approve?
  • Who will publish? Will this be the same or a different person who approves?

You can also see that there should be testing at two levels:

  1. The Draft level
  2. And at the Version level

Marketing tags would normally only be added to the “live” container and once published, the tag will be operational.  You can see that this process could be as simple as only involving 2-3 people and could be completed within a day or two.

Google Tag Manager user permissions allow you to setup tags according to your “role” structure and make sure nobody “accidentally” does something they’re not supposed to do.

firePlaying With Fire!

We all know that if you play with fire, you’ll likely get burned.

We don’t do website updates live on the site, or take down a page while we make updates.  At least not those of us who follow development best practices.  So just like the Marketing guy with his templated tag, when a programmer develops code to be used in a Custom HTML tag, it is imperative to use the Draft Preview option to test.  This way you don’t risk getting burned if something breaks.

This would be done on either the “live” container, or the “staging” container if being used.

Use this Process to Avoid Getting Burned

This is a simple diagram that can be followed in order to avoid getting burned:

Google Tag Manager Test Process

If a fire starts, revert quickly to avoid a bad burn

This process can be repeated both on the ‘Staging/Development’ containers and on the ‘Live’ container.  As you can see, by the time you’re ready to publish Live, the fire risk is greatly minimized.

There’s a chance that a tag doesn’t fail during testing, but something could change in the future that causes a conflict and site and/or tracking code could stop working properly.

If it’s something critical, affecting functionality, you can easily revert in Google Tag Manager, to the last known good Version with the click of a button.

Questions about GTM Tips?

Leave a comment below if you have any questions about these GTM tips, or contact us for Google Tag Management solution consulting.  If you want more advanced resources on Google Tag Management check out the Google Developer Guide for GTM.

Enjoy this post?

Join the discussion below, subscribe to our RSS feed or share it on the web.

This post was written by:

has written 6 posts on the Web Analytics Blog.

Olaf is a Google Analytics Consultant at Blast Analytics & Marketing. He spends the majority of time developing tracking code and finding more efficient ways for our clients to read and analyze their data He loves the challenges that every project presents and is always trying to develop tools or methods to make everyone's life easier.

Add Olaf to your circles on Google+


Tags: , , , , ,
  • http://www.greenhatwebs.com/ Ryan Masterson

    Great post, Olaf!

    In tip #2 Testing Containers, you said, “With Google Tag Manager, you are able to create and utilize a separate test container for these environments.” The problem is that different containers use different container code snippets. What if the same code base is used throughout the different sites, i.e., development, staging, and production?

    Great idea to prevent Marketing from making Custom HTML tags, and instead require them to use just template tags. Is there why to enforce this with permissions — so they don’t even have the option of Custom HTML tags?

  • http://www.blastam.com/ Olaf Calderon

    Hello Ryan,

    Great point. I encounter this all the time where they either don’t want to have any difference in code or they’re using some template system that prevents them from doing it. The great thing about the snippet is that the only thing that varies is the ID, so the solution is to build a short script that determines the correct ID based on the environment. This will vary but most of the time staging or dev environments are on a separate subdomain.

    Replace the ‘GTM-XXXX’ section of the snippet with this:

    (/staging.yourdomain.com/i).test(document.location.hostname) ? ‘GTM-STAGING’ : ‘GTM-DEFAULT’

    Make sure your staging environment is correctly set and the appropriate GTM Id’s are setup for STAGING and DEFAULT.

    This will allow you to set the exact same code on either environment while allowing you to use 2 separate containers.

    As for your second point. Also an excellent point. Sometimes you will have no choice but to use a CustomHTML tag in order to place a marketing snippet. Google is continuously working on increasing the template tags but there are dozens if not hundreds of tags out there that may never be “templated”.

    Unfortunately no, there’s no way to prevent the TYPE of tags that users create based on permissions. For this reason I suggest not allowing everyone the right to publish. This way they’re forced into the established flow of production and whomever is the one to audit and publish would be able to capture, question, test, deny or approve any tags. The great thing is that the marketing person can handle producing the tags and ensuring they’re firing correctly.

  • http://www.greenhatwebs.com/ Ryan Masterson

    Hi Olaf,

    That’s a great solution. Thanks… However now I’m wondering how necessary it is to create two different containers since GTM already has built-in previewing, versioning, and publishing. For example, you’re diagram under “Use this Process to Avoid Getting Burned” is very good and thorough, but it doesn’t incorporate testing on different sites. But maybe it doesn’t need too, either.

  • http://www.blastam.com/ Olaf Calderon

    I totally agree. However, a staging environment is something usually already in place for most major productions, so the problem is that when you have site changes on staging and not on production, you need to test on staging separately and thus would encounter more complications if sharing a container with production. This gives way for the need to have a separate container to handle staging. Some of our clients even have a separate GA account for staging so that they don’t have to filter out “development” traffic that would otherwise inflate their metrics.

    For smaller productions, you can have your staging environment share the container with production and then test at the version level prior to publishing. Once you push changes from staging to the live site, you can immediately publish your container and you’re done.

  • http://www.greenhatwebs.com/ Ryan Masterson

    Your point about being able to test site changes on staging that aren’t yet in production is a good case for using separate containers.

    However, as I think about this more, I’m still leaning towards using one container. The problem with two containers is that there is lots of room for human error when trying to match all of the tags between the container for staging and the container for production. I would feel that my tests in staging are less reliable.

    Perhaps the better solution is to use more complex URL-based rules to control when a tag fires (instead of using the rule {{url}} matches RegEx .*). Like this we could easily fire tags on staging without firing them on production (such as to test a new feature in staging not yet on production), and can fire tags on production that we don’t need firing on staging by default (such as data that we would already by trying to filter out, such Google Analytics).

  • http://www.blastam.com/ Olaf Calderon

    Again you have a great point but this is the caveat with using one container.

    I have a custom HTML tag on my live site and I go make changes for my next update. Then, we have the need to make a quick change on the existing code on the live site. However, I’ve been working on the tag and it’s not ready to be pushed to the live site. Now I have to restore the previous tag, make my changes, publish and then restore the version I was working on.

    On a dual container setting, I just go to my production tag, add the changes and publish.

    Of course, I still have to update my “dev” tag with the changes but as you can see, the push to the live site is much smoother.

    The best solution will be when Google finds a way to allow us to push only certain tags or versions of tags to the live site the way other TMSs do. If you’re dealing mostly with marketing tags, then it doesn’t make sense to use two containers in either scenario, but get into complex CustomHTML tags and you’ll quickly hit that wall that makes you realize you need a “buffer” -



Goal Driven Online Marketing & Analytics
Copyright © 1999-2013 Blast Analytics & Marketing