Tag Management Systems (TMS) promise independence from IT and thus quicker deployment of new tracking code, faster load times, lower switching costs, and a lot of other wonderful things. But even though TMS definitely have their benefits, you should know about some issues vendors may be reluctant to tell you.

Tag Management is “da hype” in the realm of Digital Analytics and Online Marketing. There are at least a dozen vendors with a sensible offering (Tealium, TagMan, Ensighten, BrightTag, DC Storm, Impact Radius, QuBit, Site Tagger, SuperTag, Tag Commander, UberTags, Google Tag Manager, and you name it). Some of them have very active marketing departments and scream at you about their benefits at every corner of the internet.

Google has made Tag Management Systems mainstream
Google came out last year with its own free Tag Manager, making Tag Management mainstream by giving everybody the chance to try out what it actually feels like – similar to how Google Analytics proselytized the masses about Web Analytics. Adobe then recently made its own Tag Manager free of charge and has been pushing you to use it ever since. Actually, when you set up a site for  SiteCatalyst now, you have to go through the backdoor to get the “original” SiteCatalyst code and not the Tag Manager code. Adobe is probably aware of the usually tedious implementation, one of the main reasons why sometimes SiteCatalyst installations remain shy of their awesome potential, but it probably is also a strategy to lock people into their (very good) products and take away one of the benefits away that TMS give you: The lower switching costs to other vendors.

If you are serious about Digital Marketing, evaluate a TMS
Don’t get me wrong: I am a fan of TMS. I think everyone who takes Web Analytics and Online Marketing seriously should evaluate Tag Management Systems. I have struggled for many years with IT departments and slow release cycles that so often caused me not to try something new just because implementing it would take so long (and cost so much money), even though I knew which code had to go where. So I am the first to admit that TMS address one of the biggest needs of every Online Marketer who wants to continuously improve his online channels.

Freedom through Tag Management Systems?

Not as easy as it sounds
But switching to a Tag Management System and operating one isn’t as easy as it sometimes may sound. Here are some things that vendors will tell you only reluctantly – and one thing you should be aware of when settling for the “free” offers from Google or Adobe.

1. A Tag Management System doesn’t mean independence from your IT.

With a TMS, you can put any JavaScript code on your website, even code that produces little popup windows greeting every visitor with “Hi Erica, did you water your flowers today?”. And as much as the following message hurts: Your IT should know about your TMS’s capabilities, because a little tracking code can cause bugs in other critical functions of your website – you don’t have to create silly popup windows for that to happen.

So involve your IT from the start when evaluating a TMS. If you don’t, they will mistrust you even more – or block the TMS’s introduction entirely. In the end, a sensible tag deployment process still involves your IT: Only the IT should have the right to “publish” new tags (this hurts so much!), and they should be reviewing your tags before they go live. Hopefully, after a while they find out that you do no evil and speed up the review process. And being able to test tags on your live system is already a great improvement. Because then you know if it works before your IT implements it on a test system.

And more,  that doesn’t mean that you don’t gain more flexibility with a TMS. As one of our clients recently put it: “We won’t gain independence from IT, but we will gain independence from releases.” And in big, slow-moving companies where releases (updates to the website) come only once or twice a year, this is a major upgrade.

2. “There’s this one “universal/container tag”, and that’s it in terms of putting code on the site, right? Because from then on, I can do everything in the TMS’s admin interface, can’t I?“

No. You will definitely reduce the amount of (on-site) coding needed, and you can deploy a lot of tags directly through the Admin interface, but for many things, it is recommended you use a “data layer” to transmit page-specific information and keep this data separate from other stuff on the website. A data layer means additional code in the HTML of your pages that has to be implemented by IT. Specialized Event Tracking mostly requires additional coding, too, by the way.

Why? Doesn’t my Tag Management System allow me to dynamically collect whatever the value of the JavaScript variable “total_price” is or the text inside of the DOM element with the id “pricetag”? Yes, it probably does. But the developer that creates and manages this JavaScript variable or this DOM element doesn’t know nor see in his code that your TMS needs this information. So next time he changes the variable name or the DOM element’s id, your TMS suddenly won’t get these crucial values anymore, and thus the five third-party tags that hinge on them – and it may be hard to find out why.

That’s why I recommend to put all the needed page-specific information into this separate data layer. The developer will then know that the data layer code is for the Tag Management System only, and that he better not change it without consulting with you.

What that means is: Any time you want to track new stuff that is not yet in this data layer, you will probably need new code on the website itself, meaning new variables and values for your data layer.

(See a very good how-to for data layers by the legendary Justin Cutroni)

3. Migrating to a Tag Management System can be a migraine. An expensive one.

Migrating to a TMS is like switching to a new Web Analytics tool for your site.  And if you haven’t documented very well which tracking code does what on which parts of your site (which is lamentably the case for 99% of websites), be prepared for a lot of surprises of the “why is x not being tracked anymore?” type.

You can and maybe should do a “vendor-by-vendor” approach, migrating the easiest vendors’ tags first. In the meantime, you can also get comfortable with your TMS via “easy” examples. But in order to migrate more complex Analytics code, say your heavily customized Google Analytics Tracking Code to Google Tag Manager, you need to replace all the GA code on a page at the same time.

Say for example, you have a GA-tagged page with an insurance price calculator that works with Flash or Ajax and does a lot of Event Tracking. You can’t simply replace the GA Base Tag in the head of the HTML by the TMS’s “universal tag” because then, the Event Tracking for your price calculator won’t work anymore. You have to migrate ALL the code on a particular page simultaneously, including the Event Tracking in the calculator. This slows down migration. You may use your TMS’s code on page A and your “native” GA code on page B though. 

(Note that some TMS may not have this problem. Ask your vendor.)

4. Tag Management Systems are easier than learning JavaScript, but they are not self-explanatory – you need PEOPLE with KNOW-HOW of these systems.

Adding a TMS means another tool in your arsenal. A tool needs people that know how to work with it (at least three, because one may leave, and the other one may be sick or on vacation). In some companies where every new tool needs to go through an extensive approval process, this can be a real problem. And building up the know-how needs an investment by the company. This could be more crucial for the TMS than for other systems, given the TMS’s central role for all kinds of analytics or marketing tags. Lose that one person with knowledge of the system, and you have a problem in more than just one area.

5. Adobe’s and Google’s Tag Management Systems are good for their own products, but not for other vendor tags.

Analytics tool vendors are not the greatest fans of Tag Management Systems because TMS make it a little easier to switch from a tool to another one. The only exception are, of course, the vendors’ own tools. So if you’re all into Google tools, you may be fine with Google Tag Manager (even though GTM doesn’t support Google Analytics Content Experiments so far). Likewise with Adobe’s Tag Manager.

But both Tag Mangers were made so you stick with their tools, not their competitors’. So they are not that good at integrating tags of, say, Webtrends. Moreover, the functionality of most of the paid TMS heavily outlasts GTM or Adobe’s Tag Manager.

So even if the Adobe or Google product may seem like an obvious choice because it integrates with your main product, think twice and do evaluate a paid vendor as well.

Your turn!
Are you currently evaluating a TMS? What have been your biggest issues when migrating to a TMS or when operating one? How did you get your IT’s buy-in? I am curious to read about other experiences.