One of the basic features of SiteCatalyst is its ability to track conversions.  To do so, you need to use Success Events.

The Success Event is generally a counter of something happening on your site.

There’s a couple of things that should be considered though, when using success events, especially if you’re using it to count things like leads etc.

Set it once

The default way that success events “count” is to increment the count everytime something happens.  However, this can lead to over-inflating certain things if you’re not aware that it’s doing it.

For example, if you set a success event every time someone starts filling in a form, and they don’t complete the form (say they go to another piece of content), and then they return to the form and start it again, the success event fires again.  Now you have 2 form starts counted.  Depending on your measurement strategy, this can be either a good thing or a bad thing.

You might in fact only want that event to be set once per visit – so even if the user abandons and then comes back, the event will only be set once.

To do this, you can ask support to use Event Serialisation – Once Per Visit.  Simply give the name of the report suite and the event name to them and they’ll make the necessary changes.

There are a number of other ways to manage Event Serialisation as well; you can do it at the code level too, but we’ve had good results by implementing it on the backend (i.e. through Support).

Tie it to a form

When you set a success event, you almost always pass in an eVar at the same time.

For example, if the user is starting a form, then you would also pass in the name of the form as an eVar:

s.events="event2";
s.eVar8 ="Stay in touch";
In the above example, we’ve used event2 as a Form Start success counter, and eVar8 is the name of our form; in SiteCatalyst we’ve called our eVar8 Lead Type.

Then, when the form is submitted, you pass in the Form Complete event, and the same form name to the eVar:
s.events="event3";
s.eVar8 ="Stay in touch";

Now that you’ve set the events and the eVar at the same time, you’ll be able to see conversion reports with success events.

Using the above example, you’ll see a report that shows Form Start and Form Complete, against Form Names.

Tracking Leads

Not every form complete may optin as a lead.  They may have requested information, but not checked the optin box.

So, it’s generally best practice to use another success events for optin tracking.  To do so, simply add another event on your thank you page, and if they checked the optin box, then (through some custom code your development team will possibly have to write for you), you can track optins as well.

s.events="event3,event10";
s.eVar8 ="Stay in touch";In the above example, we set event3 as Form Complete, and event10 as Lead Submitted, but only when the optin box was actually checked.  Otherwise, we’d just set event3.

Given that you now have 3 success events that you are tracking, you’ll need to ask Support to turn on Event Serialisation across these three events.

Using the above examples, you’ll now be able to see reports that show the Lead Type (name of form), with the various measures against it.  Below, we show the number of times the form was viewed (instances), the number of times the Form Start was set, the number of times the form was submitted, and the number of times that someone opted in from it.

The percentages shown are a percentage of the column, so for example, only 4% of Form Starts occur on this form (there’s other data here, but I’ve excluded it from this image.  From this you can also calculate conversion rates, by using a calculated metric such as [Lead Completes]/[Form Start], or [Lead Completes]/[Visits], again, depending upon how you want to report on things.

Measuring campaign conversions

Of course, you’ll probably want to know how your campaigns are converting – are they driving leads too?  Simply by using your campaign codes and SAINT (typical way to do it), you’ll be able to tie success events back to the campaign code (as it’s an eVar), and therefore you can see Leads by Campaign.

You’ll probably also want to do the same for Organic Keywords, and Internal Keywords and so forth.

Form Abandonment

The next level of analysis comes from understanding where in the form people are abandoning.  SiteCatalyst offers this functionality.  The steps are straightforward:

1. You need to use the plugin “Form Analysis”.  Simply copy and paste it into your s_code in the plugins section.
2. At the bottom of do_plugins function, in the s_code, you call the plugin using s.setupFormAnalysis()
3. In the config section of your s_code, you set the name of your form in the s.formList=”form1″.  Comma separate values if you are tracking multiple forms.
4. You make sure that you name your forms with whatever you put in the s.formList values.

With the above set, you should now be tracking form abandonment.  Each time a user clicks on the form but doesn’t complete it, just before they leave the page, the s_code will fire off to Omniture the name of the field they were last on.  If they submitted, you’ll see that too.  If they didn’t enter any information, that’ll be in the report as well.

Warning, the Form Analysis report is a little difficult to read though – so I’ll save that for another post.

So, it looks like I’m on the road again with a couple of presentations.

On Friday 27th Aug, I have the pleasure of presenting at the ADMA Digital Day in Perth.

And then, on September 21st and 22nd, I’m honoured to be presenting again at the Marketing Higher Education Symposium in Sydney.

I guess I have a couple of presentations and a morning workshop to put together…

Looking forward to both of them; looking forward to seeing you there.

As I’ve written in previous posts, internal search provides great insights into so many aspects of your site, and is one area that you should definitely focus measurement on.

Aside from the usual keywords that people are searching on, and whether or not those keywords lead to a conversion of some sort, there’s other measures that can be used to show whether your internal search is working.

For example, if you segment your audience type (as we do into Staff, Students and Anonymous traffic), you can see the different searches those audiences conduct.

Some measures to understand the effectiveness of search results would be:

• Time on the search page – a large amount of time would indicate they are not finding the result
• Search bounce – a high bounce would indicate poor results
• Number of searches per session – while not a direct indicator, could indicate poor results
• Keyword pathing – shows refinement of searches
• Number of Results – look for the zero’s in this one

Sometimes, no matter what you do, your organic search results just don’t cut the mustard – especially in a distributed content model where the content owners are less inclined or less experienced to think about SEO.  If you find yourself in this situation, there’s a number of different things you can do to help.  Half the battle though is realising that your natural search results are going to be poor (garbage in, garbage out) and any change is likely to be a slow burn.

One option to assist would be Omniture SiteSearch, which will allow you to do all sorts of things, including influencing results based on previous search data from SiteCatalyst, integrated with Test & Target…but we’ll save that for a future post.

Number of Searches

On the flip side, to get more insight, let’s look at the number of searches per session.

You can implement that very easily by using what’s called a counter eVar.  You simply want to know the number of times something happens, before something else happens.

In SiteCatalyst, you can create a counter eVar (simply select the type of eVar as counter).  Each time something happens, such as a search, we pass in the value of the keyword and we pass in a special value “+1″ to the eVar.

SiteCatalyst then allows you to see reports based on those different values.

Our internal search tracking code looks like this:

/* Internal Search Event Setting */
if(s.prop5&&s.prop5=="0"){s.prop5=""}
if(s.prop5) {
s.events=s.apl(s.events,"event1",",",1);
s.eVar39="+1";
}
if(s.prop5&&!s.eVar5) s.eVar5=s.prop5;


We set s.prop5 with the keyword on the search page – everytime a keyword is present.

eVar39 is our counter eVar.  It basically captures the number of times that we have searched for something.  Each time we do another search, the value in SiteCatalyst is incremented by 1 and then we end up with a report that shows the number of searches during a session (as we have set the eVar to expire on a visit).

So in this, albeit very limited result set, it shows that there were 184 searches on the first attempt.

There were 53 searches done on the third attempt, and so forth.

Interestingly (sadly), one search term was searched for on a 17th attempt – someones keen, but likely couldn’t find the result they were looking for, and they continued to search until they found some decent results.

You can also break down (providing you have full correlations on search terms), on each attempt to see what they were searching for.

In the instance where the person conducted 17 searches, the 17th search was for the term “vbs location”

I’ve also illustrated here that keywords can be broken down by the number of searches conducted.  In the example above, Bookshop was searched for 205 times in total, but featured as someone’s 2nd, 3rd, 4th and 5th search attempt (the none is because it’s got previous data prior to my eVar being put in place).

Monetising Search

For most companies, search conversion is key – revenue generation from search.  However, for the most part, our internal search does not “convert” to a sale of something.  It’s mostly used to find content, so we’re keen to understand what that costs us (not how much revenue is being generated).

If you’re looking for a way to calculate a cost for search, here’s a “back of the envelope” calculation…

The average time spent by Staff on our search results page is around 208 seconds.
The average number of annual searches by Staff alone is 124,600…
therefore…
25,916,800 seconds expended using search annually
= 431,947 minutes expended using search annually
= 7,199 total hours expended using search annually
(that’s a phenomenal number when you think about it… that’s 960 working days at 7.5 hours a day)

If the average cost per hour of a resource is $ 40.00
then…
$ 287,960 is the total cost of resources who spend their time searching

If you can decrease search time spent by just 10% (21 seconds), you theoretically save around $29,000 – or you increase productivity availability by 96 days…food for thought!

A few fancy calculated metrics in SiteCatalyst and you could probably put cost of search against each keyword for a specific audience as well…but we’ll leave that for now.

On the plus side, if you do the above, you’ll conversely be able to see conversions from search, enlightening you as to which search terms are driving revenue, or leads etc.

So, you can’t mix eVars and sProps right…  But you still want to know certain things like what pages were viewed from visitors conducting a search, or which campaigns are driving most page views – and you don’t have Discover.

Well, there’s two parts to this post and a bunch of answers…so read on.

Page View Success Event

Firstly, set up a Page View Success Event.

Relatively simple concept.  Set a success event every time a page viewed.  It will result in a report-specific count of pages (and should be very close to actual page views), BUT, you can see it on Conversion Reports…such as Campaign Reports, or Search Reports.

And it’s easy to implement into your s_code:

/* append page velocity to the existing event, or set a new event */
if(s.events){
s.events = s.events + "," + "event13";
}else{
s.events = "event13";
}

In the above example, I’m using event13 to be my Page View Success Event.  In SiteCatalyst admin, I’ve created the success event and called it Page Velocity.  The event is created as a Counter type event.

The code basically says that if s.events is already populated with a value, then append it with “,event13″.  If s.events wasn’t populated, then just set it as event13.

Don’t forget to use the comma…you don’t want to mess up all your production events do you.

Now, every time a page is viewed, s.events will be either appended to, or set distinctly.

Ok – pretty straightforward – and pretty boring stuff.

But now, let’s open a campaign report to start with and add the metric “Page Velocity” to it.

Next, I created a calculated metric – CT/PVs, being Page Velocity /  Click Throughs – a rudimentary engagement value.  What it suggests is that Organic traffic views about 5 pages per click through, versus nearly 14 pages from traffic that comes from Social Media sites.  In case you’re wondering how we got Social Media sites, we use the Unified Traffic Sources VISTA rule.  You can also drill down on this report through your SAINT classifications.

So, now we are able to see Page View counts against conversion reports.

Let’s take it one step further.

Page Views by Campaign

Suppose you want to see what pages they view by campaign.

By default, SiteCatalyst won’t allow you to see that, but there are plenty of reasons why you actually need it.  From campaign reports, to search keyword reports – you could benefit from knowing pages viewed by that segment.  If you don’t have Discover, this is one thing that is somewhat frustrating.

Ah, but you can do it, although it’s a bit more work, but let’s walk through it.

Firstly, you need to store PageNames into an eVar.  Once you’ve done that, you’re set.  It’s also best to create an s.prop at the same time you create the eVar.

/* Set the s.prop as Page Name*/
	if(!s.prop19)
	s.prop19=s.pageName;

/* Set the PageName eVar */
	if(s.prop19&&!s.eVar19) s.eVar19=s.prop19;

In the above code, I’ve used s.prop19 to set my pagename (so that I can use it in reports later).  I’ve also set my eVar19 to be the same as my prop19 (which is pageName)

Set these up in the Admin console as well in SiteCatalyst.   I named my conversion variable “Pagename (conv)”  so that I can distinguish it in segment managers.

Right, now you can breakdown your campaigns (because by default Campaigns have Full Subrelations enabled on them), by Page Velocity, and then by Pagename (conv).

For example:

So in the 5×5 example above, visitors from Organic Search viewed around 1.5 million pages, of which, around 200,000 were to our homepage.  Click on the Search Organic link in the report and you can drill down further.

Obviously, I’ve just used overall campaign traffic in the above example.  You can also drill down on your campaign reports, through your SAINT classifications to, say, a creative element, and see what pages were viewed from people who clicked through from that element.

Now, here’s another example.

Internal Search Traffic

Let’s assume you track your internal search keywords.  I know you all do, because they are a gold-mine of information. Make sure though that you track them in both an s.prop and an eVar.  Why?  Most people track them as just an s.prop, which gives you straight-forward counts of keywords.  But as an eVar, you can also then see conversions against those keywords, and, with the changes you’ve just made above, you will probably be able to see what pages are viewed following a keyword search.

However, you will need to set up Full Subrelations on your eVar.

The above shows that on a particular day, there were 242 page views following a search for the word “bookshop”.  The pages visited are shown in the image to the right.

So, through simple code changes, we’ve successfully managed to get some visibility on activity within conversion reports.

Hope that all helps.

If you’ve ever wanted to know bounce rates by different campaigns, or other segments, there’s a relatively easy way to do it in SiteCatalyst, which also brings other benefits with it.

Despite the fact that Bounce is not a native metric for SiteCatalyst, it’s easy enough to calculate it (single access/entries)…but as you’ll realise, you cannot use that metric on Campaigns (or any eVar for that matter), because they are traffic props.

So, to get Bounce metrics onto a campaign report, you simply concatenate your campaign code to a page name and store it into an s.prop.  The following is an example of that code:

if(!s.campaign){ s.prop26=s.pageName; }else{ s.prop26=s.campaign+"|"+s.pageName;}

In the example above, I’ve used s.prop26 to store the concatenated values.  In the Admin for the report suite, under Traffic variables, create s.prop26 as Campaign Pathing.

At this point, you should also call support, or use the live chat and ask them to enable pathing on that s.prop.  By doing so, you immediately enable the two metrics that you’ll need to see bounce – single access and entries.

Once you’ve done that, everytime a campaign code is seen, it will be stored into s.prop26, followed by the page name.  Bear in mind this only occurs on the first page that the user visits.

Campaign Bounce Rates

Now you’ll be able to create a report that shows campaign codes and their respective bounce rates:

As the above report shows every instance of the s.prop, you can then filter on either a specific campaign code, or on a specific page name.  So for example, if you run multiple campaigns to a product page, simply filter on the page name.  You’ll get the added benefit of seeing “non-campaign” traffic to that page too.

That’s not the only benefit to concatenating s.props together.  You could do the same thing for different segments to understand how they interact with your site.  For example, you could put Visitor Type at the beginning, Customer or Non-Customer; or any combination really.

Just remember that there is a limit to the amount of characters that an s.prop will store…and you don’t want to exceed the 500,000 unique monthly values on s.props either.

There’s another benefit to this.

Campaign Pathing

Campaign pathing now works…you’ll now be able to see pathing from specific campaign codes (or the other segments you have put in there).

Simply create a pathing report to see where people go when they come in from a specific campaign code.

Despite the fact that the subsequent pages don’t contain the campaign code, you can be assured that they represent the traffic from the same segment that started this journey.

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.

One of the little-used nuggets in SiteCatalyst is “participation”.

It’s a given that you want to know how many sales you’ve made, or how much revenue you’ve generated, but what about which pages have helped to contribute to that conversion.  Not every visitor follows the same path through the content, and it’s therefore beneficial to be able to see which pages are more likely to drive a conversion than others, thereby exposing your most valuable pages.

And some surprising results may surface; some pages that you thought were key pages, may not be; others that you thought weren’t, may well be contributing more to the purchase or conversion event.

Armed with this knowledge, you can further optimize your site.

Enter Participation

Basically, this little-used metric helps you to assess whether your content is participating in conversion events or not.

There are in fact two metrics that can help – linear allocation or participation (I prefer participation).

Linear allocation provides each page or variable value that contributes to the completion of a success event (e.g. revenue or cart additions) with a partial credit for the conversion. For example, if a user navigates through five pages of your site, and the visit results in a purchase, linear allocation divides the 1 purchase across each of the five pages so that each page receives credit for 0.2 of the purchase.  If conversion is enabled, then allocation for pages is also automatically enabled.

The downside to this type of allocation, in my opinion, is that you don’t necessarily see the true value.  If there are two visitors and two purchases, but one visitor sees 4 pages and the other visitor sees 2 pages, the allocation can get confusing…especially when you multiply that out by the variations of pages, visitors and the path length (number of pages they viewed).

Participation metrics, on the other hand, assign full credit to each page or variable value that contributed to the conversion. In the example above, a visitor navigates through five pages of your site, which results in a purchase. A participation metric gives credit to each page used in the purchase process. If any events have participation enabled, then the pages participating in the event also have participation enabled.

The result would be that “1″ is assigned to every page they visited (even over multiple visits).  Eventually what surfaces, is high value pages – those pages that contribute the most to a visitor purchasing something.

Looking at a real world example of this, the following shows Applications Submitted Participation metric, against each page, with Page Views and Page Bounce Rate.

In the above report, the top performing page that contributes the most to applications submitted is a page of content describing the application process.   Almost 52% of visitors who have submitted an application have gone through this page.

I’ve also created a custom metric – App Submitted Conversion Rate (Participation / Visits), which shows that nearly 6% of visits to that page result in an application being submitted.  So that, for us, is a key page.

What’s also apparent is that #8 has a relatively low participation rate (14.1%).  That page is one of the “parent” pages to the best performing page, which indicates that the path that is being followed does not take people through the parent page, otherwise, the participation would he higher.  (That makes sense to us as we drive people to the top performing page from a multitude of sources, such as course pages).

Using a pathing report, we can also validate that assumption, as we can see where they came from and where they went to on their journey for this key page.

Participation also crosses multiple visits – providing your configuration is set to ensure that cookies don’t expire on the end of the visit, so you’re then able to see how many times people return before they submit an application, or purchase something.

To some extent, the above result is expected (and desired).  Likewise for the homepage (#2).  Looking down the list, it’s a little surprising to see that the search page (#9) actually beats out some of the other pages, from a participation rate, but not an overall conversion rate.

So, it would be interesting to find out what they are searching for…

Slice and dice with Omniture Discover

Using Omniture Discover, we can dig into this data further.  Discover helps you answer the questions that you ask when you get the first answer – because the answer inevitably leads to other questions.

So, based on segment which we created on the fly called “visitors who have submitted an application” we can see what search terms they are using.  The results are shown below:

And what we see is that 25 applications were submitted from people searching for “honours” – which is interesting because honours content is not readily available on our site.

Learnings from Participation

Using Participation metrics can help determine the “value” of pages.  Pages that have low participation rates (that you think should have higher rates) are often good candidates for further optimization to assist in the conversion process.  Likewise, the same goes for pages that have low overall conversion rates (from the calculated metric).  Only you’ll know which pages they are.  Participation can be viewed as a kind of re-enforcement of the path you anticipate them to take.

By using Participation, you can determine the unbiased influence of any page on success and use it to further optimize your site.

Albert Einstein once had a picture hanging on his wall at Princeton that read:

Not everything that can be counted counts, and not everything that counts can be counted.That picture should be up in every business optimization unit across the globe.

I’ve often said just because you can, doesn’t mean you should.  And in many cases, you just plain can’t.

Despite the capabilities of many web analytics applications, sometimes the things that count just can’t be counted by web analytics.  For example, User Experience (did they get really get what they wanted) can’t be counted through web measurement.  It may well be answered through a variety of other methods, such as focus groups or qualitative research, but sadly web analytics can’t provide the answer.  Yet.  Maybe one day, when we’re all chipped, chapped and chafed, and tracked from pillar to post, but in the meantime…well, you get my drift.

Unfortunately, in many cases, companies still measure absolutely everything, report on way too much, and get nothing out of it.  They end up with analysis paralysis, which devalues the optimization proposition.

In a survey conducted by eConsultancy in 2008, 78% of companies don’t tie their data collection strategy back to their business objectives.  Staggering.

Not everything that can be counted counts

It’s vitally important to stick to business KPI’s.

When you’re driving your car, you only want to know a few key things; how fast you’re going; how much fuel you’ve got left are typically your two KPI’s.

On a day to day basis, you don’t need to know how much oil you have in the bottom of the engine; or the temperature of the coolant; or your tire pressure.

So what makes you think that your stakeholders want all that information?

Think about who you are providing insight to.  If it’s your CEO or CMO, think of them as the driver and structure your reports accordingly; your web team might be the mechanics, so they want to know how much oil is in the engine and how hot it is.

What’s important is that you pick out the few key performance indicators that are tied to the business objectives (and campaign objectives) of the stakeholder – and they get narrower the further up the chain you report.

Your CEO probably won’t want to know CPC for an online campaign, but they probably will be interested in how many sales have been generated off the back of it.  Your CMO may be interested in CPC, but probably not (too much information).  Your campaign manager will be interested though, so they can continue to optimize the campaign.

Not everything that counts can be counted

Here’s a tricky one to measure…a TVC brand campaign and it’s effectiveness at driving sales.

Now, don’t get me wrong – there are things you can do that will help, such as vanity URL’s that redirect to another URL so that you can measure traffic through the original URL.  But still, it’s a tricky one.  Despite the advancements and sophistication in the technology, there is still no way to fully integrate offline and online reporting.

Einstein often referred to that picture.  He was a smart cookie; and it definitely rings true for web analytics.

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.

Bit of surprising news, Adobe is buying Omniture for $1.8billion.

Still taking this in and many thoughts running through my mind at the moment.  Seen Adobe purchase a few companies in the past and the results have been varied.  They are, after all, a product-based company, offering little in the way of services.  Omniture on the other hand, is a service-based company.  Very different business models, very different thought processes.

I wonder if Omniture will keep their name too…?  They have a massive brand equity  ($1.8billion) so it would be a shame (I think) to see that dissapear to something like Adobe SiteCatalyst.

And I wonder too if they retain autonomy over the direction of their offering?  I see that they are to become a business unit of Adobe, with Josh James as the senior VP of the new business unit.  I hope that they will continue to develop their products and services at the speed that they have us all accustomed too.

And I really hope their services don’t get impacted.

Interesting times lay ahead for Omniture.  Interesting times, I’m sure, lay ahead for their customers too.

Please, keep us all informed on plans, impacts, directions, etc.