I was pleasantly surprised by the amount of interest in the "Universal Tag" topic at X Change. Typically, eyes tend to glaze over at even the mention of terms like 'script' or 'variables'–after all, that's "IT stuff" that should just work. It's not really the interesting part of web analytics.
I agree with that assessment, up to a point. I'm fortunate enough to do the whole analytics 'enchilada' at HP, including tagging & data collection. Given the choice between doing tagging and actual analysis, I would choose analysis any day of the week. So why present this topic, and why were there so many other attendees that were interested?
The short answer is this: everyone knows tagging determines how well analysis turns out. The dirty-little-secret that never comes up during the sales cycle is that the 'tagging', or the method by which meta-data is marshaled into an analytics system, is a process that's easily botched. If your IT team doesn't understand something; if you have any ambiguity in your definitions or technical specifications; if there are different stakeholder priorities–botching will likely ensue. Even with the best specs, availability, and priority, it amazes me how different stakeholders interpret the same well defined standard differently.
Even when we get it right, beacons & tags tend to grow organically over time. I know that sounds really cool as market speak, because organic is good–right? Unfortunately, cancer also grows organically–and also with very little effort from your IT team. Over time, we have the same site & customer meta-data being marshaled through an any number of vendor-specific variables that ultimately track the same information.
The reason "Universal Tag" was an attractive topic comes down to these basic principles, all of which were brought up during the two tagging sessions:
- Universal Tag as a Data Standard:
the Universal Tag is an attempt to undo years of not having a common foundation for good metadata. We live in a post-Babel analytics world where everyone speaks different "data dialects". Some of our metadata languages are similar enough that you get the gist of what's being said–perhaps Coremetrics tagging & Omniture tagging are like French and Spanish. Others are a farther apart — compare your typical spotlight tag with any web analytics tag, for example. Many attendees were interested in a Universal Tag as a type of data dictionary that enables a common metadata language.
- Universal Tags to Simplify Implementation:
still others were looking at Universal Tags as a solution to manage the complexity of actual implementation. There were specific solutions mentioned, such as Tealium and JSHub. I think this is a bigger problem that, as one of the participants said, "relates back to an organizations ability to have strong analytics & governance capabilities", regardless of the overall tagging solution used.
- Universal Tags to Simplify Data Transport:
others were looking for a single tag that reduces the number of physical beacons on the page. Here, we're thinking about the customer experience–why should we have 10 different physical beacons send back ultimately the same 'stuff' and not just have one beacon ping them all later? As nice as this sounds, this is a much more lofty goal given another key element that was brought up: can we rely on vendors to solve this problem? The general consensus there is no, not really. In retrospect, I think this was a harder problem to solve than the universal data dictionary.
So there you have it: the problems we discussed during our X Change huddle. So what are we (collectively) going to do about it?
First, I believe we need further discussions on the topic. This isn't something that we can solve after two meetings, regardless of how productive they were. Michael Scherotter from Microsoft brought up the point that perhaps we're trying to solve the wrong problem when it comes to 'tagging' in JavaScript, which many currently take for granted as the main language of a Universal Tag. Perhaps that will change as new platforms emerge, some of which may not support JavaScript.
Second, I believe this effort needs to be community sponsored and "open" in the most liberal terms. Many side conversations after the huddle pointed out that there's a sense of wanting to 'take back' this data from the vendors. That's not to say that we, as customers, don't 'own' the data in the first place–but rather, there's a strong desire to have various e-marketing & analytics vendors become smart enough to know "our" data, rather than have us constantly place our data in "their" format. And that's a tall order for our analytics community at the end of the day. I'll write more on that later.
So what did we miss? Were there other topics or ideas that you would like to have seen? Please post your comments and feedback so we can continue this discussion.
Finally, I'd like to thank all the participants for their thoughtful contribution to this subject. Many of the ideas summarized here weren't even on the radar before the huddle–these are truly community driven concepts. As with many of the X Change huddles, there were a number of ideas presented I hope to use in the following months at HP.
Find out more at Matthew Wright's blog