So far we’ve discussed using the Universal Tag to improve your implementation, achieve a better web analytics process and prepare for the unknown. But there’s another major benefit associated with the Universal Tag.
Universal Tag is about reducing redundancy.
The redundancy that we see typically comes in one of two forms:
- Redundancy associated with using multiple solutions
- Redundancy associated with data already available on the page
In this post, we’re going to discuss how Universal Tag can in fact reduce redundancy.
Redundancy Associated with Using Multiple Solutions
The trend that we’re clearly seeing today is that businesses are using more digital marketing tools than ever, which is resulting in more tags on web pages. For example, the home page of staples.com includes 7 different vendor tags. Many of the tags require their own set of variables to be declared, which results in redundant data. On this page alone, we see two different web analytics solutions: Omniture and Coremetrics.
Lets look at another example. This web site is using two different analytics solutions: HBX & SiteCatalyst. Both tags are collecting the same set of data, although the syntax may be different. If you were to look at the page weight associated with the HBX and SiteCatalyst tags on this page, you would end up with about 4 KB of added page weight per page. This is extra code on every single page.
For this same implementation, a Universal Tag page code will look something like this – which amounts to about 150 characters – a saving of about 4,000 bytes per page. To put this into perspective, for each 1 million page views per month, the bandwidth savings would be 3.7 GB/month, which is quite substantial.
<script src=”utag.loader.js”></script>
<script>
var utag_data={
page:”business”,
section:”business”,
segment:”business”
};
</script>
Compared to traditional analytics tagging, the Universal Tag offers several advantages:
- Simplified tagging
- Smaller page weight
- More flexible deployment
Redundancy Associated with Data Already Available on the Page
Often times, the data being passed to analytics solutions is already available on the page. Think about it. On a product page, you want to be able to capture the product name and attributes such as size, color, ratings, number of comments made, sku number, category, brand and other attributes. To demonstrate this, consider this example shown below of a product page.
The page itself includes just about all the information needed, including the product name, category, brand, rating, number of customer reviews, as well as the user status (“signed in” or “not signed in”). This is all information that’s useful for web analytics implementations. This information can be typically found in a number of ways, including:
- Parts of the page URL
- Query parameters within the page
- Meta tags on the page
- Microformats
- Other in-page elements such as h1 or other such tags
- Cookie values
The idea here is nothing new. See this great blog post by Dennis Mortensen from Yahoo! Web Analytics about the use of microformats for web analytics. The Tealium Universal tag fully supports the use of microformats, as well as other page elements mentioned above for data collection.
This approach creates a smaller footprint on the page, as well as lowers the deployment cycle. However, the approach also has some disadvantages. First, not everyone uses these elements consistently. For example, microformats are fairly new and there are a small number of sites using microformats today. Second, the approach directly ties web analytics deployment to the web design process which has its disadvantages. For example, what happens if you’re relying on tag IDs for web analytics and your design team redesigns the site? The dependence could break the web analytics deployment and is an extra checkpoint for your design team to consider.
In the end, you should pick the method that best works for you. However, it is important to note that whatever solution you end up selecting can fit your specific workflow.
