What is Universal Tag? (part 3)

In our previous posts, we talked about how the Universal Tag can simplify your web analytics implementation and improve the web analytics process. In this post, we’re going to discuss another key benefits associated with the Universal Tag:

Universal Tag is about preparing for the unknown.

Let’s face it. Implementations change because requirements change. Traditional web analytics deployments require you to know your requirements well in advance before you start tagging. Your reporting requirements (how you want to see the data) will dictate how you tag your analytics solution.

Want to see the impact of site search on cart activity? You’ll have to tag for it.
Want to see the number of times people view a product before placing it in cart? You’ll have to tag for it.
Want to see the effect of white paper downloads on lead conversions? You’ll have to tag for it.

This is costly. And what makes the process more cumbersome is the fact that requirements change. The change can be part of the evolutionary process associated with web analytics, or simply because of unexpected consequences of your implementation. In this post, we’re going to discuss what happened to a major consumer products company and how the Universal Tag saved them from re-tagging.

In this specific scenario, the company just launched a virtual world promoting many of their different brands. The virtual world is built completely in Flash and in order to track the effectiveness of the on-site promotional offers, the company decided to track the promotions as on-site campaign impressions. In other words, as a new offer (internal ad) appears on the screen, an impression tracking is sent to the web analytics tool.

This measurement framework allows the company to measure the click-through rate of the internal offers (since impressions are being tracked). However, it also results in an unexpected side effect.

Assuming that upon each offer, an impression request is sent to the analytics tool, what happens if the visitor leaves his/her computer while keeping the browser open (say heads out to lunch)?

This implementation will result in many extra unwanted calls being sent to the vendor, which results in both artificially high number of server calls (cost to the customer), as well as engagement metrics in the form of time spent on site.

With a traditional web analytics deployment, the client will have to go back to the web development team and to add a logic within the content management system that caps the number of ad impressions being sent. However, with a Universal Tag deployment, fixing this is simply a matter of adding a new plug-in to the Universal Tag library. The plug-in automatically cuts off requests after a defined number of impressions. The web development team or the agency does not have to change a thing and web analytics practitioners can be in total control of how the data is sent to the vendor.

Web analytics implementations are not always easy. Often times, as you’re getting into advanced implementations, there’s a chance that you’ll see unexpected behaviors or side effects from the implementation. With traditional deployments, these require a re-tagging exercise. The Universal Tag on the other hand lets you deploy once and fine tune without having to re-touch your page tags every time, hence preparing for the unknown.