Tag: Google Analytics

When to Use Events vs. Pageviews for Google Analytics

How to set up a schema for tracking certain things on a website is a polarizing topic. I’ve seen numerous schema that rely solely on pageviews to track everything—outbound link clicks, downloads, modal dialogs, etc—and the creator is dogmatic about the approach. But, semantically speaking, one of those three actions is a legitimate pageview; two aren’t. They’re events. I’m admittedly zealous when it comes to semantic use of Web technologies, but let’s face it: it makes for intelligent information architecture.

A good philosophy for tracking is: if new information is shown in the browser, at an address owned by you, it is a pageview. Everything else is an event.

Tracking link clicks

The short answer: tracking a link is tracking an event.

For instance, clicking on an outbound link does not result in a pageview for your website. Viewers are not looking at content on your site. Thus, an outbound link click is an event.

Clicking on a related link—such as to another similar blog post—is not a pageview, it is an event. The pageview itself will be tracked when the new page loads, but if you want to track the actual link click, you should register an event. Otherwise, you’ll be double tracking pageviews or tracking pageviews for a single page under multiple paths. Neither is ideal or desirable in an intelligent tracking schema.

Clicking a link that triggers a popup is covered in:

Tracking pop-up, modal, or ajax-inserted content

Are you tracking this based on link clicks? Why?

When tracking a popup, you should add tracking code to the popup file. The new window is a pageview. There’s no reason to track the link click as the pageview when you can add basic code to the popup and let Google handle it all.

For modal or ajax-inserted content, proper tracking means triggering a pageview when the content is shown. This is different from when the triggering link is clicked. Most plugins that allow modal dialogs or on-screen popups have an API that features some sort of onShow or afterRendering hook. This is the best place to put your pageview tracking. And yes, this is a pageview, because it is showing new content.

There are some cases where the link should be tracked, and those should be tracked as events. For instance, if you have a modal or popup contact form, you’ll want to track a pageview when the form is displayed, and an event to track which page the form is on or which link is used to display the form. Two different types of tracking that happen at two different (but very close together) points in the interaction.

The tricky case of PDF documents

PDF documents are one case where I entertain either option, but that is because there are two possible ways that PDFs extend the website: as downloadable content or as browser-viewable content. Older browsers and the default installation of Firefox treat PDFs as downloads. They are not displayed in-browser. Thus, under my definition of a pageview, clicking on a PDF link is an event. Think of it this way: we know that the user clicked the link, but we can’t be sure that the user actually downloaded or opened the document, so there’s no empirical evidence that there was a pageview.

However, modern browsers like Safari and Chrome, and certain mobile platforms will open PDF files seamlessly. In that case, for most intents and purposes, clicking a link results in a definite pageview.

Example cases:

Server forces PDF download, will not serve in browser
Event. There is no possibility the page is viewed in the browser. Any content is downloadable, not viewable.
PDF is provided because resources/desire/ability to convert to Web are not available, but is considered Web content
Pageview. There is a possibility that the page will be viewed in the browser, and that is the intended functionality anyway.
File is of a form or tutorial intended for printing
Event. The intent is not to view the content, but to provide a format for printing and interacting with outside of the Web. This is not pageview content.

In most situations where I’ve implemented tracking for PDFs, their use has fallen under the event philosophy, but I do see instances where a pageview does make sense.

How do you make decisions about pageviews or events? How do you use the resulting data?

This post follows , a post about debugging your events and pageview code. I hope to follow this with a tutorial about implementing JavaScript for this tracking.

How to Check If Google Analytics Click Tracking is Triggered

When I add new Event or PageView tracking code that is bound to click events, I want to be sure that the tracking code is fired without waiting for a site visitor to trigger it (or in some cases before the code is even on a live page). Because my own traffic is filtered out of all of my Google Analytics reports, I can’t rely on my clicks to show in my reports (not to mention the delay). But, even with the filter in place, the clicks are sent to Google, and I can check to be sure they’re sending the right information in Firefox using Firebug’s Net panel. Here’s how.

Enable the Net tab

If you don’t already have Firebug installed in Firefox, get it, because you need it for this.

Once it’s installed, enable the Net panel.

Load the page you want to test. Once you do, you’ll see a lot of stuff pop up in the Firebug Net panel. One of my posts looks something like:

Look for the PageView

Once you have enabled the Net panel, you can see if your Google code triggers the initial pageview. Look through the requests for one that starts with _utm.gif?. Expand it by clicking on the arrow to the left of it.

Looking at the params tab (it defaults to headers), you can see the information being passed to Google. The first line is your unique tracking ID. You’ll also see your page title, the domain, and most importantly, the URL being passed.

If you don’t find the _utm.gif? entry, something is wrong with your basic GA tracking code and no data is being sent to Google.

Trigger your event or new pageview and find the tracking info

After verifying that the GA code is tracking the pageview, you can see if your click event code is working. To do so, trigger an event that you’ve attached tracking code to. In my screenshot, I open an external link, which I’ve coded to trigger a GA event. It’s important that if you are triggering a link to a new page that you open it in a new tab or window so that your Firebug Net panel still tracks the original page.

A new _utm.gif? line should show up in the Net panel. Expand this new tab. If you triggered another pageview, the params will look similar to those mentioned earlier. Events look a bit different.

Click to view larger version

The important field here is utme, which shows the information you passed in the _trackEvent call. The arguments you passed to _trackEvent are separated by asterisks. Mine reads Outbound Link*us.php.net/strtotime*Why is date() returning 12/31/1969. This is because I track my outbound links under the category Outbound Link, with the external URL as the action and the h1 text on the page the call was triggered from as the label.

Yours will likely differ depending on your schema for event tracking.

Again, if you don’t find this new _utm.gif? call in the Net panel, your click event code isn’t running, or the GA _trackEvent/_trackPageview code is set up incorrectly. You’ll need to debug it, then check again.

Now you know how to check if your code is working. What do you use Google Event or Pageview tracking for?