“I can’t find anything!”

This is the most common response we came across during the scoping and implementation of Search and Promote as the new internal search for Murdoch University.

Hardly surprising, given the issues with internal search that I covered in my previous post, but amazingly consistent!

In fact, one of the great truths we found during this project is that people truly don’t care where content is located, or whether it’s authenticated and/or accessible – they just wanted to type something in the search box, immediately find what they’re looking for, then carry on with their work.

We’ve now completed the implementation across our internal sites, and it’s working really well – so well that we’re now 2-3 weeks away from covering our external sites.

In my last post I promised to run through the implementation, however there’s a lot to talk about, so today I’ll cover SEO metatags (or the lack thereof), using multiple content sources, and how we integrated Search & Promote with SiteCatalyst to dynamically alter search result ranking.

Given the issues with internal search across campus and the wide range of staff and students that were more than happy to tell us just how bad it was, we decided to first implement Search & Promote across the internal sites where our primary audience are current staff and students.

Through the implementation of SiteCatalyst a few years back  across our network sites we have been able to segment our staff and student traffic, so we knew from the onset just how many searches each segment were doing, and how long on average they were taking.

Looking specifically at staff, approx 2,400 people collectively performed 234,131 searches in 2010, spending an average of 202 secs per search. Wow!

That equates to 13,137 hours, which, at an average of $40/hr, comes out to a $524,498 productivity cost. This figure alone should catch the attention of your key stakeholders and finance people.

Armed with that knowledge, we set the following key objective for the  Search & Promote trial across our internally facing sites;

• Reduce time staff spent searching by 10% by delivering a single set of filterable results, transparent of source, influenced by recent traffic.

Now that we had a clear objective, we could begin on the planning and implementation. We were greatly aided by a project team at Search & Promote – thanks John, Wally and Richard; you were all very helpful, and it was great working with each of you.

The first step was to set up the organic crawl of our internal sites, which largely consisted of listing the appropriate entry points;

Image: URL entry points in Search and Promote

And their corresponding URL masks (note the test feature that allows you to try your masks before saving them);

Image: URL masks in Search & Promote

Search & Promote works on a number of pages crawled – your licensing allows you to go to a certain number of pages, and after that the pages are not added to your index. There was a bit of tweaking to figure out what that level was, however there’s a cool feature in Search & Promote that allows the crawl to continue and count the number of pages that you’ve gone over by so you at least have an idea of where you are. From there you can either increase your licensed limit, or identify the larger than expected sites and par down the number of pages found by using the error logs and URL masks.

Compensating for the lack of SEO content

One of the issues I’d talked about previously was a lack of the bare minimum SEO metadata across many sites, most of which we had no direct control over. We tackled this by using the metatag injection feature in Search & Promote, which can be configured to dynamically inject metadata during a crawl, based on a URL pattern. This metadata is then included in the index as if the metadata was already embedded within each page, and can range from standard title/description metatags, to custom tags that can be use to create search filters (facets).

We soon found, however, that a significant portion of internal content required authentication to access, which meant that the crawler could not get in to that content. The Search & Promote crawler can be given credentials to access that content, however our concern was that content was authenticated for a reason, and to show even a title or extract from authenticated content on a public search may give away too much.

Given that the “we can’t find anything!” comment included authenticated content and applications, we needed an alternate option for this implementation to be successful.

At Murdoch we have a database called the A-Z index, which is maintained by our IT area, and over the past 5-6 years has grown to include an entry for most of our authenticated content and applications. This was a perfect source of information, now we needed to somehow incorporate this content into our search results.

Enter a feature in Search & Promote called ‘index connectors’.

Incorporating multiple sources of content

The index connector feature within Search & Promote allows you to define a third party xml feed, xml file, or comma/tab delineated file as an alternate source of content to be crawled.

The IT at Murdoch team were able to provide us an xml feed out of the A-Z index which allowed the Search & Promote crawler to include each entry/link within the feed in its scheduled crawls, together with custom mappings for each tag within the entries  to predefined custom metatags;

Image: Sample from our A-Z Flat XML feed

Image: Setting up the A-Z Flat XML feed as an index connector

Not only were we able to crawl the feed and include all the authenticated content as separate entries (‘restricted’ in the above screenshots), but we were able to alter the look and feel of the specific A-Z results within the wider search results, and account for a lack of  description within the feed.

The side-effect that we hadn’t counted on, but worked to our benefit, is that the A-Z index had entries for related non-Murdoch sites that were still of value to staff and students.

By having entries for the non-Murdoch sites in the A-Z as wayfinders, we didn’t need to crawl the actual sites themselves. This resulted in a significant reduction in the number of sites/pages we needed to organically crawl, while still providing our audience with a complete set of search results.

Using this same index connector functionality we were also able to incorporate the university’s campus directory listings via a new xml feed; whereas with the A-Z feed we only wanted to incorporate the results within the wider results set, we wanted results from the campus directory to always be the first results and be displayed in a table format, but more on the styling and positioning of these multiple content sources later.

Allowing for cyclical requests to ensure the most relevant results appear

In my previous post on Search & Promote, one of the key advantages the product had over its competitors was the ability to natively integrate with SiteCatalyst.

Via SiteCatalyst we already knew that our internal search terms follow highly cyclical patterns as our student (and staff) needs change over the semester. For example, the term ‘timetable’ is searched for throughout the semester, however the anticipated result changes as the semester progresses. At the beginning of semester, people are looking at for their semester timetable and towards the end their exam timetable.

In the past we’ve used custom coded mechanisms to help staff and students find what they’re looking for, however with Search & Promote we can take that to a whole new level!

Search & Promote allows you to define a data source within SiteCatalyst, in our case Global Production > Page Views, and then add ranking weight based on those values – the higher the weight, the higher the impact the SiteCatalyst data will have over your search results.

We defined s.prop41 under our Global Production suite in SiteCatalyst as SearchPromoteURL, and then used it to cross reference the Search & Promote crawled URLs with the associated Page Views data in SiteCatalyst;

Image: Using page view data from SiteCatalyst to influence ranking

Now, every day the last seven days worth of aggregated SiteCatalyst page view data is automatically downloaded and fed into the Search & Promote custom defined field SearchPromoteURL, which in turn is used in a ranking rule that increases the relevance of highly trafficked pages in the last seven days;

Image: Aggregated page view data in Search & Promote

A good example of this in action are our sample and past exam papers in our Library website, where there is a separate page per letter – with the SearchPromoteURL ranking rule disabled, the pages are literally ranked A through to Z, as the other active ranking rules see them as equally relevant. However when the SearchPromoteURL ranking rule is in place, the top ranked exam page is Exams B, followed by P and I.

In the admin data report for “exams” below you can see how the ranking, relevance and score metrics are all the same for the exam paper pages, and that the differentiating ranking  factor is delivered by the page views;

Image: Admin view of results for 'exams' and the different ranking scores that order them

The same ranking results can be seen on the front-end at http://search.murdoch.edu.au/?q=exams;

Image: Corresponding public search results for 'exams'

This is exactly what we set out to achieve, and it’s so far looking to have worked pretty well!

In part 2 of this post, I’ll cover how we combined all our sources of search results into a single set of user-centric, filterable search results, well as how we fared against our original objective of reducing time our staff spent search by 10%.

Ok, it’s been way too long since I posted an update, and loads has happened since November.  I’ve been to the Omniture Summit in the US, I’ve presented again at the Education Marketing Conference in Sydney and I presented twice at the Omniture Client Briefings in Sydney and Melbourne.  That was all in March.

A couple of conversations at the (incredible) Omniture summit sparked an interest and I thought I’d share with you how we implemented.

Long pages.  Well, pages that go beyond the fold.

Do you know if your users are scrolling down to read the content?  Did you know you can get this insight?

Clickmap would be the traditional method, but that will only show what they are clicking on…not what they are viewing.

There’s a plugin called “getPercentPageViewed” and it’s really easy to implement to get that understanding.  You might actually need another plugin, if you’re not already using it, which is getPreviousValue.

You then need to set aside two s.props, correlate the two, and add a classification to one of them.

Sounds complicated?

No!

Ok, so, to the code.

s.prop31 = the previous page name
s.prop32 = how much of the previous page they viewed as a percentage

        s.prop31=s.getPreviousValue(s.pageName,'gpv_pn');
        if (s.prop31){
        s.prop32=s.getPercentPageViewed();
        }

Now, this actually measures the percentage of page viewed for the previous page.  But through correlations, we can then apply the correct percentages to the correct page, so we can generate a report that shows something like the report shown to the right.

This report is simply looking at the custom traffic prop #32 “PCT Page Viewed” and it represents all pages, site wide.

In itself, not very useful.  28% of our pages are 100% viewed – meaning they either scroll or the whole page loads.

Plus, it’s the entire list of percentages, so eventually, this report is likely to show every number from 1 to 100.

Now, here’s where the useful stuff starts.

If you view the Previous Page Viewed traffic report, you’ll see a list of previous pages viewed, along with the number of times they were viewed (standard measure on traffic reports is page views).

Pick a long page that you want to look at further and correlate that page with the percentage viewed.

You can see something like the next image shown.

So, here, I’m looking at one of our long pages, and I see that 19% of the time, users are scrolling all the way to the bottom – which is good.

However, this report also shows every percentage value passed in…which makes it rather unwieldy to try to review.

So, to get a little more useful, you need to create some classification buckets, for the percentages, so that you can group the percentages together and report on the groups, rather than the individual values.

All you need to do is apply a Classification to the custom traffic property (s.prop32 in my example).  By classifying the individual percentages into buckets, your report will be much better.

So, for example, we want to show anything more than 75% viewed to be in a bucket of Up to 100%; anything from 50% to 74% was called Up to 75% etc.  To do so, go to the Admin Console and add a classification for s.prop32, which will create the necessary SAINT files.  We called our buckets Percent Buckets.

Download that classification file, and add in the buckets you want, then upload it to SiteCatalyst.

Now you can run a report to show individual pages viewed and you can now correlate that with the Percent Buckets. What you’ll end up with, providing you’ve done it all correctly, is a report similar to the following:

Now, that’s far more interesting and useful.

It shows us that on average, almost 45% of our traffic scrolls 100% on this particular page.  As this page is a list of courses, we would expect that this has varied scrolling as people will find courses in different locations.

But, if we had a long piece of content, it would help us to determine the overall design, for instance, if the key call to action was at the bottom of the page…maybe the page should be shorter.

getPercentPageViewed is a really useful plugin which is easily implemented without any support and can provide more insight into how users are interacting with your content.

Since I’ve been incredible bad at updating this, I’m going to be adding in a few more posts rather quickly around some of the new things that we’ve implemented recently, such as Page Velocity (how certain things affect page views), the latest Dashboard using SiteCatalyst (which is amazing – nice one Omniture), Keyword Classifications (grouping search keywords into various categories – combined with Page Velocity), link tracking to automate Most Popular destinations, and a number of other little nuggets I’ve come across.

I must confess that the reason I’ve not updated recently is that we’ve been rather busy doing things like work, such as launching a whole new internal site to our Staff and Students and our brand campaign Encounters, which, this year has turned into a massive online/offline fully integrated campaign, including a TV, website, a mobile site, banners, emails and an a physical installation onto the campus which takes a feed from the main site etc.  So, my apologies.

Just presented on how to get value from your analytics platform to around 150 people at the Marketing Higher Education Symposium 2009, at the Sydney Convention Center.

136 slides in 30 minutes (quick fire)…lots of nodding heads and a few chuckles too, which is always nice.  I think it went well though.

If you were at the conference and have questions, please feel free to ask using the comments.  If you weren’t at the conference, and have questions, don’t be shy.

You can get access to the presentation slides (although it’s a bit tough without the voiceover).

Having been asked a number of times to speak with potential Omniture customers, I’ve heard that they believe it’s hard to set up and maintain.

Well, that’s a myth.

Omniture is in fact relatively easy to get set up and maintain.  It’s code based, so you just pop the code into your page:

• At the top of the page, just after the <body> tag, add your call to load the s_code.js
• At the bottom of the page, just before the </body> tag, add in the rest of the Omniture code, which then executes the s_code.js on each page load.

Easy.

But, you really want to engage their Professional Services team during the initial configuration as they will customize your s_code file to support your online strategy, add any custom variables (props, evars and events), etc which will then ensure that you get the most bang for your buck.

I’ve spoken to a number of Omniture customers who implemented without assistance.  What they face now is two things:

1. Measurement that doesn’t quite match their online strategy/needs
2. Tough questions asked by their managers as to why they are using Omniture instead of Google Analytics.

What they now need to do is engage with Professional Services so that they can understand their online strategy and align their measurement strategy to their online strategy and then tweak their s_code.

So, it’s always worthwhile doing that before you implement.

And it really doesn’t take long.  2-3 weeks of assistance and you end up with a great “playbook” which documents the implementation and how you can use it to answer those top questions.  The value is absolutely in the customization.  But I’ll talk a little about that in another post.

From that point on, it’s pretty much easy sailing.