The traditional Web Analytics industry tend to bring up the concept of a universal tag (a common data collection tracking script) now and then. Which is not at all bad thinking, I even participated in a session at the X change Analytics symposium in San Francisco earlier this year, on that subject.
The traditional Web Analytics industry tend to bring up the concept of a universal tag (a common data collection tracking script) now and then. Which is not at all bad thinking, I even participated in a session at the X change Analytics symposium in San Francisco earlier this year, on that subject. However, thinking it through, you might agree with me, that there is probably little point in creating a universal tag, as you (the web analytics deployment engineer) doesn’t really get anything else but yet another somewhat proprietary tag. What you might get though, is a vendor independent tag, which is probably a much better way to think about this, when brought up. If this is of your interest, I suggest you go have a look at Tealium (They call it universal tag though, but describe it as one tag, any vendor).
Having said that, I would like to suggest a different route, one that I in particularly talked about in my Adobe acquisition of Omniture post - where I suggest that the content and tracking marriage will be won or lost on a Web OS level.
BUT - while we wait for my prophecy to come true, I’ve been thinking a lot about how we can move towards a simpler web analytics data collection deployment, and at the same time a much richer data set. This sounds like the deployment engineers nirvana, but it might not be that far-fetched, if we take a step back and look at what we already have.
The universal tag should not be a standardization agreement in between a few web analytics vendors or even a forced through Web Analytics Association standard, neither should it be a vendor independent tag, developed by consultants.
I suggest that web analytics vendors adopt the most popular Microformats, so that the plain vanilla tracking scripts presently in place are able to read already semantic tagged elements.
Read that again. Think about it. You get more data, better data, with little or no effort - other than what your web analytics vendor have to do. When analytics experts spots an enterprise web property with nothing more than a plain vanilla tag, it creates a tiny giggle. It shouldn’t be that way though, that simple tag should be able, through settings, to adopt and read Microformats, so that it becomes a whole lot more sophisticated - and that without ANY web analytics tracking script hacking. Using this idea, the extreme scenario, will be that anything else BUT plain vanilla tagging is laughable, simply because you will overwrite semantic rich information.
Example
Let me provide an example to illustrate my point on how comical it is that we force ourselves to mark up important data points twice, and sometimes even more:
If we look at the following Article from one of AOL’s web properties:
We will see, through the page source, that they use Omniture Sitecatalyst and that they collect sematic rich information into a set of custom fields:
s_265.disablepipath = false;
s_265.pfxID = "nws";
s_265.prop2 = "Article";
s_265.mmxgo = true;
s_265.prop1 = "World";
s_265.channel = "us.spherenews";
s_265.linkInternalFilters = "javascript:,sphere.com";
s_265.pageName = "nws : Iran Admits Guards Beat Prisoners to Death";
s_265.prop9 = "bsd:19287999";
This type of web analytics tagging is very much standard and if anything above average level in sophistication. Well done AOL! However, if you take a second look at the page source, you will notice that they have chosen to implement the hNews Microformat.
<div class="article hnews hentry item" id="article-19287999">
<div class="postTop clrFx">
<div class="artHeadline">
<h1 class="entry-title">
Iran Admits Guards Beat Prisoners to Death</h1>
<div class="miniComm">
<p class="author vcard"><b class="fn">
ALI AKBAR DAREINI</b></p>
<span class="source-org vcard"><span class="org fn">AP</span></span>
(*I didn’t paste all the hNews Microformat used elements, so take the above as confirmation only and go look at the page source, for a full look at the use, which will actually show MORE semantic rich information that whats being tracked with Sitecatalyst)
Which just shows that the values inflated into the Omniture Sitecatalyst custom fields, are essentially a duplicate tagging effort, as this is already included into the hNews tags. This should have been, if not automatic, then nothing more than a tick-in-a-box in the Omniture settings sections, confirming that the client would like to pick up hNews tags.
Conclusion
The universal tag should not be an agreement in between web analytics vendors or even a forced through Web Analytics Association standard, neither should it be a vendor independent tag, developed by consultants. I suggest that web analytics vendors adopt the most popular Microformats, so that the plain vanilla tracking scripts presently in place are able to read already semantic tagged elements.
Merry Christmas 
/ Dennis (@dennismortensen)
n.b. If this makes little sense, or if your thoughts are around, what’s the point? go read a) Avinash’s technical implementation post (which by its breath shows the pain in deployment) and b) Ian’s post about whence the universal tag? (which provide other great viewpoints on how to solve the current pain)
Excerpt from:
Using Microformats to extend Web Analytics tagging
Popularity: 40% [?]
I and the web analytics Industry in general was flabbergasted by the announcement of the Adobe Omniture marriage and there’s been a big ‘huh?’ debate going on since; which I see no reason to elaborate on. Eric does (as usual) some good analysis/commentary in his two posts 
