Analytics and Search Marketing Tips
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.
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.
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.
In most cases, sites being built or updated, have a “development” or “staging” environment, sometimes both, aside from the “live” production environment. 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.
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!
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:
I wouldn’t be surprised if this list quadruples by the end of the year. New tags are being created rapidly.
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.
Without 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.
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.
Right there you see the need to establish regulations.
You can also see that there should be testing at two levels:
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.
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.
This is a simple diagram that can be followed in order to avoid getting burned:
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.
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.
Share this Post
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.
Add Olaf to your circles on Google+ Olaf Calderon has written 7 posts on the Web Analytics Blog.
Digital Analytics Blog
We're here to help with tips and insight on the following topics:
Optimize your website and marketing campaigns