Tag: google analytics

This week I had the pleasure of presenting a workshop on Google Analytics at WPCampus in Buffalo, NY. One feature I demonstrated during the session was using content groupings to be able to better understand sections of your website as comparative units. After talking with some other folks, I decided that a more in depth discussion of this feature and some examples were warranted. So, here you go! Read More

On July 23rd, 2011, I had the pleasure of presenting at the HighEdWeb Arkansas regional conference. My topic was looking at approaching our websites through incremental realignments, rather than sweeping redesigns, and doing so based on information we can get from our analytics. A core component of that topic is using Google Analytics for event tracking on parts of your site. After talking with some folks post-presentation, it was clear a deeper look at event tracking was needed to show why it’s important and how to use it.

So, what is event tracking? Let’s let Google speak for themselves on the matter first:

Event Tracking is a method available in the ga.js tracking code that you can use to record user interaction with website elements, such as a Flash-driven menu system. This is accomplished by attaching the method call to the particular UI element you want to track. When used this way, all user activity on such elements is calculated and displayed as Events in the Analytics reporting interface. Additionally, pageview calculations are unaffected by user activity tracked using the Event Tracking method. Finally, Event Tracking employs an object-oriented model that you can use to collect and classify different types of interaction with your web page objects.

Crystal clear, right? In layman’s terms, while most normal stuff in GA lets you look at data at the page level, event tracking let’s you track things, components, and happeningson pages. This is extremely important when it comes to measuring the performance of tools on your site that don’t necessarily link to a new page, or that perhaps link to pages which you can’t track. For instance, want to track how many people click the play button on a video? How about tracking how many people open up your net cost calculator which you’ve put into a modal window? Or maybe you have links repeated on a page and you want to test them against each other (GA will treat these like one link in overlay mode if they have the same href). All of this is possible through the use of events.

Understanding the Function

First, let’s look at how you put event tracking to use. Basically, you’re going to tie a GA method to anything you want to track clicks for – the simplest way is through using the onclick attribute. The method in question is _trackEvent(). It is possible to call this on page load for global events, but if you are trying to track actions on the page, you’ll combine this with the _gaq.push() method (used for asynchronous tracking) in the following manner:

In this case, by changing up the action, I can track the same basic information as it is used in different manners, in this case folks who would prefer to print the document versus downloading a PDF version.

Other Uses

Trying to think of ways to use event tracking? Consider these.

Outbound Links

This can be especially useful if you currently don’t have a way to track people once they enter the funnel of your university application that might live on another server. By tossing event tracking on the link, you can at least see how many people are clicking to start an application, and compare that to the number of completed online apps to get your dropoff rate for the overall funnel. Likewise you can track clicks into any of your third party software platforms so you can get some idea of how frequently they are used.

This is a common question: “How do I track X, when X isn’t a webpage I can put analytics code on?” Normally, it’s asked in the case of PDF, Word document, and other types of downloads. GA is good for tracking web pages, but sometimes you want to track non-HTML page content. This is not the only way to do it, but is a useful and simple one.

Multimedia Interaction

Using a video player on your site? If you have a player, especially one that is non-YouTube, you might be lacking in information about how people use it. If your player supports callbacks on common actions like play, pause, and stop, you can tie in to those and pass it a function to note certain activities.

1

2

3

functionsendToGA(filename,playerAction){

_gaq.push(['_trackEvent','Videos',playerAction,filename]);

}

This assumes your player can send a string of its status along with the callback, something like ‘play,’ ‘paused,’ or ‘stop.’ The YouTube player can do this, as can most others. Then you can use the single callback function to track any player interaction. The same basic thing could be done for an audio player, or for photo galleries or slideshows.

jQuery

So far, most of the examples focused on links, but jQuery opens up the whole DOM to interactions. Here’s an obvious use to automatically apply a download action to any links that are PDFs:

Cool, right? Expand the idea, automatically track all external links, internal page anchors, or monitor modal popup windows. jQuery opens the world to you on your pages, and let’s you wire in to basically anything that the user is going to interact with.

In the Real World

So, how can you put this to use besides the obvious? That was part of what I talked about in Arkansas. For example, every part of our base templates is now set up with event tracking. This allows me to specifically watch the usage of our header and footer links across the site, and see where they are most frequently being used. In those cases, I use “Header Links” and “Footer Links” as categories, “Click” as the action, and the link text as the label.

Sample report showing events for header link clicks

In this case, you can see I added the Page dimension to the report so I not only see the event labels, but where they were triggered from. Using this, over time I can measure how people use things we’ve placed in our template, and make decisions on what to change and how to change it. For example, perhaps a particular link simply falls out of usage, or we place something with the idea that people wanted it, but it turns out no one uses it. Knowing that allows us to make educated decisions and gives us a baseline to compare against.

Similarly, I’ve done this with other static tools around the site. We had a box on our homepage that was being used for admission application links. A debate was taking place on whether that was really useful though. Looking at event clicks on them (note: we can’t track people once they enter the application itself, so I used this as a means to see who was trying to apply), we noticed a major gap between the number of clicks vs number of submitted apps. We saw at best 80% dropoff in the funnel (I can’t account for apps mailed in, or ones not initiated from the home page – so the actual funnel loss is likely into the 90% range).

So, we set about finding a better way to use the space. Rather than linking directly to the app, we decided to link to informational pages first, with the goal of helping people get comfortable with us first since a large part of the loss was likely because people clicked the links not expecting to immediately enter the application (gotta build those relationships first). The results based on watching event numbers spoke for themselves. Pages per visit were up about 2 for those users, time on site (compared to average) was way up, and general clickthroughs increased over 50%. Without event tracking, I would have never been able to identify the problem or measure the results of the change.

In Closing

Event tracking in Google Analytics can provide a critical extra layer of depth and perspective on your existing analytics. While most normal data addresses the question of where, events allow you to watch the what. This becomes more important as you try to help your site evolve intelligently over time, rather than dumping the whole thing every few years and starting over. Events also give you an added layer of flexibility in control what is tracked, and how that happens, to meet custom needs you might have for your site. Naturally, Google has a guide for implementing the event tracker that you might want to bookmark for future reference.

How many iPhones visited your site yesterday? Can you tell me? Could you get it set up if you needed to? At many universities, concerns about the usage of mobile devices (i.e. PDAs and smart phones) are increasing with respect to their web sites. Are they meeting the needs of the users? Can the users even get in to the pages in the first place? It’s a worthwhile question, and having become a recent inductee into the Cult of the Almighty iPhone myself, it quickly becomes apparent how crucial data tracking of mobile users can be. At first glance, there’s no easy way to extract that data from Google Analytics. In reality, there’s some in there, tucked away, just waiting for you to get at it.

Before I go too far, I will mention that if you have the money and desire, you can always go with a paid analytics solution like Amethon or Bango that has software set up to specifically track mobile users. It’s tailored and customized for exactly that purpose. I have not, however, used them, so I can’t actually testify as to the accuracy or quality of the results.

First, some harsh reality: Google sucks. I’m sorry, but they do. As far as generic JavaScript/cookie based analytics go, be it Google or someone else, they just aren’t that great at tracking mobile devices well. Bryson Meunier did a comparison of Google to Bango quite recently that showed a pretty stark 88% loss in tracking with Google. Was this a hardcore scientific study? No, but it certainly sets up an example of what you could possibly be missing. Greg Harris also tries to compare apples to apples with Mobilytics and Google, and describes the problems. But, my point isn’t to go spend a bunch of money on a tailored analytics package. You absolutely can get some valuable mobile traffic data from Google Analytics, and we’ll look at how.

What We Can Track

Mobile Browsers in Google Analytics

It’s important to note that Google Analytics can certainly track some mobile details with some consistency. Some of those that you should be able to specifically sort out are:

Safari / iPhone

Safari / SymbianOS

Mozilla / iPhone

SAMSUNG-SGH-I607 / Windows Mobile

HTC-8900 / Windows Mobile

Palm750 / Windows Mobile

HTC-8500 / Windows Mobile

SAMSUNG-SGH-I617 / Windows Mobile

HTC-8100 / Windows Mobile

Opera / SymbianOS

Vodafone / (not set)

HTCS620-Mozilla / Windows Mobile

PPC; 240×320; HTC_TyTN / Windows Mobile

many others…

Generally, smart phones from the past two years on have been getting better at executing JavaScript. As that rate increases, we should be able to see more of the OS/browser combinations becoming apparent. Obviously, if they can’t execute JavaScript, you can’t track them at all, and if they do it poorly, you may or may not get matches with the list above. Where Google is fairly successful, however, is tracking screen resolutions. Obviously your phone resolution is nowhere near your monitor’s, so with some filters and regular expression fun, we can narrow down our tracking with relative success.

Setting Up A Filter

Mobile Resolution Filter Setup

The fast answer is to just create a mobile traffic profile, and apply a filter to it. The iMedia Connection Blog has a handy regular expression for just this task. It recommends (^[1-2]?[0-9]?[0-9]|^3[0-1][0-9]|^320)x([1-3]?[0-9]?[0-9]$|4[0-7][0-9]$|480$). To get started, go to your Google Analytics page and click on Add Website Profile on your overview page. Name it whatever you like, like “Mobile Traffic Report,” and set it to Add a Profile for an existing domain. This sets the profile. Now, go back to the overview page and click the Edit link for the mobile profile on the right hand side. On the profile settings page, look around the middle for the Filters Applied to Profile section and click Add Filter. You can see the settings in the screen capture on the right. You want a custom include filter for a visitor’s screen resolution that matches the above regular expression. Then save changes and wait.

This filter should start matching any traffic coming from sources with a resolution of 320×480 or less. This will be regardless of the browser or operating system it may (or may not) be able to report on, allowing you to better capture traffic. You’ll also not accidentally capture some of those people still in the 640×480 dark ages, though you could miss some PDA traffic that has managed to get VGA resolution. This is where the rough edges start showing a little. Like I said at the start, Google Analytics is far from perfect on this.

There is an alternative mentioned at E-nor.com suggesting a similar filter, but using some of the identified phone operating systems instead. While it will work, keep in mind that this won’t pick up phones that don’t identify themselves. Plus, you’ll have to constantly keep up with adding new phones as they become available.

A third technique I’ve used with some success is setting up an exclude filter for visitor non-mobile web browsers matching the expression (Internet Explorer|Firefox|Safari|Chrome|Netscape|Opera|Mozilla (Compatible Agent)?|Camino|Konquerer|(Lynx ,)?gzip|Playstation 3). Though you have to be careful with this, because you risk excluding Mobile Opera and iPhone/iPod Touch users (I created this filter before those days, I’ve since switched to the screen resolution method). You could add some additional filters though that could make this work by testing the OS as well. Basically it’s operating on the principle that anything not matching the regular expression must be mobile. Again, you’re making some assumptions, and it’s one that’s bound to skew results higher than reality.

What To Do With This Data

Now that you’ve got a profile collecting your mobile traffic data, keep up with it. One of the first critical areas to address is where people are going. Try to address the top landing points, and maybe offer custom mobile versions, or make sure the key data on the pages is easy to get at, such as login links, news, and other resources. Maybe the numbers warrant putting forth the effort to write a mobile specific stylesheet. Also consider, if your programmers are considering publishing something like an iPhone application for your student portal system, it might be valuable to know if you even have any iPhone users on campus. In cases like that, you might be saving yourself a lot of work addressing a demand that isn’t really there (maybe you just have one or two very vocal, and perhaps annoying, users).

Likewise, you might be surprised by the amount of traffic you get from mobile devices, only to discover your site is practically unusable on phones. In that way, you can identify a major need and prioritize it accordingly. Know the technosphere your web site lives in, and make sure it is adapted properly for evolution and survival against potential competitors. If demand is outpacing your ability to supply proper support, you’re potentially losing opportunities to capitalize.

Also be sure that you know the problems that the data poses. It isn’t perfect, it’s analytics. In this case, it’s an even more rough approximation than normal, so if people start dissecting your data and picking apart figures, be prepared to cede the idea that you might not be able to wholly prove anything with absolute certainty. You simply can’t trust in a mobile device’s cookie and JavaScript handling to be bulletproof, so you’re not going to get perfect data. Not by a long shot, not with Google at least. The solutions offered here are just to get you started, so you can at least begin to gauge the scope of your situation, and start formulating some strategies with at least some kind of basis in reality.

We’re Rich, Have a Strategy, and Want Better Data!

Great, then don’t use Google, because odds are you’re going to be disappointed in the metrics. If you have the money, check out Mobilytics, Bango, comScore, or Amethon. These companies all take specific approaches to measuring people on those many tiny screened devices. One could hope that Google is able to step up and improve its system, but one of the main limitations is simply in the JavaScript nature of the tracking.

The takeaway is that mobile analytics tends to be neglected. Since so many of us use Google Analytics, we don’t have access to high quality metrics, and since the filters aren’t there out of the box, we don’t always jump right in and set up mobile profiles like we should. That leaves us missing out on a growing market segment. Additionally, mobile computing is like the new Internet Wild West, and it has a lot of challenges due to the decentralized technologies involved. It’s better to start facing some of them now, and leave yourself better able to evolve later, rather than finding yourself way behind scrambling to catch up.