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)
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.
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?