May 03 12

Event Tracking vs. Virtual Pageviews

By

Straightforward page-tracking can be easily performed using Google Analytics, but what happens when we want to track more complex activities, such as watching a video, clicking on an external link, or switching between tabs on a single-page application?

Such activity tracking can be performed using one of the following two methods:

  • Event Tracking: By treating activities as events you can call _trackEvent every time your visitors perform something on your site that you want to track. Each event holds three basic attributes: category, action and label, which help you organize and manipulate the data collected by Google Analytics.
  • Virtual Pageviews: Using _trackPageview, you can send Google Analytics a pageview for each of the activities you want to capture. For example, if you want to track how many times your visitors watch a movie, you can capture the “Play” click and call _trackPageview every time a visitor clicks on it.

Until a while ago, it was inadvisable to choose event tracking, as goals could not be defined based on events. GA, luckily, amended this problem in one of its recent versions, so both methods can now be used to track activity, and can be compared.

In this post I will summarize the pros and cons of each method, as I see it.

Advantages of Event Tracking

  • Ease of use – You are required to send each event in a simple structure. Using three basic properties: category, action and label, you can describe each and every activity. For example, if a visitor plays the “Men in Black 3” trailer, the event sent should include the following information: Category:”Videos”; Action:”Play”; and Label:”Men in Black 3”.
    However, since the design model is highly flexible, you must prepare what you want to track, and how you want to track it, in advance. You have to make sure you know all the elements you want to track, define a clear naming convention and make sure all the relevant data is available in the event tracking reports.
  • Tracking Information – People often say that event tracking can track more details than page view tracking, but this is not actually true. You can track as much information as you wish using virtual pageviews. The problem is the results received are more complicated – which brings us back to the fact that event tracking is more simple, both to set up and to use.
  • Pageview CalculationsEvent tracking does not affect pageview calculations, which is an important factor in cases where an event should not be counted as a pageview. For example, if you have a page with several widgets and you want to track the amount of times each widget is displayed, it makes more sense to use events and not virtual pageviews.
  • Bounce rateNon-interaction events will not affect your bounce rate when using event tracking, as you can send events to the server without including them in the bounce rate calculation. One of the problems with virtual pageviews is the fact that any virtual pageview you fire will cause GA to treat that visit as a non-bounced visit. Therefore, if you have a page with several widgets and you want to track the amount of times each widget was displayed, your bounce rate will go down to zero when using virtual pageviews, since each visit to your page initiates one pageview for the page + additional pageview for each gadget on the page.

Advantages of Virtual Pageviews

  • Funnel StepsVirtual pageviews can be used as funnel steps. If for example, you have a lead form and you also want to track when the visitor first interacts with the form and when he/she submits the form – in addition to tracking the lead thank-you page – you should go with virtual pageviews. That way you will be able to define a funnel (with the goal being “Lead Created” and the prior steps being “Lead Interaction” and “Lead Submit”).
    With event tracking, however, you can only define the goal “Lead Created”, without the option to see the entire funnel (at least not through the Funnel Visualization Report). This is because Google Analytics lets you define goals by events but does not offer the option to define funnel steps by events.
  • It seems that the event tracking module is a separate and isolated module: It has its own set of reports but as with funnel steps (and goals, up until a few months ago), event tracking is missing in many important modules, such as real-time reports and visitor flow. In most cases, not showing events in the visitor or goal flow reports makes no sense.
    I must add that I have seen numerous web analytics tool that do provide both pageviews and events, yet for some reason they all lack synergy between the two.
  • Quality Assurance – QA and tackling issues are much easier to perform using pageviews. Let’s say you have created a goal based on a URL, but you do not see any conversions. When your events are simple page views, you can easily go to top content, visitor flow, etc. to see if the problem is related to the goal definition or if you have not actually sent the event correctly. Your virtual pageviews are also available in real-time reports, which makes your debugging process much easier (and faster).
  • Design Model – You can build your own model and store more information about each event using virtual pageviews and the API, which allows you to slice and dice your virtual pageviews any way you want.

So when should one be used and not the other? In my opinion, as long as event tracking is not supported by all Google Analytics features (especially real-time reports and visitor flow), virtual pageviews is usually preferable for tracking activities. However, I would choose events when what I want to track is not an activity, does not affect the bounce rate, and is not relevant to the visitor flow (such as the number of times a specific banner or widget appears on my site). In some cases, I will use both methods, that way, I will be able to see the whole funnel both on the event flow and the visitor flow reports.

Whichever method you choose, I do suggest you remember the following rule of thumb: Don’t let your site UI and technical implementation dictate your choice. The decision should definitely be based on your needs and not on the way your site is implemented. I’ll give some examples.

Let’s say you have a page that contains several videos. The user clicks on the “Play” button, and is then redirected to the video page, where the movie automatically begins. This is a simple case of having two pageviews: the homepage + the video page, and most likely, the video pageview will be defined as the “Play Video” goal. Chances are, you defined the video pageview as your goal without even think about using event tracking here.

Then one day, for any number of reasons, you decide to change the way your site works, and you arrange for the video to be played directly on the homepage. Now, instead of an additional pageview that is sent automatically, you will have to somehow notify Google Analytics about this activity (“Play Video”) . The question is will you use events to track it or will you send a virtual pageview (and simulate the original pageview that would have been sent)?

From the web analyst’s point of view, the fact that the video is now loaded on the same page should not affect your work or how you analyze the data. You will still want to see the “Play Video” event in the Visitor Flow Report and as steps in some of your goals, as prior to the change. Yet in many cases, the technical and UI implementation (i.e., playing the video on the same page) could lead you to choose otherwise.

Another example is when your UI team decide that a certain action should be performed using AJAX, without transferring the user to a different page or refreshing the page (table pagination, tabs navigation, etc.). Should the fact that your site is served from one URL with multiple AJAX calls change the way you track your users’ activity? When your visitor clicks the “Next” button to load 100 more rows, or clicks on a different tab, should you use events or virtual pageviews?

I hope I have given you some food for thought, and as both methods can be easily implemented, choose the one that most suits, based on the reports and metrics you need.

Follow

  • Niamh

    Hi

    Useful article : ). To eliminate the issue with Bounce using Virtual Pageviews I usually start all virtual pageviews with the term “virtual”. Then I can easily filter them out of one profile and maintain an accurate bounce rate.

    I am back using GA after a two year break (using Omniture). My dev team deployed a virtual pageview and it is showing up as having 100% bounce (which should never be the case). They tell me that the version of GA we are using means that the virtual pageview will overwrite the actual pageview. Never heard of this issue myself.

    Have you ever seen it? Appreciate your insight.
    Many thanks
    Niamh

    • Shay Sharon

      Hey,

      You are right about the bounce rate although it is not that easy (you will have to work with two separated profiles – one just for the bounce rate and the other for all the rest).

      Regarding the issue you’ve mentioned, I am not familiar with it. You see 100% bounce rate with more than 1 pages/visit? Sounds strange. If you want, send me the URL and I will look at it.

      Thanks,
      Shay

Subscribe for Our Latest SharePoint Analytics Updates

Signup to get the latest SharePoint Analytics posts straight to your inbox!