There was an interesting article entitled, Help Desk Is Spelled: R-O-I. The article highlighted a couple schools, but mainly focused on LSU. In 2007, LSU launched an internal marketing campaign within their IT department encouraging students to learn more about new technologies available and to be smart about using them – focusing a lot on security issues, etc.

The campaign included a cartoon character named Tad who had the misfortune of being  computer-security illiterate and getting himself and the institution into all sorts of mischief because of his shortcomings.

The message is “don’t be a Tad” and the goal of the campaign was to get students to be more responsible when it comes to their own computers by installing recommended anti-virus  and spyware applications.

When I read the article, I thought, “what a great idea, I wonder if it worked.”

So I read, and read, and read. And they never told me if it worked. Besides a quote of it “worked wonders,” there were no metrics to speak of.

Quite possibly Campus Technology just never mentioned it, but I’m wondering if LSU ever tracked the campaign. Whether the article meant to or not, it mentions the goal of the campaign:

… driving users to take full advantage of new technology rollouts, and not sapping or overburdening help desk resources because users are not fully versed in and encouraged to use the new tools.

Later the article states:

… the campaign was designed specifically to get students to take advantage of an outsourced creditmonitoring service from Equifax and antivirus technology from Symantec, to keep endpoints secure.

Great start, but did the campaign meet the goal?

• How many click-throughs were there from the campaign posters, billboards, bus ads, and other off-site elements?
• Did specific media types work better than others?
• How many users converted by downloading the anti-virus apps?
• Did help desk call volume decrease?
• Did virus issues decrease across campus?
• How much money was saved by the decrease in call volume and virus issues?

Was the campaign working? Did it need  to be tweaked to get the point across more effectively?

It’s odd to me that the title and content of the article consistently mention ROI, but we never find out how much the school actually saved by implementing the awareness campaign.

Again, the campaign may have been tracked. My point is only that if it was tracked, I wish Campus Technology had reported on its success beyond saying that it “worked wonders.”

How do you know it’s working? How do you know your users/students/etc are finding this stuff useful?

Obviously different types of higher education websites might use Web 2.0 differently. For smaller schools, it might be a little easier (or not!) as there may be one website for all aspects of the higher education experience. For larger schools, however, each department, each school, each athletic team, each *course* may have different websites. (Yikes!) So how can each of those websites use Web 2.0? Let’s look at a couple ways:

1. The helpdesk can use RSS to update students, faculty, and staff of any IT alerts and issues.
2. Admissions can use Twitter to announce upcoming application and registration deadlines, and more.
3. Instructors, advisers, and admissions can create blogs to keep their students and prospects involved.

This list could go on and on. The question becomes, however, how do you know any of it is useful for your users/students/faculty/etc.?

First, of course, create some goals for your user of these technologies and applications. Stop rolling your eyes, just do it! I guarantee you’ll thank me later.

So how do we create goals for something we’ve never used before? Remember, goals aren’t set in stone. Put *something* down. Anything.

Facilitation goals. These might be the most important. If you are going to use Twitter, blogs, Facebook, any type of collaboration tool, then *use* it. Make a goal that states how many times you’ll post or update in a day/week/month and make sure you meet that goal. I’m not suggesting that the posts or updates be forced, however there must be fresh content or it shouldn’t be done!

Analytics goals. Now let’s talk about usage. How do we know if people are actually using this stuff? Let’s put some goals down. How about something like these:

1. Helpdesk and RSS: RSS subscriber count to increase by 2% monthly. Good start! Now, how do you measure that? How about using Feedburner?
2. Admissions and Twitter: Increase our twitter friend count by 2% monthly. Ok, but let’s go further with this one. How about tracking the URLs that you post for your announcements? Usually in Twitter you use the “tiny URLs” to save space. You could also use “vanity URLs” to do the same and keep your branded URL. But, either of these URLs can be tracked so you can see how many of those Twitter *friends* are actually clicking through and taking some action.
3. Instructors/advisors/admissions and Blogs: Increase visit rate by 5% monthly. Increase RSS subscriber count by 1% monthly. That was too easy. If your instructors, advisers, admissions, or anybody else is running a blog, there should be many well-defined goals and strategy around that. Let’s talk about that more in-depth in a later post.

The bottom line is that the goals don’t have to be complex or lofty. Start small … but put something down. Why? Don’t you want to know if your users/students/faculty are actually engaged in what you have to say?

If you’re posting registration deadlines on Twitter and nobody is clicking-through, don’t you want to know so you can change your strategy? Maybe just slightly changing your wording helps. Maybe posting more relevant information with *no* link will help the click-through-rate of the information you *do* post with a link. But, again, you won’t know any of this unless you’re using some kind of analytics.

It all goes back to your users and students. *They* need to find these things useful. How about finding out if they do!

For the purpose of this post, I’m assuming that your helpdesk site has either no analytics tool installed or, if it does, you are currently not doing anything with the data.

So, let’s get started.

Let’s say your helpdesk site includes:

1. tutorials or instructions for using university systems
2. an alert system
3. a ticketing system for users to enter issues
4. FAQs/knowledge-base

There are many more aspects to any university helpdesk site, but let’s use these four to start.


Installing the code. Before you do anything, install some analytics code and get some benchmarking data. If you don’t have code installed, there are many free tools out there. I would recommend Google Analytics for a couple of reasons. It’s probably the most robust free tool out there today and it’s probably the most universally used free tools.  Why would that second part matter? Because the support community is huge.

If you’re installing Google Analytics, follow the basic setup tips suggested by Kyle James at his blog. He outlines some great tips for those just starting out with Google Analytics.

Pay attention to your callers. Helpdesk sites are unique. They really are customer service websites. So, it’s important to pay attention not only to what your website users are doing, but also to what your actual callers are asking. Compare what your callers are asking and website user behavior. Is there a gap? I’ll go into this in more depth later in the post.

Create a quick survey. If you’re just starting, it’s important to know what on your site is popular with your users and what they like/dislike. It’s very easy to set up a quick survey.

Although you can just have a link to the survey/feedback form on your site, actively promoting your survey will give you better results. I know what you’re thinking – “I *hate* those pop up surveys! I never fill those out.” Remember, though, that you’re not your target audience. You’ll also be surprised at how many users fill out your survey. Seriously.

If you do use the active method, think about using 4Q from iPerceptions for these reasons:

1. It’s free and takes about 10 minutes to create.
2. All plug-n-play, you simply add a line of code to your site.
3. You can control how many users receive the invitation.

Why should you use the *active* survey approach instead of just putting a link to a survey on your site?

1. It will take you less time to get results.
2. Here’s the big reason why – passive surveys or feedback (ones your users initiate by going and finding the link) will give you mostly negative feedback. Why? Because average users almost never go hunting for the feedback/survey link unless they are having a bad experience. If you ask up front if the user would be willing to fill out a survey at the end of their visit, you’ll get both negative *and* positive feedback.

It is as important to get positive feedback as it is to get negative feedback. If you only know what you’re doing wrong, how can you continue to do the right things right?

Any survey/feedback form is better than nothing, though, so if the active approach isn’t right for your site, then create a short form and put the link in your footer or another appropriate place.

Ok, enough of that. Onto the helpdesk …

Tutorials and instructions. Which ones are the most important to the student, faculty, or staff? Do you know?

1. How many visits are you getting to each tutorial? (Visit Report) Using the visit trend, you will quickly be able to tell which tutorial is used most and when (maybe at the beginning of the semester?). You may see such an increase that you may want to make the tutorial more prominent on your site at specific times of year or semester. Please note: just because a particular tutorial is the most clicked on doesn’t mean it’s necessarily what users want. Maybe the users can’t find the one they want. This is why surveys are so important.
2. When the user finds the tutorial, are they making it through the entire tutorial? (Goal Conversion Reports) Using a goal conversion funnel, you can see how far your user got into the tutorial. Why is this important? You can focus on which stage of your tutorial may not be effective (where users are *falling out*).

One thing you can measure to see if users *are* finding the tutorial they need is the time spent within the tutorial. Are they clicking and immediately abandoning? This might be a red flag saying that the particular tutorial isn’t the one they were looking for.

Alert System. Most likely your alert system includes alerts for everything from scheduled system outages to virus alerts. Whatever the use, it’s important that the information gets out to users. You may be sending emails or text messages for important alerts. That’s fantastic. Here are a few metrics you might use to see if your alert system is effective:

1. Are users actively asking for your alerts? (RSS Feed Tracking) Track your RSS feeds using feedburner. Are people using them? If not, find out why. Do users understand RSS? Should you create a tutorial about RSS feeds and how to use them?
2. Which type of alerts are the most popular? (Popular Pages Report/Content Report) If your most important alerts are not your most visited, should you make them more prominent? Are they in technical language that users may not understand?

Ticketing System. If your ticketing system is public-facing (users can enter issues themselves) and web-based, you can add your analytics code to the system to see if users drop off anywhere within the system.

1. Are users using your ticketing system? (Visit Report)
2. How many of the users that initiated a ticket followed through and actually submitted one? (Goal Conversion Reports)

If your ticketing system has search capabilities, take a look at the internal search keywords used. You can start to get an idea from these keywords what users are having issues with as well (even if they do not actually submit a ticket).

FAQ/Knowledge-base. How are users finding your content? What content are they searching for? You can get this data on both a standard FAQ page (with in-page *jump* links), or with your knowledge-base.

1. Which FAQs are users clicking on? (ClickMap or Site Overlay) By using your site overlay you can see where users are clicking and quickly see which FAQs are the most click on.
2. Which questions in the knowledge-base are users searching for? (Internal Knowledge-Base Site Search) Studying the keywords users type in to get to answers within your knowledge-base can be very enlightening. What type of language are they using? Incorporate that language into your responses. This also might give you insight into a language shift within other parts of your site. Remember that your users, generally are not as technically savvy as you, so studying the keywords *they* use will give you ideas about how to re-word some things within your knowledge-base *and* within your site.

Studying user behavior for your overall helpdesk site is important as well. How do users search for your content? What is your visit-FAQ(knowledge-base) ratio? If you have an overall internal site search, what is your visit-to-search ratio? Are most users using search or trying to navigate through the site using navigation or content links?

It’s important to re-iterate the importance of a survey or feedback form on helpdesk sites. Why? Because your most visited tutorials, FAQs, knowledge-base questions, etc., may actually *not* be the top demanded content. How would you know that? What should bring up a red flag?

1. You see a gap between the most visited pages/questions/alerts and:
   1. what your users are saying in your survey,
   2. the keywords your users are typing into your internal site search, or
   3. the questions your users are asking when they actually *call* the helpdesk

If there is a discrepancy, some reasons may be:

1. The language you’re using is too technical (experiment with changing the language and see if that gap closes up). Users can find the links, but don’t click because they don’t know the terms.
2. Your language is fine, but the site is difficult to navigate.
3. Both 1 and 2.

So there you go. Some examples of how analytics can help a university or college helpdesk site. Of course there are so many more, but this post is already running a bit too long. Any other ideas? Please share your thoughts.

The Web Analytics Association Standards Committee put together the Web Analytics Definitions document last year that defines every metric you can think of for measuring user performance on your site. So why am I bothering to go through some of them now when you can just read the document? Although the document does explain some metrics within context, I’d like to further explain some interesting nuances.

For the sake of time, I will only define four (of the arguably most popular) metrics in this post. There are so many others out there, but for now we’ll stick to these.

Page View. Defined technically, it’s the number of times a page is viewed. You may be saying to yourself, “well, duh!” but this metric can be confusing, especially if your site is a blog, AJAX or flash-based.

First let’s talk about blogs. Depending on the way your blog is set up, your entire post (when published) may publish to the front page. So, if you look in your analytics, you’ll get a thousand page views for your homepage page, and then, say, 10 for your actual post page. Why? Because users can read an entire post on the homepage. So how do you know which posts users are reading? An easy way to figure this out is to implement the “read more” excerpt functionality within your blogging platform. Users will view an exerpt on your homepage, then be forced to actually click and view your post page to read the rest. There you go – micro-conversion!

Flash and AJAX present problems as well. Traditionally analytics tools allowed you to “fake” page views within the action script in Flash, but, of course, this is clunky (and can take a ton of time). Google Analytics now has event logging, which allow website owners to track Flash and AJAX easier. So, for those people who think you can’t track flash or AJAX-based sites, that’s not true. And, to top it off, it’s getting easier.

Visit. A visit (also called a session – these terms are interchangeable), is an interaction by a user consisting of one or more page views for a specified time period. Usually (for most analytics tools by default), the time period is 30 minutes. So, a user comes to your site and views some pages. The session/visit ends when the user:

1. exits out of the site or browser
2. is idle for more than 30 minutes

This, again, gets a little tricky with Flash and AJAX for the reasons specified above. Analytics tools are getting better with these types of pages/sites, though.

Unique Visitors. A unique visitor is always counted according to a time frame. There are daily unique visitors, weekly unique visitors, monthly and so on. A unique visitor is a user that visits your website one or more times within a specified period. Unique visitors can be tracked using authentication or a persistent cookie. A persistent cookie, as opposed to a session cookie (which expires when you close the session or visit), is a cookie that is put onto your computer and expires only after a specified period of time (usually 365 days). Unique visitors can easily be skewed by users deleting their cookies or denying third party cookies (cookies deserve an entire post!).

So … a weekly unique visitor would be one user (who accepts cookies and does not delete them within that week) who visits your site one or more times within that week.

<PostEdit> – Kyle brought up a great point. Unique visitors is always specific to the report you’re look at. If you’re looking at a monthly report, then the visitors are unique over that month time. If you change the time frame to a week report, then the unique visitor count will change accordingly. </PostEdit>

Bounce Rate. Specifically defined as single page visits/entry pages. A bounce can only happen when a user enters a site on a specific page and leaves the site without ever viewing other pages. Sometimes people get this confused with exit rate or ratio (which is number of exits from a page/total number of page views of that same page).

It’s very important to put bounce rate into context. For instance, the two most popular links on the World Campus current students page are off-site URLs. That means, if our current students have bookmarked that page and use it as a portal to these other sites, that page will have a very high bounce rate. In this context, that’s ok. If a specific page on your site has a high bounce rate, be sure to try and figure out why. It may be for a perfectly good reason.

<PostEdit> – Another good point about bounce rate from Kyle. Remember that a bounce rate is always an exit rate, but an exit rate is not always a bounce rate. Bounce rates are a subset of exit rate specifically for first page (or entry page) visitors. </PostEdit>

My goal with this post was not to bore you (although you’re probably arguing to the contrary right now!). It’s important that we have standard definitions of our metrics. It’s as important to put these all into context when analyzing and reporting.

Next week … breaking down each type of site. The helpdesk, the Intranet, the school or department website. How can analytics help these specific types of sites?