It has been a while since our last blog post. We’ve been busier than ever deploying the Universal Tag on client sites and I’m happy to say that the number of unique client deployments is approaching 50.
There’s more and more buzz around Universal Tagging every day and as a result, we’re getting the same questions from more people than ever: What is the Universal Tag?
In this multi-part series, we’re going to share our thoughts as to what the Universal Tag is and what it’s not.
In this post, we’re going to cover what we see as the first misconception about the Universal Tag.
Misconception: Universal Tag should be used by those that are in the process of switching vendors.
Fact: Based on two years of experience, we can categorically say that this is not the primary benefit that Universal Tag provides to clients.
Universal Tag is about fixing your current implementation.
That’s right. Out of almost 50 deployments of Universal Tag, only two clients have signed up in order to switch vendors. The large majority has no plan to switch vendors. Yet they recognize that their implementation can be vastly improved. Universal Tag provides them a platform to do just that.
The reason is because the Universal Tag provides a simplified platform for tagging compared to traditional vendor tags. It also changes the best practice implementation considerably. Today’s web analytics tools require you to think well in advance about the different types of reports that you want to get from the solution. Only after you have a good understanding of what your reporting needs are can you start the tagging process.
The Universal Tag framework changes this by letting you send generic data and map it to vendor-specific syntax at any time. This changes best practice implementations in that it lets you just send the data. The rest can be handled through the Universal Tag.
Here is a real-life example that helps demonstrate the point.
Example: Product Syntax
Consider a scenario of a product page. Within the page, you’d like to capture several components, including the product name, product size, color, and number of ratings received. As far as reporting is concerned, you’d like to get reports on top products viewed, top colors and sizes viewed, as well as average ratings of products (a numerical report) and a histogram or bar chart report of reviews (how many views for products with rating 1, rating 2, …).
Sounds simple, huh? Lets look at how you would go about implementing this with the two most popular tools on the market: Google Analytics and SiteCatalyst. The examples that we’ll use will be for a cotton shirt, color: white, size: large and a rating of 4.5.
First Google Analytics. We’re going to use custom variables to capture product name, size and color. The challenge here is that not only your developers have to know about the specific syntax, but they should also be aware of the fact that you can have visitor, visit or pageview-based custom variables. Now there’s no such thing as a numerical custom variable in Google Analytics, so you’ll have to use the event tracking feature in order to get your numerical ratings report. The implementation syntax will look something like this
pageTracker._setCustomVar(1,"product view","cotton shirt",3);
pageTracker._setCustomVar(2,"color","white",3);
pageTracker._setCustomVar(3,"size","large",3);
pageTracker._setCustomVar(4,"rating","4.5",3);
pageTrack._trackPageview();
...
pageTracker._trackEvent("product view","cotton shirt","rating","4.5");
Let’s try the same thing with SiteCatalyst. We’re going to assume that we’ll use prop1 and eVar1 for size, prop2 and eVar2 for color, prop3, and eVar3 for rating and event1 as the numerical event used to measure the average rating. The implementation syntax will look something like this:
s.events="event1,prodView";
s.products=";cotton shirt;;;event1=4.5;evar1=large|evar2=white|evar3=4.5";
s.prop1="large";
s.prop2="white";
s.prop3="4.5";
Again, you’re requiring your development team to know what different props, eVars and events are as well as the exact syntax which should be used (for example using lower case evar for merchandising).
Now let’s look at what this same implementation will look like with the Universal Tag. Here’s an example syntax:
yourdata.product="cotton shirt",
yourdata.size="large",
yourdata.color="white",
yourdata.rating="4.5",
yourdata.page_type="product view",
Now what if you wanted to deploy both SiteCatalyst & Google Analytics? No changes. The implementation will be the exact same.
This simplified implementation has several benefits. The one that’s clearly being addressed in this post is that it simplifies implementations and vastly reduces the deployment cycle. Your development team no longer has to master the analytics tool being used and can concentrate on sending the data through the simplified tag. Your business team or analytics department can then translate this data into vendor-specific syntax.
In future posts, we will share some of the other benefits that we’re seeing with the Universal Tag. Stay tuned.
Web analytics is an iterative process. A typical web analytics cycle is shown here. First, users deploy their web analytics tool. From there, they analyze the data, and make changes to their sites based on findings. The cycle then repeats itself. However, in some cases, the findings may require users to look at the data in a different angle. Often times, the new angle will require a change in web analytics implementation, which means re-tagging the site.