A Visit-based dimension in Webtrends is an eVar in Adobe Analytics, right? And Visits for a Page in Adobe Analytics will yield the same result as Sessions for a Page in Google Analytics, no? Beware of false friends! This article series shows you the nuts and bolts of Custom Variables, holders of your most precious data – by comparing Google, Adobe, and Webtrends Analytics.
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.
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.
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.
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.)
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.
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.
We concentrate on other practitioner concerns, such as walking through the items you’ll need to have Omniture enable. We find that folks sometime forget about this until the last minute… for instance enabling visits and visitor metrics for Commerce variables, enabling pathing on prop variables other than Pages, specifying the traffic and conversion variables you would like to see sub-related or co-related.
Quality assurance is a big focus of ours in the Implementation Toolkit…again this is something we’ve seen from our time “in the trenches” that people tend to rush through; hence, we’ve made our 20 point Quality Assurance check list available…the same one we use ourselves .
The other thing we concentrated on in writing the Toolkit is to make the content as easy to understand as possible…even for non-implementers. In fact, we have gotten some great feedback from web analytics project managers who have said that the Toolkit has given them the background they need to manage their technical resources when doing an implementation.
So, that’s basically how I see the Toolkit as being different than Omniture documentation. Of course, you might go the route Stephane Hamel suggested in his review of the Toolkit, and use the Toolkit in tandem with Omniture’s Fusion Playbook.
Either way, take a look for yourself at: http://www.semphonic.com/analytics/impguides.asp
I should mention that we’re running a contest right now to give away a copy of the Implementation Toolkit. Here’s the deal:
You email us your most challenging Omniture implementation or HBX Migration question. We’ll select the toughest question and answer it at X Change <http://www.semphonic.com/conf/index.asp> , and send you a copy of the Toolkit as a reward for having the hardest, most difficult question. You don’t need to attend X Change to win, but it would be nice, right?
And for those of you who ask a question that isn’t the toughest…we’ll answer them too, and send you our response directly.
Don’t forget to provide your name and organization name with your email. Wewon’t use this information for any reason other than to contact you if you won and to answer the question you submit. Remember we can only answer one question per person, so make it a good one!
Send your entries to: firstname.lastname@example.org
And, if you’d like to purchase the Toolkit straightaway and receive a 10% discount, just go to http://www.semphonic.com/analytics/impguides.asp and use Manoj’s promo code: manoj1008