However, this philosophy comes at a price. Because it indiscriminately accepts any data it’s given, it accepts any data it’s given. The result is that, if someone with the right skills is feeling particularly malicious, they can vandalize and seriously distort your business’ data. There are two ways this can be done.

We’ve been aware of these potential issues for some time now, but we wrestled a bit with the decision of whether or not to post this. On one hand, we like to share our knowledge and, since this is a very real fact about Google Analytics, it’s good for GA users to be aware of it. On the other hand, we’re potentially teaching people how to mess with someone’s GA deployment. Ultimately we decided on transparency and honesty — after all, we’re also going to tell you what you can do to protect yourself from these. But we must begin with a caveat: we do not endorse doing anything like this. We offer this information so you can be aware of potential security risks with your own data, and take the necessary steps to protect your data integrity.  We are strong supporters of the Web Analyst’s Code of Ethics, and though that code doesn’t say much about messing with others’ data, the idea is generally to be open and honest with data.

(Update: I should also point out that Google Analytics is not alone in being vulnerable to some of this. The approach to campaigns and ease of copying other data makes it easier than with some tools, I think, but those stem from Google’s strengths rather than weakness. I offer Google Analytics up because they don’t have a service level agreement for everyone, and hence it’s up to you to protect some of your data. Despite any vulnerability, I do want to be clear that Google Analytics is a fine tool and this alone is not cause for alarm, just something to be aware of when implementing this tool, and by extension, others like it.)

With that out of the way, here are the potential exploits we’ve seen:

Campaign Vandalism

Google Analytics makes campaigns tracking easy. Unlike tools like Adobe SiteCatalyst which store campaign tracking codes and convert them into useful data, Google Analytics sets campaign names directly in the URL query parameters, accepting any campaign name that it receives. This saves you time managing all your campaigns and channels, and makes setting up Google Analytics significantly faster. But with GA merely accepting any campaign names it gets, what’s to stop me from visiting your site using a bogus campaign name?

What’s the problem?

Campaigns in Google Analytics work by adding the names of campaigns, media and sources to URLs. For instance, if you want to track a summer email campaign that links to www.example.com, you may enter a URL like this:

In this example, you’re pushing though three pieces of information: the source of your list (newsletter), the medium over which you’re marketing (email) and the name of the individual campaign (SummerBlast). This data will be recorded in Google Analytics, no questions asked. You don’t even have to tell Google about the campaign ahead of time.

But what’s to stop me from visiting your site on this URL?

The answer is nothing. If I were to visit a GA-tracked website with those query parameters attached, their Google Analytics implementation would show that someone came to their site magically, by means of a spaceship, through a campaign called Stupidhead. I did this to one of my own sites, and here’s what I got.

How dangerous is it?

The most someone can do is create a bunch of meaningless data. The effect of a single vandal acting alone would be minimal, though an extremely determined vandal could set up a sort of vandalism bot — an automated software that repeatedly visits your website using falsified campaign data.

If you’re smart about your reporting, you’re probably more concerned about your converting campaigns. In order for vandals to mess with those reports, they’d have to become converting visitors. They may not have a problem with filling out a lead generation form, but if you are running an ecommerce site, these reports have a built-in protection: vandals will have to pay for the opportunity to seriously mess up your reports. (However, you’ll still need to account for the second scenario below.)

How do you fix it?

The first step is to identify vandalism. Chances are, it will be obvious — if someone has decided to vandalize your site, it’s probably because they want you to see it. So a bogus campaign name that shows up in your reports will be clear. If you’ve been smart about maintaining a convention for your campaign naming, you should have an easier time detecting falsified campaign information, though a determined vandal could spoof your own conventions.

Getting rid of the campaign data isn’t as easy. In fact, it’s impossible. What you can do instead is segment it out, so that you see only data from non-vandals. To do this, you need to create an advanced segment. Creating a new custom segment (using the ‘Advanced Segments’ area at the top of a report in the new Google Analytics interface), you can choose to exclude campaigns, media or sources that contain the offending terms.

The problem here is that if you’re the victim of serious vandalism, such as from the bot scenario given above, you have to use this segment every time you look at a report in Google Analytics. That’s a pain.

If you’re a large organization and you’re afraid of receiving an attack to your Google Analytics account, you may consider running more than one analytics solution, or copying the relevant data to your own datamart. The larger you are financially, the more likely such an attack is, but the more resources you’ll have to back-up your data.

What should Google do?

Probably nothing. I think that the fact that you don’t have to do campaign management within Google Analytics is a plus. It cuts down the overhead — every organization should have some method to the madness of creating campaigns and campaign names, but the extra work of punching data into your web analytics tool isn’t always worth the benefit, especially for smaller organizations.

Given the fact that traffic has to convert, and actually spend money if you’re an ecommerce site, in order to mess with valuable reports. If someone really wanted to hit your site hard with this, the most they could do is become a nuisance. It won’t destroy your reporting, but it will make it harder to pull clean data.

However, since Google is gradually approaching the enterprise market with its Analytics product,  its product team may consider providing two options for campaign management: both the current consume-everything version, and an internally-managed campaign list in the style of SiteCatalyst. The benefit would be for large customers, who have the resources to properly manage their campaigns, to be able to do so risk-free.

Fake Data Injection

Ok, so, if I want to, I can mess up the campaign data a bit. And if I want to mess up your revenue sources, then at least I have to pay you for the opportunity to do so, and it may not be so bad.  But what if I want to mess up the rest of your data? Surely, I wouldn’t be able to do that, right?

Wrong. Unless you’ve set up filters to prevent this, Google Analytics will accept data for your Google Analytics tracking account from any server, as long as it sends the web property ID for your website.

What’s the problem?

Because Google Analytics accepts this data from anywhere, anyone can create a web page using your Google Analytics tracking code, view it, and have traffic, events or ecommerce data show up in your Google Analytics report.

For example, what happens to your reports if I create a fake transaction, using your Google Analytics tracking code, with a transaction of -$90 million? Here’s what happens:

The other days in that report aren’t at zero dollars. They range from $50,000 – $100,000, but you can’t see the trends because the fake transaction has skewed everything.

How dangerous is it?

The damage here is greater, in that it will severely distort any reports. Someone could take an obvious step, like the above examples, of pushing huge transactions into your Google Analytics account. However, the vandalism could be more subtle: one could push several smaller transactions with false source data to try and misguide you, or push events that you can’t reconcile with your order management system.

The effect of this and the campaign vandalism method I mentioned above can be compounded. Recall that you’d have to buy something to mess with revenue source data with the method above? It turns out that, if you fake realistic-looking transactions while using spoofed campaigns, you can make an even bigger mess of things.

One limiting factor here is that the visits have to be run from a server that’s connected to the Internet and can host web pages. As a result, you can use the Hostnames report in Google Analytics to identify where the fake data came from. This does mean that if someone wishes to vandalize your data in this way, they will have to do so carefully, otherwise they may be identifiable. Potential vandals would have to go to greater lengths to ensure their anonymity.

How do you fix it?

Finding the fake data could be tricky. In the case of revenue and transaction data, you probably have an order management system with which you can compare the data. However, when you’re strictly looking at Google Analytics, the fake data may not be obvious if the vandal has chosen to be sneaky about it. The first step is to check your Hostnames report. Hostnames are the domain names or IP addresses from which your website is viewed. In the new Google Analytics, you can find the list of hostnames that have been used to view your site from the Visitors > Technology > Network report.

If Google Analytics code executes on hostnames that you don’t own, you’ll want to investigate the problem. In some cases, those hostnames will simply be search engine caches or translation services that are copying your analytics code. However, if you notice transactions or strange events and campaign data from suspicious hostnames, then you may want to look into the matter.

There are a couple of ways to actually fix the problem. The first is an ad hoc approach — if someone drops a fake transaction into your system, simply remove it by executing some JavaScript. This requires you to write a custom JavaScript that basically makes an inverted version of the transaction, with negated quantity, revenue, shipping and tax values. This is annoying, but quick enough to get rid of a single transaction.  You can also handle it the way I suggested handling vandalized campaigns above, using custom segmentation.

However, if you want to prevent yourself from these attacks entirely, then you’ll need to add some filters to your Google Analytics profiles (or create new filtered versions of your main profiles). The goal here would be to create a list of hostnames — the domain names and subdomains that you use for your website — and ONLY accept data from those hosts. Now, you’ll probably want to set up your filters on a new profile, which is a filtered version of your original. That way, you have 100% of the data collected by your site, but also a clean/safe copy to work with.

The example filter I’ve given here will only count traffic, events and transactions from the domain name ‘example.com’. A better way might be to only include traffic from specific IP addresses, if you know the IP addresses of your website(s)–this could prevent attempts to spoof your hostname and push vandalism that appears to be legitimate. In either case, be sure to keep this up-to-date! If you change your domains, subdomains or IP addresses, it may affect your filtered profile and cut out some legitimate, valuable data.

One quick note: Sometimes you’ll see additional domains in your list that are from hostnames that have a legitimate purpose. For instance, Google will serve up your site when it shows either a cached version or a translated version — in both cases, the hostname includes ‘googleusercontent.com’. Bing also shows page caching on cc.bingj.com. You may want to exclude data from caches or translated versions of your pages, but if you’d prefer to see all of it, include data from those domains as well.

What should Google do?

Google should provide these filters as standard options. You should be able, when creating a profile in Google Analytics, to specifiy what host names and/or IP addresses you’re willing to accept data from, and be able to provide an on/off switch for accepting data from other sources. Making this option more prominent may help businesses be aware of the issue and protect themselves from day one.

The are more technically complex, and secure, methods of limiting these kinds of problem that Google could consider. One option is to make use of server-side code in conjunction with the JavaScript to authenticate an API key before data is accepted.

At any rate, rumblings of a paid, enterprise-focused Google Analytics can be heard from the horizon. If a service level agreement becomes available to some Google Analytics customers, data integrity and security will be chief concerns.

Until next time,

Colin

UPDATE: Just a quick note of clarification. Although I focused this post on Google Analytics, I should clarify that GA is not the only tool vulnerable to this — especially the second method of vandalism. The first method is the easiest thing, and that’s more specific to GA. This post came out of an internal discussion about the campaign vandalism. To be clear, this kind of thing isn’t particularly common, and as Emer mentions in a comment below, it tends to be a result of negligence when people copy code or designs, rather than a malicious attempt. So, there’s no need for immediate concern for most people, but I think it’s worth being aware of what you can do to protect yourself from this inherent vulnerability in most analytics tools.

The method of tracking for LinkedIn buttons differs a little bit from the others I’ve posted so far. Currently, LinkedIn does not provide a callback function that executes when an action is completed — there’s no flag in the code that says “visitor shared something, now what?”. Instead, we have to build our own JavaScript function that we can bind to an action. In order to do so, this example uses jQuery, a popular JavaScript library.

The first step is to get your button code snippet from LinkedIn. LinkedIn calls this service LinkedIn for Publishers. When you generate the code, it will look something like this:

This script from LinkedIn above generates new HTML which is inserted into the page in order to create the ‘Share’ button and its functionality. The code generated includes a new <div> element, which has the class name IN-widget.

This gives us the chance to reference the generated button with a little code of our own. Using the jQuery .ready event handler — to ensure that the code does not execute until LinkedIn is finished building the button — we construct a new function that binds to the “click” event for all objects with the class name ‘IN-widget‘. In this function, we include the Google Analytics social tracking code, to create a new social event.

This new code can be added pretty much anywhere on your page — you may want to include it right after the code LinkedIn gives you to keep them together, or put it in your header if that’s how you prefer to organize your site.

Note that in this example, the last parameter, window.location.href, will send the current URL along as the resource shared. In different systems, you may prefer to output the URL directly, rather than through JavaScript. For instance, in WordPress, you may replace the last parameter with the permalink for a post:

Now, there is one issue which must be kept in mind. In the case of the Facebook and Google +1 buttons I’ve previously shared, the social event code only fires after something has been shared. That’s the benefit of the callback function provided by those services. In the case of LinkedIn, however, what we’re really tracking are clicks to the share button — it’s possible for someone to cancel sharing after clicking the button, so you may get an inflated total.

With that caveat in mind, you’re all set! Once you’ve added this JavaScript, your LinkedIn shares will appear in the new social reports in Google Analytics. You can find these reports under “Visitors > Social” in the new version of GA. With this, your web analyst can help you determine what impact these buttons have on your site and your business. For instance, whether frequently-shared articles get much more converting traffic from LinkedIn, and whether the people who share things are also the people who convert themselves.

Until next time,

Colin

Everything that happens on a website is an event.

We’re in a strange place with this ‘events’ business in web analytics right now. Event tracking is still relatively new and many are only now really discovering them. The events paradigm allows you to track activities that were previously outside the realm of measurement by firing off a JavaScript codes that say, “hey, something happened!”.

This leads us into a bit of misunderstanding. Traditionally, web analytics involved looking at page views. Some page views were boring. Other page views were conversions. Some other page views were somewhere in between, part of a conversion funnel. Web analytics tools became much more relevant when they started tracking ecommerce conversions, so you could see how much money was being made. So far, so good.

Events showed up, in part, to respond to the technological development of the web. Suddenly, important stages of that funnel were no longer page views. With methods like AJAX, some sites suddenly had their entire shopping cart process happen on one page, with each step loading within the page. Page views don’t tell you what happened there, so event tracking came to the rescue in order to track these new “events” alongside your traffic and transactions.

What event tracking highlights is not that there was good tracking and then new technologies broke it. What it shows instead is that the older way of doing things was broken. It tracked only one kind of event: page views. Sometimes, it tracked two: page views and transactions. Good. Not good enough.

Page views are events. Transactions are events. Clicks are events. Chat interactions are events. Searches are events. Customer reviews are events. You get the idea: everything that happens on a website is an event. It’s not that these new event things are an addition to what’s there, it’s that the old way of tracking interaction on a website is incomplete. It forced you into one or two types of event, and ignored the rest.

What Google Analytics, Yahoo! Web Analytics, Adobe SiteCatalyst and other tools are now doing, which needs to be done, is allowing you to determine, as an organization, what kinds of events are happening on your website and which ones are relevant to a conversion.

Everything that happens on a website can be tracked.

At Napkyn, we don’t really do implementations, almost as a rule. Our focus is on helping our clients expand the value of their sites. If we sold developer time, we’d be focused too much on building implementation frameworks and running up project hours, which isn’t valuable. But we do review our clients’ implementations and make our recommendations about what else should be tracked — what data we need to tell them how to grow their online business.

When we make these recommendations to clients, more often than not, the answer is something like, “wow, you can really track that?” Sometimes that sparks a further list of, “what about this, and this, and this?! Can you track these?” The answer to those questions, 95% of the time, is “yes, we can track that.”

Strictly speaking, any user interaction on a website can be tracked. This includes anything that’s clicked on, moused over, spoken with. I say, “strictly speaking”, because the things we can’t track are the little bits that aren’t on the website itself. Obviously, things like whether the planes are on schedule at O’Hare and whether or not it’s raining in Fiji are off-limits for a web analytics tool, unless you happen to be the O’Hare airport or a news outlet in Fiji. Less obviously, things that are contained within iframes (small windows within a site that load in content from another site) as well as some externally-hosted JavaScript applications can’t be tracked by the page they’re on.   This includes some versions of Facebook Like buttons and other social media sharing icons.

Everything that happens on a website should be tracked.

That claim goes beyond my analyst’s desire to have the whole picture, to sift through every bit of data I can to get killer insights. This isn’t a quest to know everything about everyone who browses a website. This is about knowing how valuable each ingredient is. You don’t want useless clutter, but you don’t want to throw out anything good. So, we need data to determine the value of every interactive piece of a website.

So, everything on your site should be worth tracking. The reasoning is simple: If there’s something on your site that’s not worth tracking, it’s not worth having on your site.

Of course, you have to prioritize what tracking you’ll add first. If you’re missing it, the first things you should track are your macro conversions – the ultimate goals of your website: Sales. Lead forms. Donations. This will depend on what your site is about, but you get the idea. This is crucial, and web analytics is next to useless without it.

Next up, track your micro conversions — conversion-related events that drive towards a conversion. An add-to-cart button is a micro conversion. We can argue about semantics, but I count things like newsletter sign-ups as micro conversions. They’re not the goal of the site, but they get you something valuable: permission to market to someone later.

Engagement events are third on my list. Some others, like Avinash Kaushik, count these as micro conversions. This is all semantics, of course, but I like to, at a higher level, differentiate between events that are and are not driving someone towards being a customer. Signing up for marketing emails does that. Adding a product to a cart does that. Clicking a Facebook “Like” button does not. These events may still be valuable and certainly show that the visitor is engaged in your website, but they don’t directly help that visitor become a customer. Other examples include filling out a feedback form or commenting on your blog.

Anything outside of that is noise. External links on your blog? Noise. Social media links that take people away from a product page and towards Facebook, Twitter, etc.? Noise. (Yes: That someone “liked” a product page without leaving it is valuable. That someone left your conversion-focused site to look at your Facebook page is noise.) Should you track noise? Sure! After all, if you can prove that a feature is useless or even hurting conversions, then you have a case to rid yourself of it. On the other hand, you may be surprised by what the data tells you — after all, if intuition were perfect, we analysts wouldn’t have jobs.

You won’t look at all of this at once, and this isn’t data for executives. Executives are already drowning in metrics — this is data that should be at the ready for analysts when hard questions come up. And when the time comes around to make iterative changes or a full redesign, it’s extremely valuable to be able to see what role each component of your website plays in the overall visitor experience, and most importantly, converting traffic into business.

When such a time comes, you’ll be thankful that your web analyst has the data at hand to answer those questions. And if you can get your head out of the traditional page-views–centric approach, you’ll stop worrying about what you can track and start thinking about where your next revenue lift should come from.

Until next time,

Colin

We’re well into 2011 and coming up to the end of the fiscal year for many businesses. With pressure to plan out the next 12 months in order to continually grow, many of our clients are looking to refresh or relaunch their websites. (We’re looking at doing the same ourselves–we’re doing some cool new things that we’d like to brag about!)

As web analysts, we’ll be the first to tell you that updating a site’s design won’t immediately equal performance improvement. Without planning, it can easily go either way: a relaunch can offer major improvement to your revenue performance, but it can also kill your traffic, and even with an amazing conversion rate, fewer visitors means fewer visitors to convert.

So, here’s the checklist:

1. Look at the data

Obviously, as web analysts, this is near and dear to us at Napkyn. But it’s something every business should do when making changes to their marketing efforts. You essentially have two options when deciding what sorts of changes you make to your website. You can:

1. guess, or
2. know.

If you guess, you could throw out the best-converting pieces of your website. Worst case scenario: your business fails entirely. Looking at your current data will let you know which parts of your site are working, and which aren’t. Worst case scenario: You do as well as you did before.

Everybody wants a sexy brand and that’s not a bad thing, but good design is not success. I’ve seen beautiful sites fail and ugly sites make millions. At the end of the day, you probably want changes that make you more money. Look at your data to get insights on what works well for your business and compare it to others’ data and best practices to get a sense for what has worked before.

Of course, not everyone has a head for this stuff, so if you’re not sure about how to move from guess to know, we can help with that.

2. Manage your URLs

Next up, a tactical tip. If at all possible, try to minimize the changes to your URL structure. Keep in mind that search engines don’t index websites, but rather web pages — and they do this by the URL. Every URL that you remove from your site is a page lost from Google’s index. Chances are good that you remember from when you first set up your website, getting good rankings can take a while. You don’t want to risk having to start over. The number one cause of lost traffic after a site relaunch is almost always a drop in search traffic.

There are some cases where keeping your URL structure is not possible. This can happen because you change content management systems or ecommerce software vendors, and the old structure simply isn’t possible in the new software. Many good systems allow you to set the rules for how URLs are generated, but sometimes this isn’t available. Fair enough.

If your redirects look like this, you’re doing it wrong. Go for a seamless HTTP 301 redirect.

What you’ll need to do is make sure that every URL on your site still goes somewhere. The best way to do this is with an HTTP redirect — specifically, using the HTTP 301 “Moved Permanently” code. This is a message that is sent by your server to a browser, search engine or any other device that visits your site, and tells them that a page moved, and where it went. Other methods, such as meta refreshes and other HTTP redirects are not as effective in keeping search engine listings, so be sure to use this one whenever possible.

If at all possible, configure your server with a listing of all of your old URLs and their new locations. That way, specific product listings, articles or other pages aren’t lost. If you’re raking well in Google for selling blue widgets, don’t redirect your old blue widgets page to your homepage — point it to your new blue widgets page. This will make sure that your search rankings, incoming links, shopping feed listings and bookmarks are all preserved, and will help potential customers find what they’re looking for.

A new website almost always means a change in search traffic. This will help you minimize the risk of a natural search free-fall.

3. Keep your customers in the loop

If your business has tends to bring customers back for more, or you have prominent customer login or customer service  areas of your site, you want to be sure that you don’t alienate them with your new changes.

In customer service areas, inform customers early that the site will be re-launching soon. If you rely on customer involvement with your site, pull a Twitter and let them test the new interface with an option to switch back for now. If that’s not a viable option, provide linked messages to customers like this: “Looking for your order history? Our new site files orders right in your user profile.”

This is relevant to my next point, preparing to measure the results. An increase in page views (relative to visits) isn’t always a good thing when you relaunch a site. Often it’s a sign of existing customers or visitors familiar with your site who get lost in your site. Visitors who are already familiar with your site may be looking for something in particular, and if it’s moved, they can become frustrated.

4. Get ready to measure the switch

If you followed item #1, then you’re making these changes for a reason. Don’t forget to close the loop, either — you need to define the metrics that will determine whether or not this change was a good one. How will you know that you’ve won? Make sure that you’re prepared to handle, and try to make predictions about how the flow of traffic.

Then, once your new site has been online for a while, you’ll be able to compare the data against the plan, and learn whether or not the changes you made had the intended impact.

The technical side to this involves making sure that you actually can measure the change with some confidence. If you’re making significant changes to the deployment of your web analytcs tool, you’ll want to be sure that you’re not comparing apples to oranges with this change. If you’re switching tools, try running them concurrently for a time to be sure that they’re on the same page.

5. Develop a testing plan

Even the brightest marketing minds don’t get everything right the first time. Your new website may be miles ahead of your old one, but without data on its performance it’s tough to be certain how it will fare. So, once your new site is launched, you’re not done.

When measuring the switch (item 4 on our checklist), you’ll probably notice a few areas that don’t do quite as well as they did before, or didn’t improve as much as the rest of the site. These may be individual products or product categories that perform differently, or specific traffic sources that react differently to your site.

Identifying the less-successful areas of your redesign early gives you an opportunity to ensure that you continue to make the proper revisions. Start testing areas of your redesign by using A/B or multivariate testing tools. If you had two competing layouts for a new page on your site, test both! Sometimes the results will confirm your intuition, other times they will surprise you.

6. Think of everything

Easier said than done to be sure, so that’s a joke. But if you’re tracking your business through high-level metrics, you’re better equipped to understand where major changes fit in and how to avoid missteps. As web analysts, our job is to make the big numbers bigger, so when you’re clear about high-level business performance, the tactical stuff falls into place.

This list isn’t exhaustive, but following these guidelines can help you make informed decisions around your relaunch, and prevent you from throwing out the things that work.

Enter jQuery. If you’re a web developer and you haven’t taken jQuery out for a spin yet, then you need to do a little reading. Among jQuery’s many features is its ability to easily select any element on an HTML page from your JavaScript code, and then manipulate or watch that element.

Watch it like a hawk.

The advantage for event tracking? You can neatly organize your event tracking codes, putting them all in one place — in your header or an external JavaScript file — rather than littered throughout your code. It makes tracking your tracking easy, and it can even speed up the deployment of powerful event tracking codes.

Let’s look at a quick example. Suppose that I have a link on my site, and every time that link is clicked, I’m tracking it as an event in Google Analytics. My code may look something like this:

Clean it up with jQuery
The details of the link aren’t important, but essentially I’m tracking clicks on external links, in this case one that goes out to Google Canada. Here, I’m using the onclick attribute to assign the action to the link. What jQuery lets me do is move that out of the link. I can replace the JavaScript with an ID in my link:

And then move the tracking code to a <script> area in my header:

What we’ve done is created a function that will execute on $(document).ready, which is a jQuery handler for the moment that the DOM — the set of objects on the page — is fully loaded and ready for manipulation by JavaScript. We then create another function that is bound to the click event of the link we created, which we reference by its ID, GoogleOut. The selector style is the same as CSS: we use the ‘#’ symbol for IDs, and the dot ‘.’ for classes.

One code for multiple events
Now, we have the advantage of moving all of our event tracking code to this same $(document).ready function, listing them one after another. That helps with the managability, but we still have to set up IDs for each link. What if we have several external links on a page? It would be as tedious to give them each an ID as it would to manage all of the onclicks.

For this, we can use jQuery’s ability to not only select multiple elements on a page, but gain access to individual elements. First, let’s change our link code. Rather than give it an unique ID, let’s give it a class name, “external”, which can be used for all of the external links on our site.

Next, let’s modify our code to select all external links, instead of just our Google one.

You’ll notice that not only did I change the selector to 'a.external', but I changed the last parameter of the Google Analytics event tracking code to $(this).attr('href'). In my original code, I had written in ‘google.ca’ so that we would see in the Google Analytics reports that the click out was on the link to Google, specifically. Now, I want to track all external links on my site, not just to Google.

In this case, I’ve used jQuery code to select the href attribute (using the .attr() method) of whatever link was clicked (which we specify by $(this)). The href attribute, of course, contains the URL of the link. So, not only does this code now track my link to Google, but it will track each and every external link on my website, as long as I tag them with the external class name, and tell me which external links have been clicked.

By now the power of jQuery for event tracking should be clear — not only can you use it to clean up your code, but you can track multiple events with a single line of code. You may even be able to add event tracking to large sites without changing much more than the header code. jQuery selectors will allow you to grab existing elements on your web pages without dabbling in their individual code.

If you’d like to learn jQuery, I highly recommend Sitepoint’s jQuery: Novice to Ninja. I have a copy, and it’s a great resource, both for those who want to dip a toe into the jQuery waters and for those who want to expand their skills with jQuery and JavaScript in general.

It’s powerful stuff for neat, efficient coding of event tracking. The example I used, specifically, can help you determine which external links on your site are useful, and which aren’t. For example, using this data a web analyst could tell you whether the outbound links on your site are helping to complement your site or lend credibility to interested buyers — or if they’re just sending visitors away for good.

What’s Event Tracking?

Traditionally, web metrics were entirely based on page views. We look at what pages visitors see, and in what order they see them. But that’s not how the web works anymore… things are not just page-by-page. You can search a Google map and then move around or drag your location pins without reloading the page. You can post your Facebook status updates and see new tweets come in on Twitter without reloading. You can watch, pause and rewind videos, without reloading. JavaScript, which enables this interaction, is more important than ever to using the web.

Event tracking allows you to gather data when these things happen. Older techniques for tracking things like video plays involved forging URLs — using a snippet of code that would “pretend” that a page was loaded so that we could track the event. With proper event tracking, we no longer need to view things as URLs. We can track events as what they are — non-pageview events.

Getting Started

Here’s what you need to know to get started using events in Google Analytics:

First, Google has set up several fields for each event, for the purpose of categorizing them. Events are grouped by Category, Action, Label and Value. Let’s look at how they play together.

The above diagram shows four events that are grouped into two categories. The events are represented by the coloured boxes.

Let’s consider the first category of events, “Videos”. This event category will relate to actions that are taken on videos throughout the website. In other words, all events that take place with videos on the site, including videos played, paused, downloaded or shared, will be tracked in this one category.

The next level down is the Action. As the name suggests, actions are the specific thing that was done by the user to trigger this event. In the case of these videos, we have an action for “Play” and an action for “Pause”.  We can find out pure metrics for actions, such as how many videos were played by a specific segment within a time frame, or we can use them to group specific events and drill down by event type.

On the next level is the label. For our videos, we’re using the label to indicate which video an action was performed on. For instance, the first event in the diagram is a “Play” action labeled “Training Video”. Now I know specifically which video was played. The next action has the same label, but is of the “Pause” type — meaning that the training video was paused, triggering this event.

The last number is “value”. Value is an integer field which, in the case of my videos, is left blank. Values are used to provide specific counts that are useful to the event. For instance, if the event is the removal of an item from a shopping cart, I may use the “Value” field to indicate the dollar amount of the item removed. Then, I can know the total value of all products that were removed from carts prior to purchases.

Our next event category does make use of the values. This category is called “Contact Form”, and is used on a website for events related to that form. Our first event’s action is a form error, which means a failure to send the form because something went wrong.  The label is used to indicate the type of form error, in this case, an “Invalid Email”. We’ve also included a value, “3″. That value is, for this event, the number of errors that the specific visitor has encountered so far. Thus, we know that this invalid email was the third error encountered by the user.

The last event is also for the contact form, in this case tracking a successful submission of the form (the Action), and the type of request that was sent (the Label).

Now, you don’t necessarily need to use Categories, Actions, Labels and Values in the exact way that I’ve laid out. What matters is that you formulate a method for tracking events and stick to it.

The Code: Tracking an Event

To actually implement the tracking on your site, you’ll need to add a little bit of JavaScript code. The code I present here uses the asynchronous method of tracking. This is a new method of tracking that Google recently deployed as its standard tracking method. You don’t have to use the asynch. method to use event tracking, but it may be a good time to upgrade anyways.

You can tell if you have the asynch method by looking at the Google Analytics tracking code on your site. If it begins with the following:

Then you’re ready to go. If not, just log into your Google Analytics account, re-copy your tracking code and update your site.

Now, you just need to add tracking codes to the events on your site. Suppose, for example, that you have an image gallery on your site, and that clicking on an image enlarges it. Your code for a particular image may look something like this:

Let’s say you want to track how many people click on this image. You’ll want to add the tracking code to the onclick event for that image. Onclick is a JavaScript event that allows you to execute code when someone clicks on something. To do so, add this code.

Let’s examine the code for that event more closely. The code to track an event in Google Analytics is as follows:

For our event, we coded it as follows:

The first field in the _gaq.push() function is called ‘_trackEvent’. What it does is obvious — it tells Google Analytics that we want to track an event. The next field is the category. We set it to “Images”, because that’s what we’re dealing with. The action is the next field, which I set to “Enlarged” to tell us that someone clicked on an image to enlarge it. The last field is for the label, which I set to the filename of the image that is being enlarged, so that I can track how many times each image is enlarged.

Notice how I didn’t add a fifth field for the value. I’m not tracking a value here at all, so I can omit that bit. In fact, you can also omit labels if you don’t need them.

Let’s look at another example: tracking external links. If someone clicks on a link that takes them outside of your site, you don’t have access to the data for the page they land on, so you wouldn’t know it happened. With events, you can trigger a bit of JavaScript to occur right before they leave your site. For example, let’s say I want to track how many people click on the link to my Twitter account. All I need to do is add an event:

Now, I can track who clicked on the link to my Twitter profile, and how many times that link was clicked.

Reporting Event Data

Once you have your tracking set up, you can view events as they occur. Note that you don’t need to set up events in Google Analytics before you track the codes. Just like you don’t need to add every URL into Google Analytics manually, GA will track event data as it comes in automatically.

You can find the event tracking under Content > Event Tracking. Here, you can view events by Category, Action or Label… or you can drill-down into the heirarchy to see specific subsets of the data (such as all Clicks for a particular link). You can also segment this data just as you can with normal page view data, so you can see which videos were played by people who bought products, or whether or not Canadians had a hard time filling out your forms.

Taking Action on the Data

Event tracking is a great tool to give you some more data, but as always, the value of web analytics is always in the insights that data brings. This is where a web analyst can dive into the data and come up with actionable things you can do to meet and exceed the business goals of your site.

In the meantime, I’ll talk a little more about improving and organizing your event tracking in some upcoming posts. Be sure you don’t miss them by subscribing to Work, Web, Play.

So it’s no surprise, then, that the time of year will make a big difference on your web traffic. Of course, any ecommerce or consumer-focused site will notice a lift in the November-December holiday season. But what other factors influence your traffic?

I was just looking through my Google Analytics account when I noticed that one of my sites, Ancient-Mythology.com, had picked up a bit over the past two weeks. I took a step back and looked at the charts for the past two months, and realized that my traffic was coming out of a two-month lull. Curious, I took a look at the past 22 months of data. The answer was obvious.

It doesn’t take a degree in rocket surgery to put this one together. As my clever clip-art inserts demonstrate, my traffic was down every summer and during the Christmas holidays. This is a strong indicator that my mythology site is being used primarily by students, most of whom are probably working on a high school class project, or studying humanities or religion in college.

We tend to look at our stats on a week-to-week or month-to-month basis, but there’s plenty to be learned by looking at the big picture. So take a look at your stats over the past couple of years. Your niche may have an annual pattern — and you might learn who’s really visiting your site, as I did.

Once you’ve figured this out, capitalize on it. Organize your marketing campaigns and major site updates according to these patterns, so your site is at its prime when you have the most visitors. Use this data to determine the needs of your visitors at the time, as well. For example, I might see success if I were to advertise or affiliate with other student resources, or services offering essay-writing help.