How to Collect Precision Data with Events and Virtual Page Views

Google Analytics’ “tag every page with this code” method omits a new user’s ability to track page activities that don’t necessarily navigate the user to a new page. Two of my favorite features that address the need to track such visits are Google Analytics Events and Virtual Page Views (VPVs), which allow you to get deeper insight into how users are navigating and ultimately using your website.

Virtual Page Views (VPVs)

Before we dive into some best practices, let’s define what a VPV is. On every page of your website the core function of the javascript snippet is to successfully fire the _trackPageview line of code. This little bit of code tells GA that a pageview has occurred and pushes out all sorts of information to Google’s reporting database. An underutilized feature of the _trackPageview is that it will actually accept manual data. Essentially you’re telling GA that a page was viewed even if it hasn’t, or even if it doesn’t exist for that matter.

By default the _trackPageview push automatically populates itself, in the event there are no arguments, with the URL of the website. For example if the _trackPageview fires on the page site.com/example/index.php it sends across “/example/index.php” which you’d see in your GA report. If you code in an argument to the page view such as, “/big/fat/lie.html” Google would be none the wiser. You would see in your content reports “/big/fat/lie.html” alongside all your other pages.

In your various reports this VPV would register just like any other page. You can fire as many or as few of these as you’d like in any area javascript can be utilized. You don’t have to fire just one page view per page, you can fire as many VPVs or legit page views as you’d like. The key item to note is: Google will treat a VPV just like any other page in your reports. Which means as an analyst its important to distinguish what pages are real and what pages are VPVs as they can artificially inflate your overall site pageviews, bounce rate, time on page, and any other page based data.

Events

Events are very  different from VPVs. As with any other GA function, they fire a snippet of code but the differences lie in two key areas: 1) they enable robust tracking of non-page changing interactions; and 2) you can tier classifications of events, which has huge benefits in post collection analysis.

Events have their own completely separate report outside the majority of reports which encompass your content pages. Since events accept more arguments at collection you have the ability to really drill down on a user’s action within your website. You can answer questions such as, “How far into the video did my users get? What videos did they watch? How many people made it to the end?”

Events vs VPV’s

When should you use Events or VPV’s? The simple but not so simple answer is this: it really depends on you want to view the data. One of the biggest advantages of using a VPV over an event is the ability to set up goal funneling. Event driven goals only allow you to trigger a conversion on a single event but it takes a lot more legwork to deduce the path. Creating a goal using a funnel with VPV’s in place gives you a cleaner goal funnel report.

As a general rule of thumb you should be utilizing VPV’s to emulate a user reaching a page such as a thank you page for an AJAX form, PDF link click, or a JQuery popup. An event should fire on an interaction that wouldn’t necessarily convey the wealth of information a page would. Events also have the added benefit of telling you what page they occur on. For example you may have the same video on several different pages of your website and it would be smart to understand what pages this video is most popular on. This would not be achievable with a VPV since according to Google the VPV is a page itself.

Here is my general rule of thumb: Use an event on a verb, or an action.  Use a VPV on a noun, or place. One final piece of advice is when creating VPV’s: stick with a normal URL structure such as “/big/fat/lie.htm”. Also, since these are not real page views in the common sense they can artificially pad your numbers. To keep track of what is a legit page view and what is a VPV you should always add /vpv/ as the subfolder. Adding this subfolder will allow you to easily filter VPVs out of a particular view if you need to, and make better sense of your content reports when hunting down popular pages.

How are Events and VPV’s going to help your data tracking and analysis?