Using Microformats to extend Web Analytics tagging

microformats-logoThe 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 subject, 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 (in the extreme scenario), will create a scenario, where anything else BUT plain vanilla tagging is laughable, simply because you will overwrite semantic rich information.


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 semantic 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"; = "us.spherenews";
s_265.linkInternalFilters = "javascript:,";
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">
<span class="source-org vcard"><span class="org fn">AP</span></span>

(*I didn’t paste all hNews Microformat used elements, so take the above as confirmation only and go look at the page source, for a full usage look, which will 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.


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)

  • Matt Lillig

    Good info Dennis.

    Seems like this would be a much easier approach than having to repopulate variables within your 3rd party analytics script. I wonder how often this “duplicate tagging” occurs out there?? Do you see it all of the time?

    Anything to help improve the speed of implementation and tracking is obviously worth exploring.

  • Dennis R. Mortensen

    Hey Matt,

    >>I wonder how often this “duplicate tagging” occurs out there??

    Unfortunately Microformats are not as widely used as I would like them to be. However, there is a correlation in regards to those wanting sophisticated analytics tagging and those also wanting sophisticated content tagging (and that mostly through Microformats).

    We at Yahoo by the way, actually pushed this aggressively when Kelkoo started using the hListing Microformat last year.

    d. :-)

  • Olivier Silvestre

    Hey Dennis,
    I love the topic. It’s a great one to discuss and debate over. I’m very much in agreement with you and your post. I would like to add that Tealium’s universal Tag is not just for Web Analytics solutions. It goes above and beyond (survey, email, affiliate, custom DB, etc). All online solutions proposed by any vendors in need to collect data can be served by the Universal Tag. So it’s not just data collection for Web Analytics solution that need to be solved, but all solutions in need of any data. At Tealium, we thrive to make our Solution even simpler, more flexible, more powerful and more standardized. Hopefully, by collaborating all together and listening to everyone’s feedback and ideas, we should be able sooner than later to make online tool/solution deployment a “nightmare” of the past, so that we can all focus on marketing strategies, tactics, analysis and optimization.
    Cheers, and merry Christmas 2009
    Olivier Silvestre

  • Eric Hamilton

    Sounds good to me also,
    However, being a former web developer, I know that some web developers are lazy when it comes to consistency in tagging. Non-descriptive title tags are other issue. How do you feel about the lack of consistency when deploying HTML tags on a given web site? How can this be easily addressed? Is this even an issue in your opinion?



  • Ali Behnam

    Great post as usual Dennis.
    I agree that for many sites, the data being sent to the analytics tags is repetitive.

    I do want to clarify that the Tealium Universal Tag already supports the ability to read such data points for those who have them. We also have customers that read values from other existing sources such as meta tags and I believe some of the vendors also provide some level of support for this type of data capture.

    But as you mentioned, the benefit that we get is that we can deploy such clients with a single include file to the vendor(s) of their choice.

  • Dennis R. Mortensen

    Hi Eric,

    My common sense tells me, that if people don’t have the “energy” to validate their HTML tags (essentially letting the browser choose what to render on their behalf), they probably don’t have the energy to validate their Analytics tags – and would be happy with the vendor collecting the most appropriate on their behalf. So, no worse, no better. Where the pendant engineers among us, would validate the HTML (and the proper Microformats) and get perfect rendering and data collection in one!

    d. :-)

  • Dennis R. Mortensen

    Hi Ali,

    >>and I believe some of the vendors also provide some level of support for this type of data capture.

    Indeed and good input Ali. I would love to see this as something not extended as yet another custom setup (better than repetitive tagging though), but more as a verification of the fact that I use hNews or any other Microformat (END of configuration).

    Do you have a screenshot of said vendor you can share ?

    Merry Christmas
    d. :-)

  • James Dutton


    Interesting article. Reminds me of when I worked (many years ago back in 2004) with HP Asia where we decided to minimise the custom Omniture tagging requirements and leverage scripts that pulled meta data published by the cms into the SC code. This was back in the day when tags were the most sophisticated published data available, outside of a rigorous custom implementation.

    This concept is still in play for many clients I work with. The caveat, of course, is that very few web publishing systems (correct me if I am wrong) have been correctly implemented… that would enable this.

    Typical example: Client invests in Teamsite, but has yet to implement in a governed and structured manner – ergo despite the aspirations of simplified data collection, the measurement team is forced into a custom tagging scenario. Folks will tell me ‘oh, get the cms correctly installed’ – right, ok – doesn’t work this way. Same thing would apply – as you say – that microformats or custom meta / dom data isn’t coded by developers in a well architected semantic manner. The more the production processes are automated, the easier this will be…

    Have a happy snowy NY Christmas from hot ‘n humid Singapore!

    Cheers, J

  • Emer Kirrane

    Hi Dennis,

    You’re right – this doubling up of information does cause a lot of pain in deployment.

    As Eric mentioned above, any page tagging can suffer from inconsistency. One example of the extra work caused by a lack of pedantry in HTML content is the page title tag. As you know, we (Yahoo! Web Analytics) use the HTML page title as the page name in reports in the UI. However, if that is missing/incorrect/generic etc, users implement the setDocumentName() method which is used instead. Seems like needless hassle really.

    Merry Holidays! :)


  • Dennis R. Mortensen

    Hi James,

    Great Omniture story, thanks for sharing, but also one which I honestly hope we’ll see repeated in an even more coordinated environment – AND I certainly agree that we (the web deployment engineers) ended up with a more rigorous install process that the CMS deployment engineers.

    >>The more the production processes are automated, the easier this will be…
    Agree. It would be somewhere in between great and fantastic if the Content Creators and the systems / processes they use did most, if not all, the tagging needed as they publish. This is not a utopia though.

    >>Have a happy snowy NY Christmas from hot ‘n humid Singapore!
    Damn you! I am knee deep in slush :-)


  • Dennis R. Mortensen

    Guten Tag Emer..

    I agree, even basic and traditional HTML tags could be utilized in a more automated fashion, traversing the DOM and concluding /suggesting on behalf of the client would not be a bad idea. I am however still a bit of a fan of letting the clients outline the semantic elements through Microformats – must be the nerd in me, who looks for structure. :-)

    Merry Christmas

  • Rudi Shumpert


    Great read and great comments above as well! I really like the idea of letting the clients outline the elements through the methods you suggest. I’ve done something similar with using jQuery to check for a specific class/id and add tagging on the fly. While this is not a universal tag solution it could be expanded.

    BTW. I’m enjoying your book that I got for Christmas!


  • Dennis R. Mortensen

    Hey Rudi,

    First. Very Merry Christmas. AND thank you so much for taking the time to read my book – really happy it time well spent.

    I like your jQuery idea, which is not far from what I am talking about – which is essentially stressing that the vendors execute in full on what you have started. Would love to see what you have done, if you would like to share..

    d. :-)

  • Rudi Shumpert


    I’d be happy to share the jQuery work. I have a very basic reference to it on my blog @ . The post references Omniture, but could be applied to any tool.

    I’ll put together a more detailed post on it soon!


  • Pingback: Web Analytics with Dennis Mortensen | The WordPress Podcast

  • Pingback: Web Analytics with Dennis Mortensen « WordPress Community Podcast - Online Radio - WebmasterRadio.FM

  • Pingback: Visitor Insights » What is Universal Tag? (part 4)