Blast Analytics and Marketing

Analytics Blog

Supporting Leaders to EVOLVE
Category: Digital Analytics

4 Helpful Tips to Avoid Risk with Google Tag Manager

November 25, 2013

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.

Olaf Calderon
About the Author

Olaf is the Director of Implementation at Blast Analytics & Marketing. He and the implementation team, handle configuration, installation and training of analytics tools. He spends the majority of time developing tracking code and He loves the challenges that every project presents and is always finding more efficient ways for our clients to collect, read and analyze their data. His passion is developing tools, processes or methods to make everyone's life easier.

Olaf Calderon has written on the Blast Digital Customer Experience and Analytics Blog.