One of the new features in the newer versions of Google Analytics (GA) is the ability to track event actions on a link. This can be not only clicks, in our case, on a button, link or graphic, but you can setup javascript triggers when a user starts, stops or pauses a video, for example.

Setting this up is pretty straightforward. First, you’ll need to add a quick snippet to your GA embed code, if you aren’t already. It’s the trackPageview function. You’ll add it under the line in your GA code where you’re account code is. For example:

<script type="text/javascript">

  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', 'UA-XXXXX-X']);
  _gaq.push(['_trackPageview']);

  (function() {
    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
  })();

</script>

That will allow you to start tracking events on your pages. To add the event tracking action to a specific element on your page, you add a line of code that looks like this to your a tags.

onClick="_gaq.push(['_trackEvent', 'Videos', 'Play', 'Baby\'s First Birthday']);"

There are three fields there to pay attention to. The first is the category field. In the above example, it’s Videos. You can have multiple categories on a certain page. On our WordPress sites, we’re specifically tracking banners and small image buttons, often on the same page.

The second field is the action variable – which in the example above is Play. For our WordPress pages, we use the term Click. Through javascript and PHP variables, you can make your actions very specific, such as:

_gaq.push(['_trackEvent', 'Videos', 'Play - Mac Chrome');
_gaq.push(['_trackEvent', 'Videos', 'Play - Windows Chrome');

And finally, the label. Above, it's Baby's First Birthday. For our uses, we tailor this to the specific banner or button getting clicked. After a few days, we realized it would also be good to know what site the visitor was on. As with the other fields, this should be tailored to the specific content being clicked on. In the video example, you'd have something like this for different videos being played:

_gaq.push(['_trackEvent', 'Videos', 'Play', 'Gone With the Wind']);
_gaq.push(['_trackEvent', 'Videos', 'Play', 'Huckleberry Finn']);

To our user, our links look like this:

<a href="http://sites.jcu.edu/newsroom/?p=1697" onClick="_gaq.push(['_trackEvent', 'Taters', 'Click', 'Princeton Review Best in the Midwest (Site: JCU Newsroom ID: 1694)']);">
<img src="http://webmedia.jcu.edu/newsroom/files/2011/08/princeton_review-700x230.jpg" alt="Princeton Review Best in the Midwest" />
</a>

In our WordPress templates, it looks like this:

<a href="<?php echo $url; ?>" onClick="_gaq.push(['_trackEvent', 'Taters', 'Click', '<?php echo get_the_title($ID)." (Site: ".get_bloginfo('name')." ID: ".$id.")"; ?>']);">
<img src="<?php echo $img[0]; ?>" alt="<?php echo get_the_title($ID); ?>" />
</a>

We are tracking the individual banner that was clicked on, as well as the site the banner appears on. We add an additional field for our own, the actual ID of the banner asset. We do that just in case we need to find one quickly, or two banners get named the same thing. It’s happened.

That gives us a very nice report in GA that looks like this:

We can very easily filter by a specific site to see what buttons and graphics are getting clicked on. You could also add this to any static link as well, but I’m specifically interested on what specific calls to action are getting noticed by our users.

Matt Cutts, a software engineer and an eloquent corporate spokesman for Google, spoke at PubCon earlier this month and later gave a video interview to Web Pro News, in which he said that the speed at which web pages are available might become a factor in SEO moving into 2010.

While Google hasn’t officially said this is going to happen, having as fast a website as possible is a very good thing, for your users and for you.

So, let’s look at a few ways you can improve the speed of your site.

1. Compression

Most, if not all, of the major web servers available today offer some sort of compression. What that means is they serve out the content to your browser in a certain way, much like a ZIP file, that your browser can read and deflate very quickly. Smaller files sent = faster site.

Now, how you set up compression differs by what web server you are using and what platform your server is.

In PHP, it can be as easy as adding one line of code to your site. Like this:


<?php
ob_start("ob_gzhandler");
?>


If you’re using Apache and only serving out HTML, you should look into the mod_gzip apache plugin. It compresses text files on the fly. Here are some instructions for IIS, though there are also commercial plug-ins you can buy to achieve the same result.

Sometimes you may not have access to the actual server or root access to install some of these services. No worries – some CMS and blogging systems offer plug-ins to achieve some of these things.

I’m a WordPress nut, so on all of the installs I run, one of the first things I always install is WP Super Cache, created by Donncha O Caoimh. This plugin will cache pages of your site for super fast loading, it will compress HTML, if enabled. This plugin also works in MU, and I’ll blogging that later.

Not sure its worth it? Check for yourself. There are many sites on the web that test your site and see if you are compressing data. Here’s one that quick and easy to use. For this site, by using compression I’m saving almost 75% in terms of the amount of data sent. Faster sends = faster site loads for users.

2. Cut Down On Stuff

Compression is great, but if you site is pulling in a million assets, widgets from third-party sites, and three or four Javascript libraries, it won’t make any difference. If you can, cut down on the number of calls, minify your javascript libraries and determine something like that Facebook fan box is absolutely critical to a page.

I think we’re all a bit guilty in the broadband era of not worrying about how much our page weights are. It’s worth looking at, especially as more and more web surfing is done on mobile devices.

Want to see how much stuff your code is calling for? Check out Firebug for Firefox or use Safari’s built-in Web Inspector. You may be surprised what you see.

3. CDN

Serving some of your static content (images, CSS, js) from a content delivery network will increase the speed of your site. These assets don’t change very often, so why not let a very fast network serve them out.

There are a ton of options out there, from very expensive to not so expensive, but the two I’d recommend are Amazon S3/Cloudfront and Rackspace’s Cloud Files.

Those two are inexpensive, easy to use and very fast. The few bucks a month you’ll pay are well worth it.

4. Semantically Strong Code

Last but not least, if you write clean, good code, your site will load very faster.

If your code is a mess, or god forbid, you’re still using a layout method like tables, your site is going to take longer to come down the pipe and also render out for the user.

Are there easy things I’m missing? Leave a comment and let me know.

The challenge is that we have many different people working on pages across several departments, and they are all not “web people,” so creating pages that comply with web standards isn’t their top priority. So, a few years back, we wrote a web app to help us with tracking pages, which I’d like to share with you today.

No fancy Web 2.0 stuff here, it’s straight-up ease of use for the only audience this tool has – me, Josh and our students. This page shows a list of pages that we need to check. It shows me if the page has been assigned to someone to fix, and what style sheet the page uses. The first step is to check the validity of any page. So, clicking on a link brings me to this page.

This page is made up of two frames. Let’s start with the bottom frame. It’s the W3C results of a validation test, which is pulled in automatically depending on the URL we feed it. Once the results are in, I can set the validation status of the page as well as see a history of the times we’ve checked this page. We are adding content to pages just about every day, so it’s not uncommon for a page not to validate from time to time. Our code also pulls the style sheet the page is using, so we also know if the page CSS was changed at some point.

Once the information is submitted, the window closes and our main app updates. Next, I need to assign these pages to someone, either myself or one of our students. I select the checkboxes next to the pages and select who will update these pages at the top of the form. At this point, the pages to be updated are automatically created as a new project in our homegrown web project management tool. The next time the student logs into the project system, they’ll see the pages they’ve been assigned and can start work on them.

It’s quick and easy and makes validation, as well as the sometimes annoying task of keeping up with validation, less of a burden.