Aug 15 2008
Analytics for the Intranet
In this post, instead of talking about specific reports that will help track a department or unit Intranet, I will be focusing on how Intranets differ from most public-facing websites and how you look at your analytics will also be different.
Department Intranets are very different from your public-facing sites. For one thing, most of them are behind some type of authentication, which can add some complexity. Some intranets may also include AJAX or other types of technology that are not the standard static html pages.
This particular topic, analytics and web 2.0 applications, has been a source of much debate in the analytics industry. This is one reason why it’s important to put every type of analysis you do on a website into context. So, for instance, page views mean nothing with AJAX because the entire page doesn’t change. So page views would be useless in this instance. There are more arguments about page views, but that’s another post for another day.
Because Intranets vary so much, it is essential that you write down the goal of your Intranet. Again, I’m beating a dead horse here, but it’s crucial. Your Intranet goals should be easier because you *are* the user! If the Intranet is for your department or unit, you should have no problem getting usability testers, survey responses, and other feedback.
I’ve been involved with some Intranet projects and I know that a lot of times one goal of the Intranet might be to take the place of company-wide announcement or “news” type internal emails. This is an easy thing to track. Are those announcements getting traffic? Do you make your *important* news more prominent than your *nice-to-know* news? If so, does that seem to make a difference in your traffic to those pages?
Segmenting on technology is also useful. Do you know the technology that your internal users are using? Unless your the IT department, probably not. Segment your analytics by browser type, flash version, OS, resolution. Have you developed a Flash movie that needs player 9.0? Are you sure you’re users are all running 9.0? Do your pages behave differently in different browsers? Again, take it into context. Are all your users on Macs using Safari or Firefox? Or, do all your users have access to Firefox? Then perhaps designing/developing with Internet Explorer in mind might not be a priority.
This is one point where your external site and your internal Intranet differ greatly. In my opinion, especially if you have a smaller number of users (0 – 500), you *should* make sure your Intranet works on all your users machines. In a previous post, I harp on designing for the majority, knowing there will be a minority of users out there who might have problems veiwing your website. This is the exception. WIth your Intranet, all your users should be able to use it.
Another great use is to see if certain *new* applications or technologies (say, your spiffy new widgets) are actually getting used. Are they too new? Do users understand how to use them? Using analytics you can get an idea if you might need to do a little user training.
Obviously you can use analytics for your Intranet a lot of the same ways you use them on your public-facing sites. First develop your website goals and build your analytics strategy around those. There should be different *rules* for your Intranet, though, and those should be kept in mind at all times.
