It has become increasingly common for websites to put all information for a product on a single page and deliver that information to the user in manageable chunks through JavaScript or CSS or some other web-devilry. This presents an Analytics conundrum for these sites, which many site owners won’t even bother themselves with.
But you might want to bother. Especially if you’re working on a new site—one which either hasn’t had Analytics turned on yet or hasn’t gathered a significant amount of data. So…
…what’s the deal?
The conundrum is how you will track user interaction with the page. Consider the following product page:
The page loads all of the product content but hides some from the user until he clicks on the “Specification” or “At A Glance” tabs. Doing so will result in the visible information pane being swapped for the other.
Analytically speaking, there are essentially two options when a user clicks a tab: track an Event or a Pageview. The reasoning behind using one or the other may not be apparent at first glance. And Event Tracking is normally used to log when the user interacts with a page element, such as a button or video. So…
…why track these interactions as Pageviews?
The greater part of the content of the page is changing whenever the user clicks on one of these tabs—beside an overview and specification page we might have a review tab or others depending on the site in question. The first point for Pageviews is that the user isn’t just interacting with a page element; he is effectively receiving and consuming new content.
The second point is the clincher for me, personally: think of all the useful metrics you get if you track Pageviews! You can see how long users spend looking at different information sets, or what they looked at last before they put the item in their cart. You can set goals based on Pageviews. An Event is just a click. Sure, I can get the number of clicks on each tab with Events, but what does that mean to me? Is that the actual metric, or is how much time is spent looking at reviews vs specifications more important? And of course I get those total clicks with Pageviews anyway. Traffic Generation Tips
Closing Thoughts
This Analytics strategy has provoked some debate around the office; whether or not it is right for your site really depends on the way you conceptualize your site’s content. I stand by my preference for the Virtual Pageview tracking method; a Pageview does not need to be defined by a request to the server!
The main concern, hinted at above, is that there will be some difficulties if you have been tracking analytics for a while: this change would significantly alter a lot of metrics that you might consider important internally. Weigh the benefits. Annotate your analytics to highlight the difference. If you want to maintain the integrity of your historical metrics, you may want to create a new profile for your site in Google Analytics. You can then filter your original profile so that it does not include the Virtual Pageviews. Your new profile won’t contain historical data, but it will start to collect your new Virtual Pageview data immediately. Or just create an advanced segment to see the data you need.
Wait! How do I…
Relax, if you’re worried about implementing this, it’s easy; we just drop a little onClick action into the <a> tags around the tabs:
<a onClick=”_gaq.push([‘trackPageview’,’/product-id/tab’]);”>
Of course, in this case we would need to replace ‘product-id’ with a reference to the product in question, and change ‘tab’ to indicate whether the <a> tag is referencing the ‘At A Glance’ or ‘Specification’ tab. Your site architecture may suggest a different URL structure. For more, check out Google’s description.
…and that’s all there is to it.