“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%.

When it comes to searching across the web, we all know that Google is king, but does this still hold true across your own internal network?

Over the past 12 months we have wrestled with this question, particularly in an environment with multiple search mechanisms, manually maintained indexes, and masses of sites that were created when metadata was primarily used to categorise instead of search.

In a series of posts, I’m going to go through our experiences in improving search across our internal network – I’m not suggesting we have found the magic search bullet, or that we’re anywhere near finished tweaking and tinkering, but I do know we’re a hell of a lot closer than where we were at this time last year.

The problem

In our travels across campus, we kept hearing “I can’t find what I’m looking for!”  – not surprising, given that we had;

1. 500+ individual sites, ranging in age (earliest was 1997), metadata (none to Dublin Core to ‘something’) and ownership
2. Inconsistent use of key SEO elements, such as title, headings, tags and meta descriptions across the majority of our sites
3. Multiple sources of content and internal search mechanisms, each with their own set of search results
4. Manually maintained indexes, all categorised and sub-related, together with an in-house redirect mechanism
5. An internal audience of staff and students with heavily cyclical search requests – a search for ‘physics’ at the beginning of semester is more likely to be for text books, and at the end of semester past exam papers

Image: Multiple source-centric result sets;

Given Google’s dominance in search, we quickly went down the path of a Google Search Appliance, or ‘Mini’, which is a self contained rack mounted system that gives you God-like powers over the Google algorithm. We were bringing in a little bit of Google in to magically transform our disparate set of sites into a cohesive set of search results.

Once plugged in, the Mini worked really well – for pages that were properly formatted for organic search.

Pages that were missing or incorrectly using titles, headings and metadata didn’t fare so well, and we found the search results were not the most relevant, as the Mini couldn’t make much sense of most of the content it crawled. We also found that there was no clear way to incorporate the feeds from other systems, with the “how do I…” answers primarily provided by a community of Search Appliance users and resellers, and not Google themselves.

Given the wide ownership of the sites we were working with, updating each with appropriate SEO friendly content was unrealistic. What we needed was a way to;

1. compensate for the lack of SEO content,
2. incorporating multiple sources/ formats of content,
3. allow for cyclical requests to ensure the most relevant results appear, and
4. combine all the different sources of search results into a single set of user-centric search results.

Enter Adobe Search&Promote

If you’re a regular visitor to this blog, it will come as no surprise that Tim is a power user of Omniture products, steadily working his way around the product wheel. We became aware of the Search&Promote product (then called SiteSearch) which promised to solve our key internal search issues.

Search&Promote uses a search algorithm to organically crawl your sites, in addition to ranking rules based on a wide range of configurable data. Once you’ve defined your rules, you can adjust the overall balance between your ranking rules and natural search relevance.

Where there is a lack of metadata, Search&Promote can be configured to dynamically inject metadata on crawl, based on a URL pattern. Additional custom metadata can also be injected to create facets (filters) that allow users to drill further down into predefined categories.

If your multiple sources of content can be transformed into XML feeds, then that content can be crawled, categorised, and integrated with the organic results by Search&Promote.

Yes, there are other internal search products on the market that will do the above, however there is one thing that Search&Promote has over its competitors – the ability to tightly integrate with SiteCatalyst and Test & Target.

We’ve known for some time that internal search terms follow highly cyclical patterns as our student (and staff) needs change over the semester. We’ve helped them find what they’re looking for using of real-time SiteCatalyst data in search-as-you-type and tag cloud mechanisms, however with Search&Promote we now have the opportunity to take internal search to the next level.

In the report below (7 day moving average) you can see two popular search results across three semesters peaking at different times during the semester;

Notice how ‘bookshop’ peaks at the beginning of semester, then dies down, only to peak again at the beginning of the following semester. No surprises here, but it does coincide with a significant increase in page views across the Bookshop website.

Then look at the results for ‘timetable’ – there’s a peak at both the beginning and end of semester. The difference here is that people are actually looking for two different pieces of content – their semester timetable at the beginning, and their exam timetable at the end – using the same keyword. Again, the rise in search terms coincides with increased page views across each piece of content.

So, in theory, by looking at the last week’s worth of traffic across our group of sites, we should be able to determine what content students are looking for, then re-rank the search results accordingly. For example, the term ‘timetable’ at the beginning of semester will push results related to the semester timetable to the top, and at the end of the semester push results related to the exam timetable to the top.

Exciting stuff!

Next post – the implementation.

In many cases homepages are either relatively static, or promotional driven.  The problem is that homepages are often still the starting point of a users journey on the site and not every user should see the same content.

In our case, at Murdoch University, despite the fact that we use SEO and SEM tactics to drive clicks to deeper content, we know from our metrics that many users either bookmark our homepage, or search for “Murdoch University” or a derivative thereof, which means that they click through to our homepage.

The role of the homepage is to channel users into areas of the site as quickly as possible.  With many different audience groups, numerous campaigns, and many stakeholders, real estate is highly sought after.  So it’s crucial that we are able to address content relevance – make the content on the homepage as relevant to what the user is looking for when they visit, because relevance yields greater conversion.

Enter Omniture Test and Target.

Using Test and Target, we’re able to easily modify the content displayed on the homepage (and many other areas of the site), by using their sophisticated behavioral targeting technology, thereby making our content far more relevant to users when they visit, with the goal of optimizing their experience, and ultimately leading to more sales.

For example, if a user has previously been to our site, started an application but not yet completed it, why point them to the content that talks about how to apply, when you can prompt them to complete their application.

Likewise, if they have expressed an interest in a certain category of information, get them back into that stream with as few clicks as possible.

As Test and Target stores a profile of an individuals browsing activity on our site, coupled with SiteCatalyst data, and various parameters that we set on specific events throughout our site, we can use that as a kind of category or activity affinity, and alter content display based on those parameters, on a user by user basis.

For example, our homepage has 4 key modules on it.  Currently the two left modules are T&T driven.  The left hand module is promotional based.  So we’re currently running a Postgraduate promotion.  If the user has been to a PostGraduate course previously, they will see the PostGraduate promotion.  If they have been to an Undergraduate course, they’ll see our Course Search module.

For the next module, it shows either a Future Students module (default), a Domestic Students module, or an International Students module.  If the user has been into the Domestic Students section, then in the future, when they see the homepage, they’ll see the Domestic module.  Likewise, if they are an International visitor, or they visit the International section, when they see the homepage, they’ll see the International module.  If we know nothing about them, i.e. they are within Australia but haven’t been to the site before, they’ll see the Future Students module.

Implementing Test and Target in this manner is very easy.  There are a number of key parts:

1. Put the code onto the page in the area where you want to display the content – this code is called an mbox.  It’s a combination of a <div> tag and a piece of javascript.
2. Put some default content inside the <div> tag.  This is displayed is nothing else can be displayed.  For us, the Course Search and the Future Students content is default.
3. Put mbox code onto other key pages and set specific parameters within those mboxes.  I call these “listeners” – they don’t actually display any content, they just pass critical information into the user profile when they are activated, such as on key pages, or key events like starting or completing an application (see below).
4. Put some alternative content into Test and Target (called offers).
5. Create targeted campaigns in Test and Target with rules about what content should be displayed (either default or the content created in step 4).
6. Activate the campaign and hey presto – behavioural targeting now works for you.

Ok, well, there might be a bit missing, like your content and targeting strategy, but you get the drift.

Category and Activity Affinity

Throughout our site, we pass a number of parameters through the “listener” mboxes, which are placed on strategic pages.  For example, in the above Domestic and International sections of the site, we have created a parameter called profile.sitesection and we pass in a value of either Domestic or International.  We can also pass in other values, such as “Research”, “Library”, “Student” or “Staff” on other pages, so that we can expand on the targeted content.  The strategy largely depends upon who

Our T&T campaign that we created in step 5 then looks for either of those values and depending on the value, displays the relevant content.  If it doesn’t find a value, it serves the default content – the Future Students content.

Another area that we utilize this is within our online application system.  We pass in a value when they start an application and another when they complete an application.  This allows us to look for those values, and depending upon a combination of them, we know the status of an application (not started, started not completed, started and completed) and can then display relevant content to either engage them to start an app, prompt them to complete an app, or other default content.

Within T&T we can also set conversion events.  These events are mostly used when you are testing different variations of promotions (I’ll post an entry about testing content in the near future) to see which one drives the best result.  For behavioral targeting we’ve found that we use these more for general reporting, rather than actual optimization.

Practical usage ideas

Content relevance is effective for every industry vertical.  For example:

• ISP’s could use it to target content to customers with accounts, versus potential new customers.
• Banks could use it to target product category affinity – those that might have expressed an interest in mortgages versus credit cards.
• Retailers could use it to target product category affinity too – if a user expresses an interest in TV, show them TV products on the homepage over other products.
• Tourism operators could target by region of interest or by activity, such as kayaking, or fishing.
• Media companies could use it to display news from a certain category, for example, finance news over fashion news.

One of the most successful strategies is re-engagement; get an abandoned user back into a process quickly.  You know they’ve abandoned; they’re back on your site; re-engage them and try to convert them.

Like everything though, it’s important that the content strategy is thought through first and the objectives and success measures are clearly defined, before trying to implement.