Tagging users for intranet analytics

In an attempt to get more out of our analytics data, I’m going to experiment with tagging users as they visit the intranet.

It’s best practice to look at more than the whole picture when analysing web traffic data; segmentation provides greater insight into what is happening out there in the real world. A blanket report of page views for the complete intranet will not provide many insights.

Another good motto that I use is “no lonely metrics” (coined from Avinash Kaushik.) In other words, don’t just give me a number. Always compare one metric against another, for example, a number for this month compared to last month or page views compared to time on page.

On an intranet, based in one country, it’s hard to get the same amount of demographic data that you’d normally find on analytics from a web site. On our public site I can find out where visitors are located and how they found our website. But staff on the intranet all start with the same homepage when they open their browser. Unless they land on the intranet from a tagged email or newsletter, we don’t have much idea where they came from, geographically or organisationally. In fact, the most that we seem to be able to offer in terms of visitor statistics is the number of visitors. Because we are all on the same network, few visits to the intranet are from referrals and there is no geographical diversity.

Consequently, most of our intranet analytics reports are based around intranet pages and documents. There is very little detail about the visitors. We know what people are looking at but we don’t know much about the people. Which means that we can’t segment and chop up our reports from the user perspective. Which means that we are not getting a clear picture.

By using cookies to tag visitors based on the content that they view or by offering a self-service page of check-boxes where staff can tag themselves, I hope to be able to integrate this information into our analytics and produce more informative insights where the emphasis moves from pages to people.

See also

How we increased feature news traffic by 53%

At the start of October we introduced the next step in our strategy to improve engagement with news stories on the intranet. A month later we are seeing a 53% increase in traffic.

I had a good hunch that introducing the box would generate *some* interest, but I was amazed by the results at the end of just one month. Pageviews for news stories climbed from 44,185 to 67,872. Similar to Google Adwords, simple text adverts, when placed in context, can be effective.

This increase in news story traffic started when we introduced a “Related stories” advert box, placed top-right of feature news pages. Nothing clever. It’s a simple text box containing a bulleted list of links to past stories.  A maximum of 3 links, with something in common between them all.

Related news

It’s a manual process for our intranet news editor (yes we just have the one!) to link up the relevant back-stories. We publish at least one, usually two feature stories every day, timed to coincide with our peak news readership periods (elevenses and late lunch) aiming to give a sense of steady momentum to the homepage news stream. Our feature news is varied, with stories from the front-line to seasonal pieces to interviews with board members.

The recent enhancement is a great success for my internal communications colleagues. For them, it suggests an increase in reach and shows that staff are interested enough to want to browse through back-stories to get the news behind the news, creating a richer picture. Being practical, we’d like it if staff had already read these stories, but related stories give us a second chance to increase coverage and helps staff to discover articles that they would not otherwise find. Over time, the ripples should start to run through our news collection as more and more stories backlink and crosslink to each other.

I blogged in August on our plans to introduce social functions on intranet news stories. I stress again that we are doing this on a limited HTML/Javascript platform with no fancy programming or databases. We already have a basic *Like* function. Related stories is the second feature to dripfeed into the mix. Next up are *Share with a colleague* and *Comments*…

Release the test tubes; time for more user experiments

As part of our efforts to save money across all parts of our organisation, we are combining many of our human resources, finance and procurement services into one central place.

There are several intranets within our organisation. Currently, most staff come to the HQ intranet for their human resources content and services. But there are some parts of the organisation that do their own thing. The move towards a shared platform will simplify processes for staff as well as cut costs and improve efficiency in back-end processing and automation.

The move will be a staggered project, slowly introducing new ways of working with the ultimate goal of providing an online self-service platform for staff. We will kick off with human resources services such as updating bank details and sick absence records, and then bring in other services. We’ll move from paper-based and electronic, downloadable forms to online processing.

While the new applications are being designed and developed outside of the Digital Team (usually by technical developers with no user experience processes), and being housed outside of the core intranet as part of the greater digital workplace, I have to make sure that staff will be able to access the pages and find the services easily from the intranet. Much of the content and guidance already exists on the intranet but there will be some new guidance for specific front-line staff. So we’re giving it a little reshuffle and a bit of a rewrite.

Fortunately, I still have the test scripts from the information architecture phase of the intranet redesign project, last year. I just need to modify and add a selection of tasks and I’m ready to run the tests again.

Shelf-stackers in the intranet supermarket

The job of the shelf-stacker is to fill the intranet shelves with junk. It’s a fairly easy job. They don’t have to think too much. It’s not difficult to shove something on a shelf. They might stack it next to something similar, but it’s not so important to them where it goes. Some of the shelf-stackers don’t stack items with the labels facing the right way. As long as it’s on a shelf.

They’re not bothered whether a customer takes an item off a shelf, has a little look, or not. They don’t mind if something has been sitting on a shelf for months and is out of date. That’s not their job. Sales figures don’t interest them. Top sellers? Supply and demand? Nah. In fact, most of the time, they don’t even bother looking at what it is that they put up on the shelves. Someone gives them something to stack, and off they go. Job done. Box ticked.

Shelf-stackers continue to fill the shelves. Some aisles become so cluttered with piles of junk that customers often complain that they can’t find what they want on the shelves. And when they give up looking and ask the shelf-stacker to help find something, it is a fruitless search. Some of the keener shelf-stackers may realise that customers aren’t visiting certain aisles. So they hang flashing signs above the aisle in the hope of enticing the customers. The customers learned long ago to avoid these aisles.

In the intranet supermarket, we need more than just shelf-stackers. We need intelligent people who care about their customers. Who realise that what they are stacking is ultimately for consumption by customers. Who understand that simple stacking alone does not tick the box. We need them to have an interest in the shelf life of their products, keen to find out if customers can find products easily. We need people with the good business sense to only stock what the customers want, eager and ready to tidy up messy aisles and to be more questioning about stacking whatever they are given, wherever they fancy.