I’ve come across a few clients now that either aren’t using SAINT, are using it in a limited way, or are using it for campaigns only.  Maybe people are confused by what it does, or daunted by it, or just don’t know what it can be used it for.  It’s got uses that extend way beyond campaigns.

So, in this post, I’ll re-cap a bit about what SAINT actually is, and how it can be used, across a whole multitude of things.

And classifications can be used for millions of records.  We recently uploaded a very large list of customer ID’s and segments per customer, which enables some fascinating insight into customer behaviour.

SAINT – the acronym

To get this out the way, SAINT stands for SiteCatalyst Attribute Importing and Naming Tool.  It’s a way to classify a SiteCatalyst variable into more meaningful terms, and enabling you to group them together in certain ways.

What’s a Classification?

Basically, when you “classify” a SiteCatalyst variable, you are extending the information available on that variable through additional meta-data. 

Classifications are most frequently used on campaigns.  When you run a campaign you track it through a campaign code – a unique code that you set to identify that specific campaign element, such as “eml123”.  You add the tracking code (typically in the format www.youdomain.com/page.html?cid=eml123) to a link that’s driving traffic to your site.

Your s_code is most likely looking for any page query string to contain the parameter “cid”, and once it sees it, it’ll put the value “eml123” into the s.campaign variable.

It only needs to see it once…typically on the landing page.  As long as it saw it and recorded it then you can see success events further down track, tied back to the campaign code.

Looking at your campaign reports, you’ll see one called “Tracking Code”, and in there, you’ll see all of the unique values that have been passed through the s.campaign variable.

But by themselves, they’re pretty difficult to read.  “eml123” doesn’t mean much to anyone.

So what if you want to view them by type of campaign, or source of clickthrough, or media type etc.  Do you need to create a new conversion variable for each one?  No. 

This is where classifications come into play.

You can simply tell SiteCatalyst, through SAINT, that there is additional information that represents the unique campaign code, and using that information, you can view reports and conversions by the extended data, slicing and dicing to your hearts content.  Obviously you need to upload that data using the SAINT template, but that’s all pretty straightforward.

So, what else can it do?

Well there’s plenty of things that can be classified. 

We’ve used classifications across a broad spectrum of values, including:

• Products – the obvious one, classified into category, sub category, manufacturer, supplier, etc
• Internal promotions – the next most commonly used one, classified in the same way (generally) as external campaigns
• External Search Terms – classified against branded or non-branded terms
• Internal Search Terms – classified against type of term, such as product, information, support, sales etc
• Customers – classified against customer demographics, business segments, locations, products owned, mosaic segment etc.
• Behavioural Segments – classified against profile characteristics (such as described in Moving Beyond Business-Based Segmentation)
• Videos – classified against genre, length, player etc.
• and the list goes on…

If you’re using multiple eVars to capture similar information, or information that is essentially meta-data to do with another eVar, then you should be using SAINT to classify from a single eVar.

And it’s not just eVars that can be classified.  Traffic props can be classified too. 

Use Hierarchies

I’ve also come across plenty of clients that don’t have the hierarchies configured.  To configure hierarchies is very simple using the admin.

The benefit to hierarchies is that they allow you to view rolled-up metrics, and then allow you to drill-down into your chosen hierarchy.

Once you apply a hierarchy to your classifications, your menu structures change to support that hierarchy.

The most common use of hierarchies is within campaign structures, but they apply to all classifications.  Below I’ve shown the resulting menu structure for Murdoch’s equivalent of products – courses:

Once you open a report, for instance, Course Area (shown below), you initially see the rolled-up metrics.  Once you click on the + sign, you drill into that classification to report on the next level.

So, if you don’t see the classification drilldown in your menu’s…

…ask your admin to classify as it will surely help in your day to day reporting capability.

This topic was requested by one of my readers – thanks for the inspiration Dan. 

And it comes back to segmentation.  And the value derived from measuring your customers/members behaviors across your digital channels, and the impact they could be having on your conversion rates if you don’t segment.

Ok, so, we’ve all likely got some form of customer – either a lead, or a customer who has purchased, or a member, such as a policy-holder or a service-holder.  For the purpose of this post, I will call members, customers.

Why do we want to measure their activity?

Well there’s a number of reasons.

If we run a self-service site, we might want to know what self-service transactions are being done beyond the login (within the customer self-service portal, nowadays commonly called My{something or other}).

That’s pretty straightforward and you can achieve that with traditional metrics if you are reporting solely within that “site”.

But customers are not all the same.  There are business customers, there are residential customers, there different types of customers within each of those segments – business types, business size, residential locations, MOSAIC-based classifications of customers, demographics and so forth.  And guaranteed they will do stuff differently.  They purchase different products and services.  They’re interested in different content and so forth.

And many self-service sites are purely transactional in nature – change your address, update something or other, check usage of something or other etc.  Most of your content will be on the “outside” and these guys use that content too.  But they have a closer affinity to your brand and will use that content differently.

And the other big thing about them is, they’re customers.  They’ve converted.  Not only are they your golden opportunity to

a) cross-sell/up-sell and
b) observe their activity and figure out why they converted so you can better optimize

but (and possibly more importantly) unless you measure their activity, they are negatively impacting your conversion rates on your regular website and your average revenue per visit is understated.

Huh? Why?

Because they probably go through that site to get to their My{something or other} self-service site.

Consider this:

Let’s say you’re an insurance company.  Your acquisition team wants to know the sites conversion rate for product sales and the average revenue per visit.  You also have a self-service site and the way that most of them get to that site is through your regular homepage.  Suppose your overall traffic to your site is 350,000 visits per month and you get 10,000 product sales per month, with revenue of $500 per sale.  Suppose also that 200,000 visits per month go to your fabulous self-service site where they’re busy updating their info, checking on their policy and so forth.

If you DON’T strip out known customers, you’re under-reporting. 

Your average order value is unaffected – it’s still $500.  But your visit conversion rate is showing as 3%, and your average revenue per visit is $14.29.

If you strip out the known customers, your conversion rates just went through the roof.  It’s now 7% (10,000/150,000) and the average revenue per visit is $33.33 ($5,000,000/150,000).

Ok, a little extreme maybe, but you get the general idea.

So, measuring customers not only provides more accurate conversion rates, but also gives you better insights into their activity.

And SiteCatalyst allows you do all that – and more. 

Customer segmentation

Right, so you want to measure customer activity for a variety of reasons.

For basic customer segmentation, you’ll need an eVar and an s.prop and one or two success events.  The eVar will enable visibility of conversions back to them (revenue and the likes); the s.prop is used to segment your traffic-based reports by customer/non-customer type and the success events are for things like logins, failed logins etc.

If you’re measuring self-service activity, you’ll have another eVar for self-service transaction type and a counter success event.  These two are set every time the user completes a transaction.  You pass the type of transaction to the eVar and set the success event.  All pretty much no-brainer stuff.

If you really want to get value, you’ll also use an eVar to capture their memberID, userID or some other unique value that can be used for customer-type segmentation.

Basic segmentation – customer/non-customer

When a user does something that only a customer can do, or if they make a purchase, you set the eVar as “customer” or something similar.  You also set the success event, such as login, if that’s what they did. 

You will also need to set the s.prop to “customer” and you need to make sure it’s remembered and set again on every single page view.

The way to do this is through the getAndPersistValue plugin – a handy little plugin that will set a traffic prop automatically from a value in the cookie.

For example:

Let’s say that you have a My{something or other} self service site, and the user logs in.  Upon login, you would use the following in your s_code:

/* My Self Service Login */
/* Set User Type */
if((s.pageName.match(/loggedin/)){ // change for your page
/* serialised login and self service success success event*/
s.events="event1,event2";
s.eVar10="Customer"; // Customer Non Customer
s.eVar11="Login"; // Self service transaction name
}
/* Check existence of persisting prop10 - user type */
s.prop10=s.getAndPersistValue(s.eVar10,'s_prop10',365);
if(!s.prop10&&!s.eVar10) {
s.prop10="Non Customer";
s.eVar10=s.prop10;
}
/* Set persisting prop10 to value of the eVar10 */
s.prop10=s.getAndPersistValue(s.eVar10,'s_prop10',365);


Basically what happens is when the user logs in, the eVar is set to Customer.  The success events count the number of successful logins and also a general self-service transaction count.

Line 8 says set s.prop10 from the value of eVar10 and store it in a cookie for 365 days. 

Under non-logged in status, eVar10 will be empty, so line 9 is true (eVar10 has no value but s.prop10 may have a value).  If that’s the case, set it Non Customer and set the eVar to Non Customer.

Then line 14 re-evaluates s.prop10 from eVar10 and resets itself.  Odd I know, but it works.

You end up with a number of different states:

1) For non customers eVar10 and s.prop10 = Non Customer

2) For customers in the same session, eVar10 and s.prop10 will be Customer

3) For customers in a later session, eVar10 and s.prop10 will be Customer (because of the getAndPersistValue)

A word about the success events:

I’ve used two success events – event1 as a discrete count of logins and another as a general count of self service transactions.  You could combine, but I like the separate count and you can serialise the login event so you only count it once per session – giving an idea of true logins, rather than repeat logins per session.  The self-service transaction type (eVar11) would generate a report of all the different types of transactions by customer type, when viewed using the Self Service Transaction event (event2), or specifically logins (event1).

The Result

Now you have the capability to report on not only logins and self-service transactions types, but also your conversion rates are more representative of real rates by Non-Customers (and Customers – very important for retention purposes), and you can see their behaviors across pages when you use the s.prop. 

In v15, or with Discover, you can create and use these two segment values for more analysis to filter out or filter in based on Customer or Non Customer.

Of course, the next thing you’ll want to do is further enhance your Customer segments with demographics, or those additional business segments, using extracts from your customer database.  Take a look at 1 million rows and it still wants more, for an understanding of how that works.

So, segment, strip out your non-customers and re-run your conversion rates.  Now do the same for customers.  And now start looking at what customers did prior to conversion so you can influence those non-customers to do the same thing. 

My final tip…use Test&Target to provide more relevant content to Customers or Non Customers…because, now you can identify them.

Well, it’s August and true to their word, Adobe upgraded us to SiteCatalyst v15 on the 1st, and so I thought I’d share a few of the golden nuggets within v15.

I was thinking about how to order them…do I go by not bad to flamin’ eck, that’s awesome? Or start with the big bang and then let it continue to smoulder throughout? 

The problem is there are too many new and great features that you can’t really put them in any type of order.  They appeal to you on different levels, from functionality, to UI, to analysis, to reporting, to combination segmentation and sub reporting.

And as this post is kind of huge (sorry you might a coffee and a bagel on this one), here’s a little taste of what’s covered in it:

•  Segment, the all powerful segmentation
•  New segments
•  Site Overview Report
•  Segmented Overview Report
•  Side by Side segments (well sort of)
•  Key Metrics report
•  Normalization (one of my new best friends)
•  Visits, Visitors and PageViews
•  Full Sub Relations – multiple breakdowns on eVars
•  Traffic prop breakdowns
•  Login as another user
•  Calendar events specific to report suites
•  Significant changes

So let’s start with the big one that everyone knows about, or at least should.

Segments

Unless you’ve been living under a rock for the last 5 months, you’ll have heard about the segmentation capability within SiteCatalyst v15.

Out of the box, it comes with 7 pre-defined segments that are shared across SiteCatalyst, Discover, and Test&Target.

These segments were chosen because, according to Ben Gaines at Adobe, they are “valid (and important!) for all of our users—across vertical and market size. We’ve also seen these types of segments predict different behavior across a variety of actions: registration flows, purchases, and general site browsing.”

New Segments

You can, of course, create your own segments on the fly and apply them to any report as well.  If you’re a Discover user, you can create them in Discover and save them back into SiteCatalyst for later use.

I’ve not yet figured out how to create a segment available across all report suites, without creating it in Discover.  Perhaps Adobe can help on this one?

Segments can also be used in Test&Target too. There’s a one-click little target icon next to the segment box which opens up a new A/B..n campaign in Test&Target, although it doesn’t specifically target custom segments that you’ve created as that’s a little more complex – but the preconfigured ones are available for use immediately.

Site Overview report

This new report is actually a dashboard, but, it’s highly useful and can be modified to your needs.  Using the same features as dashboards, you can set this one to your landing page when you log in (no more pinwheel).

From those reportlets, you can get to the main report by clicking on the name of the reportlet.

You can also change the date and the whole thing will rerun against the new dates.

Segmented Overview

If you want to see a particular reportlet using a specific segment without running the whole dashboard again, just click on the report suite name within the reportlet and a little popdown appears, allowing you to select not only the report suite, but also a segment to use.

When you select a new segment, it will re-run the reportlet, not the dashboard, against the new segment.

Of course if you want to run the entire dashboard against the new segment, then just select the segment in the main segment dropdown and you’ll get instant gratification.

Side by Side Segments

Ok, so you still need Discover to do comparative segmentation, but, there is a sneaky little way to show two segments at the same time, using a dashboard report.  Generate your base report, for example, I’ve used calculated metrics on the new Key Metrics report (see below for more info).

Then apply a segment, and add it to a dashboard.  Apply another segment and add it to the same dashboard.

Then go to the dashboard layout editor (which is also new), and just put both reportlets into the new dashboard.

What you get is a visualisation of the two (or more) segments, plotted over time.

Key metrics report

One of my personal new favourites here is the Key Metrics report, which allows you to put multiple metrics on a time-based report.  This was always one of the big challenges before, but, they listened to us, and here it is.  And there’s a bunch of nifty things about this report that I just love!

Firstly, as shown above, you can add multiple metrics, or calculated metrics to the report – something you could never do before.  For instance, you can add Visitors, Visits, Page Views, Conversion Metrics, Conversion Rates and so on.

Now that you’ve got the key metrics trended side by side, every worthy analysis ninja will look to segment that information – so, just go ahead and apply those segments.

One of the great things about this report is you can do calculated metrics too…side by side (see the image for side by side segments above).

Normalization

Ah, what a great idea this was.  Normalize your data on the Key Metrics Report.  As you can see from the above screen shot, the page views data is overwhelming the trending report, making it difficult to view some of the trends for the other metrics.

But that’s ok now – just normalize it.  Same report as above, just normalized.  And the other metrics pop up.

Ok, so those metrics that I’ve used don’t really tell us anything.  How about this one then?

I’ve highlighted dates when certain metrics weren’t in line with the norm.

Now you have something to go and look at.  Why, on those dates, did those metrics “pop”.  What did you do?  Did they vary by segment?  And what can you do to nudge those that didn’t behave similarly?  You can learn from that.

Love this report.  One of my new best friends.

Visits Visitors & PageViews

Yes, these are now available across most conversion reports.  You used to be able to get Visits and Visitors by special request, but now, they’re enabled and you get Page Views as well.  And they’re particularly useful across things like campaign reports, referring domains, search engines, keywords etc.

Full Sub Relations – multiple breakdowns on eVars

Remember the days when you had to think carefully about setting up subrelations on eVars…should you use Full or Basic?  And remember the impact if you got it wrong, or realized later that you needed Full Sub Relations on a key eVar?

Well, those days are gone.

You now get full subrelations on all eVars (although I don’t quite understand why the admin asks you still for the type of subrelation you want when you create an eVar – Omniture…can you add any info here?)

In this example, I’ve used two eVars, both are set up in the admin as Basic Subrelations, but I’m able to now break one down by the other, and then I’ve added a filter to remove the keyword “murdoch” from the report.  As you can see, it’s a conversion report, with Unique Visitors, Visits and Page Views, as well as success events.

Once again, you can sub-segment this report against any of your existing (or on-the-fly) segments. Yay!!!

Traffic Prop breakdowns

Another great feature is the ability to now breakdown key traffic props, such as the referring domain report.  It used to have basically “instances” and allowed you to put in success events.

No more.

Now you can not only see Visits, Visitors and Page Views, as well as success events, but you can also now break it down by things like Average Time on Site, and, all eVars…wow!  Couldn’t do anything like that in v14.

And you can flip it too…start with a conversion report, such as our Figure Out Your Life segments, and you can break them down, by Referring Domains, or Time Spent per Visit etc.

Ok, long post I know, but, there’s so much going on that I’ll probably add more posts in the future on the new features.

Just to touch on some of the other new things as well…

Login as another user

Do you have a user that’s experiencing problems?  Well, now you can log in as that user.  Go to the admin and views the users, then click on “Login as this user”.

Report specific calendar events

One of the problems with SC14 calendar events was that they showed up across every other report suite…which made it very unhelpful to users that had somewhat restricted views, such as global sites and regional sites.  The UK office didn’t really care that you ran a specific promotion, but they saw it anyway.

Now you can apply a calendar event to a specific report suite only.  To be honest, the link for it is a little tough to spot, so I’ve put a whopping great big arrow to it:

Ok, now I’ve covered the things that I’m excited about, there are a few things that new users need to understand with this version.

This has all come about because of the way that data is stored.  It used to be pre-processed into the reports, which resulted in the limitation on segmentation and other capabilities such as breakdowns.  But Discover always worked off the original unprocessed data, which also led to some differences in the data, especially around unique visitor counts and classification deduping.

SiteCatalyst v15 now runs off the raw data – the same as Discover, so the datasets are the same, hence the reports are the same.

Key Differences

There are some key differences between v14 and v15 that you need to be aware of:

Visits for Non-Cookied Visitors

All visitors, regardless of them accepting a cookie are now included in Visit counts and pathing data.  But this increases your Visits metric, so your conversion rates will likely go down a bit.  In testing, the increase of visits was about 0.5% for first-party cookies, and 5-12% for third party cookies.  Another great reason why you should be on first party cookies (contact your account manager if your tracking server has 2o7.net in it).

Time Spent metric 

Both the time spent per visit and the average time spent on page metric now use all server calls to generate the metric, which is much improved on SC14.  What this means is that non-page view data is included in time spent reports, such as custom links etc.  And, they’re no longer bucketed.  It now works off an average for each and every individual page view.

De-duplicated Visits and Visitors in Classifications 

Classifications are now correctly de-duplicated, meaning that when you group things using classifications, they are now de-duplicated, whereas before, they would count each instance of a visit or visitor.

Ben Gaines wrote an excellent blog post about these and a couple of others which is definitely worth reading and getting to grips with.

Summary

What can you say?

Thank you, Omniture Business Unit within Adobe, for listening to us.  These changes make the platform even more useful than it already was and clearly makes it a powerhouse in the web analytics space.

With these, and many other changes made, we’re able to provide our organizations with even more insights that lead to more business optimization capabilities, a better ROI and hopefully more analysis ninjas.

Thanks guys!

So I promised that I would finally put fingertip to keyboard and talk a little bit more about using Visitor Scoring…to finish up the series that I started a while ago.

If you’ve read my previous posts, you’ll know that we implemented a series of metrics for engagement measurement, culminating in a per-visitor score.

I wanted to share with you some of the insights and benefits of doing all of this, particularly in Discover.

An Engaged Segment

If you remember from the previous post, we talked about using a total of seven different metrics to try to ascertain engagement, or, when used in combination, could identify an engaged user segment.

The final metric was a measure of interaction and there were two ways to implement; either by just counting the number of visitors that participated in specific actions on your site, or the second way; by creating a scoring methodology at the visitor level and leveraging that as the final metric.

A little tougher to do, as it involved some additional code across the site, but definitely implementable, and now, we’re able to use that information to gain even greater insights.

The reason you should segment is because not everyone on your site converts – in fact, probably only around 3-5% actually do what you want them to do.  So you use segmentation to analyse those that have converted and try to understand what made them different, what their different behaviours were, and if possible, try to use that as predictors of future behaviour by the other 95-97%, so that you can lift conversions.

Creating the engaged segment

Using Discover we created a Visitor container that contained the following rules, which we had previously determined worked best for our business.

The rules applied are from 6 of the original 7 indexes that defined engagement for us:

1. Click Depth Index – which captures the contribution of page and event views
2. Duration Index – capturing the contribution of time spent on site
3. Recency Index – which captures the visitor’s “visit velocity”—the rate at which visitors return to the web site over time
4. Loyalty Index- the level of long-term interaction the visitor has with the brand, site, or product(s)
5. Brand Index – the apparent awareness of the visitor of the brand, site, or product(s)
6. Interaction Index – visitor interaction with content or functionality designed to increase level of Attention

Notice the counts at the bottom of the segment creator – those seem to be a bit confusing as the number on the left (216 Visitors) represents the number of visitors that meet the criteria of the segment, but the number on the right (1,071,458 visitors) does not appear to be a count of visitors for the timeframe (for some reason I have yet to figure out).

Additionally, for this particular segmentation example, I wanted to ensure that our engaged visitors have actually become a lead (one of our primary goals).  So our segment includes that, as well as them having a score of greater than 200, which means they’re interacting with a fair amount of content or doing a fair amount of activity (such as applying to come to study with us).

Saving the segment, it’s then ready for use.

Using the segment

One of the first things I looked at was where our engaged users were coming from, their average scores, conversion rates and application rates (or purchase rates), compared to all visitors who are not staff or students.

And I fell off my chair.

While the number is quite small comparatively, due in part to the timeframe I’m using, the score, lead conversion rate (leads/visitors) and application rate (applications/visitors), are significantly higher.  This is to be expected due to the segment, but I wasn’t quite expecting the numbers to be that high.

Visual Site Analysis

I was keen to understand, visually, where these highly engaged users go on our site, so I used the Pathing Site Analysis report in Discover (one of my personal favourites).

Firstly I started with all visits to get a sense of what they do across common pages that we want them to interact with:

Fairly widespread usage of key pages.  The thickness of the arrow indicated volume of traffic from one page to another – the bulk of traffic goes to the Courses homepage, from the site home page.

Next, I applied the same engaged segment:

Ok, I must need velcro pants because I fell off my chair again.

It appears that our highly engaged users take a whole different path.  The colour indicates their propensity to become a lead.  The big red steps are basically the lead capture process through our main tool – Figure Out Your Course.

And they seem to browse around first within courses then become a lead – which is also good to know.  But once they become a lead, they tend to leave the site – which means we need to ensure that we’re effectively communicating with them through other channels, such as email at a later date.

Breaking down the traffic sources

In breaking down the Organic Search by time spent, we also see that a significant portion of highly engaged visitors spend more than 10 minutes on the site, and are more likely to convert to leads having done so, as compared to all visitors – another significant insight for us to use.

In summary

This is just one example of many that could be used on your site.  Once you’ve identified your engaged users, you can segment them further by demographics, or by customer type, or by content viewed, or by member/non-member and so forth.

You can view revenue by engaged/non engaged (bound to be vastly different), or average order value etc. 

If you use Test&Target, you’ll be in a great position to leverage the engaged user segment, targeting non-engaged users differently to increase their engagement levels.

All of this will help you gain better understanding into their behaviours, so that you can then further optimise your site to improve those conversions.

I’m keen to hear from others that have used Visitor Scoring, or Engagement Metrics across their site, coupled with Test & Target to lift conversions.  Let me know what your thoughts or successes are.

While this might be a quickie, it’s a biggy.  A big one in terms of the amount of data just uploaded through SAINT.  In fact, we’ve just uploaded around 1 million rows of data, with 6 columns per row.

And it didn’t even blink!  Gotta love that!

So why do we have a million rows of data?
Customer segmentation of course.

This was actually done for one of our other clients.

The rationale?

To segment conversions and transactions by customer type, segment, previous segment, needs group etc.  And SAINT enables that capability.

How?

Firstly create an eVar that the raw identifier will go into.  This might be an account number, a customer ID etc.  Then, using the admin, create the classifications on the eVar for the relative columns you need.  At this point I always create the classification hierarchy as well, just so I can envision how I want the data to be reported and drilled down though.

When you create the classifications, the SAINT file is also created and made available for download.

I opened the SAINT template in Excel and copied my customer segment data into it in blocks of 100,000 records.  There’s a number of reasons for this, not the least of which is to keep the file size down, but also to make it easier if an upload does fail – at least you can deal with 100,000 rows better than 1 million rows.

So I’ve now got 10 files, each file contains 100,000 rows and 6 columns of data per row.  Each file was about 5mb.

You can’t upload that much data through the browser, so you need to use the FTP Import capability.

In the SAINT admin, select Import File, click on the FTP Import and then Add New:

You’ll then get a popup that asks you to select a bunch of things to create an FTP account:

Select the data to be classified, move the report suite or suites to the box on the right, select the import options and add in your email address.

Check the box and hit save.

A new FTP account has just been created on the Omniture servers and you’ll get a confirmation screen showing the address, username and password.

Open it up in an FTP client and upload your SAINT files to the FTP server.

You’re not quite done yet though.

You also need to create a series of empty files, with a .fin extension, named exactly the same as your SAINT files.  These are “finish” files and are crucial to the upload.  They’re completely empty files – any text editor can create them.  Just make sure they are named exactly the same, case sensitive.

Upload those .fin files and you’re done.

Now, go have a coffee, have some lunch or dinner or whatever and come back later.

Progress

You can kind of check on progress by refreshing the FTP list of files.  Omniture removes the files from the FTP directory when it begins to process them, so you can kind of get an idea of where things are.

Time Frame

I uploaded the files around 4pm. 

At 10:30pm I did a data extract by FTP of all data to see where it was up to…it was done.  Shortly thereafter, I got an email saying it was done, without any failures.

Easy as pie.  No muss no fuss.

While we’re using customer segments, it could just have easily been customer demographics, technographics or any other form of data.  The point is, 1 million rows and it didn’t even blink.

There’s a few things to watch out for though when importing that much data.

There is a limit on the amount of unique values (500,000) that will be reported against in a given month.  We’re ok – we won’t see that limit.

Recommendations are that file sizes be kept under 30mb for the initial load, and then subsequent refreshes less than 5mb.  So we’re still ok.

And the import time will vary depending on many things, including how busy their import routines are.  You get in the queue and everyone loves a queue.

But that was it.  1 million rows of customer data now available for segmentation nirvana in SiteCatalyst – and DataWarehouse, and Discover, and Test and Target.  We’re off to the races!

And while the first run of this was a manual run, future updates can easily be automated now that the FTP site is created.  Just remember your .tab and .fin files must be named the same.

This is a follow on post to my previous one about measuring that elusive engagement.  This post focuses on the aspect of applying a score to visitor interactions, as they interact with your content and applications.

Visitor scoring is fairly simple – especially in SiteCatalyst, and by leveraging the data in Discover through segmentation, (and ultimately in SiteCatalyst 15), it’ll give you even more insight into visitor engagement.

Visitor scoring measures and assigns a relative value to individual customers and prospects based on their actions and behaviors over time. You can determine intent and engagement – even before visitors convert.

Once you’ve identified your most valuable visitors, you can dissect their actions to determine the campaigns, keywords, referring sites and offline touch points that engage them – and invest more on these efforts.

Scoring

The basic premise of a visitor score is to give them “points” for certain activities.  What score you decide to give them is entirely up to you…the important thing is that they accrue points over time, and you can use those points to create segments of visitors that have exceeded certain thresholds.

In doing so, you’ll be able to compare different visitors, for example, those with a high score, to those with a low score, from different traffic sources, or across different campaigns.

The theory behind this is that visitors with higher scores are likely to be more engaged – they’ve accrued more points over time, by doing the things you want them to do.  It’s not just looking at conversions, although they will probably feature in your scoring methodology.

Imagine for a moment that you have a number of visitors:

Visitor 1 – comes to your site from Organic search, looks at 5 different products, watches 2 videos, signs up for your newsletter, but doesn’t buy anything.

Visitor 2 – comes to your site from Organic search, looks at 1 product and buys it.

Visitor 3 – comes to your site through an email campaign, and views 8 of your products.

Visitor 4 – comes to your site through Paid Search, looks at searches for a product, views it once and then looks at 3 FAQs.

Which visitor is more valuable to you?  Who is more engaged?  Visitor scoring will assist you to better understand the answer to that – and when you slot this Visitor Scoring methodology into the Interaction Index, and use Discover, you really do get a good proxy for engagement.

Ultimately most sites exist for a specific reason, whether it be to convert the visitor to a purchase, or allow them to self serve, or engage them with your content etc.   And we all want them to do that.  But only a small percentage will.  In fact, in general, it’s around 3-5% of visitors that actually “convert”.

First things first

What you need to do initially is agree on a set of interactions across your site, and then apply an arbitrary score to them, either between 1 and 10 or 1 and 100.

For example:

1. Home page viewed or Landing Page Viewed = 1 pt
2. View a general content page = 5 pts
3. View a Product = 10 pts
4. Search = 20 pts (I tend to think that if a visitor is going to take the time to search for something they can’t find, they’re more engaged, hence the higher score)
5. Watch a video = 30 pts
6. Use an interactive tool = 40 pts
7. Sign Up for a newsletter = 50 pts
8. Provide feedback/rate and review/comment = 75 pts
9. Buy a product or conduct a self service transaction = 100 pts

Don’t worry about the actual scores, but do leave room for additional interactions that you can add in if you need to (but remember to communicate it out if you do add in others, as scores will go up).

Now that you’ve scored various activities, you need to implement the code to measure those interactions.

Implementing the scoring

In SiteCatalyst that’s easy enough to do – you need an eVar and a success event.

Set up the success event as a Counter Event. 

Note that you can now have counter events where they take a value other than 1, which is what is needed for the  scoring.  However, I believe you’ll need version H23 of the s_code to support this. 

Create the eVar as a Counter eVar, not a text eVar.

Visitor scoring is done by simply passing the score value as a +number into the eVar and the success event is set with the =number (yes, you no longer need to pass the event through the s.product string).

So, for example, on your homepage, you simply add the following:

s.events="event1=1"; s.eVar1="+1";

On your search page, you’d include:

s.events="event1=20"; s.eVar1="+20";

(The above obviously assumes you’ve used event1 and eVar1 for Visitor Scoring.

Complete that process for each of the key interactions and you’re set.  We implemented ours directly into our s_code through a variety of s.pageName value matches, or product views, or other success events occurring.

To put this in context, we’ve implemented the following scoring:

1. Homepage view = 1pt
2. Searched for something = 5pts
3. Viewed a course = 20pts
4. Completed a form = 30pts
5. Used one of our interactive tools = 50pts
6. Opted in to something = 70pts
7. Submitted an application = 100pts

Making it legible

First thing you need to do when you implement this type of thing is make it all a bit more usable.

When you look at the raw data (your eVar against conversions), you’ll see something like:

Remember that the success event (Application Submitted) is associated back to the value seen in the eVar, when the success event was applied – so, in the example above, 37 apps were submitted when visitors had a score of 190; 22 had a score of 211, etc.  Notice also that as we’re showing both Apps and Leads, we also see that they don’t correspond; Leads has a very different scoring result (see below).

Overall, it doesn’t tell you much – you actually want to group the eVars together.  So, use SAINT to classify them into buckets. 

Important Tip: When you use Excel to classify your eVar, the key column will be the interaction score.  You need to keep that column showing 2 decimal places – when you export from SAINT, it has the decimal places on it, when you open in Excel, the decimal places disappear, and if you re-save without decimals and upload again, they keys will be different, and the reports won’t work.  So, put the key column to 2 decimal places and then classify it.

That brings about the problem of what your buckets should be…well, that’s up to you.  Only your data will tell you that.  But, you can experiment with different buckets to see what works best.  To be honest, it’s best to do this in Excel, rather than SAINT, as you’ll want instant gratification.  And you’ll obviously need data collected before you can classify…so it’s best to run it without classifications for a while.

We classified ours following a bit of analysis using Excel to figure out the best buckets for Applications Submitted and Optins.  As it turned out, after a lot of playing around, we chose a logarithmic scale, as it seemed to group everything the best:

What we see in Excel is that with these buckets, 80% of applications occur before a visitor has a score of 320.  We also note that most apps occur when visitors have a score of between 160-320…our sweet spot.

So, using SAINT, we classified our Engagement Value eVar into our buckets and uploaded back to SAINT. 

Tip: Due to the size of the file, we typically use an FTP upload now – it took less than 10 minutes to classify the data in the reports.

Now re-run the above SiteCatalyst report, this time using your buckets:

Remember above I said that leads obviously have a very different score?  You can see that in the above report, that Lead Completes tend to happen when the visitor has a score of between 40 and 160.

What we see from Excel with Leads is that 80% of leads occur before a visitor has a score of 80 – which means that those that become leads, do so pretty quickly; they haven’t visited much other content (otherwise their score would be higher) – which is great news for us!

Another way to classify the scores is to set “low, medium, and high” buckets for engaged visitors.  I’m still trying to figure out what we should use as those buckets, as we have a very large spread.  Standard Deviation will probably assist in that one eventually.

Calculated Metrics

At this point in time, you probably also want to create a few calculated metrics to get some averages out.

Ones that I’d recommend are:

1. Score per Visit = [Engagement Score] / [Visits]
2. Score per Search = [Engagement Score] / [Instances (Report-Specific)]
3. Score per Referrer = [Engagement Score] / [Instances (Report-Specific)]

Why is Instances in there twice?  Because a) Visits are not available across every report type and b) the naming convention just makes it a bit easier to understand (IMHO).

Did you know you can also trend calculated metrics?

Now that you’ve got all this wonderful new capability, what do you do with it…?

Segment it (of course)

There’s all sorts of different ways you can use this…all basically segmentation based.

You can look at traffic sources, campaigns, keywords, geographics, user type segments, etc.  You can trend and compare your segmented values over time.

In the example on the right, we see that while Australian visitors have an average score of 5.82, the highlighted items have much larger scores, indicating that they are engaging with more of the things we want them to do.  The example on the right was extracted using Discover, as in SiteCatalyst 14 the capability with geo-demographic reports is somewhat limited to country/visits.

In the next example, we’re looking at scores by course interest.  The course category is actually an eVar that is set in various places across the site – similar to a product category.  When a visitor browsers different bits of content, we’ll set their course category differently, which is then used for Test & Target purposes…but works well here too.

We see that while Undergrad had more course views during this short time frame, they scored actually slightly less than Postgrad visitors.  This would indicate that PG visitors tend to read more, which would also make sense, as it’s a bigger purchase decision for them.

And as a final example, scores by different campaign types (Organic, Paid, Campaigns, etc).

Hmmm…seems Paid Search is doing really well; not a huge amount of traffic during this period, but they are interacting a lot.  Break that down by keyword or Adword group and you’ll get even more insight.

Here we’re looking at Branded vs. Non Branded keywords (and their top keywords):

Seems that branded search terms generate a higher interaction, and in fact when they type in the full name of the university, they have the highest interaction.

Multi-scoring techniques

You’re not limited to having just one scoring methodology.  We’re actually in the process of implementing a second one for a completely different reason.  All you need is a spare eVar, another success event, and bit of time.  Rinse and repeat!

Comparative and Trending

Of course, you can also trend on the calculated metrics to ensure your overall interaction score is going in the right direction, and you can trend by different segments too.

Likewise, you can do comparative analysis using different dates to compare the interaction scores.

Extending the scoring

In SiteCatalyst 15, you can leverage the segments for visitors with scores higher than X – you can either use the value of the event, or you can use the SAINT classifications. 

Additionally, you can use these in DataWarehouse and Discover – or start from Discover and put the segments back into SiteCatalyst.

And, you can leverage the segments and scores in Test & Target to further optimise user journeys and conversions.

There’s just a whole heap of different ways to use this information.

Next post

In my next post, I’ll combine the above interaction Visitor scoring into the Discover segments for a full on Engagement Analysis, replacing the previously described interaction score with this one.

I thought I’d share a real humdinger with you.

It’s campaign time again.  Not just any old campaign, it’s our main recruitment campaign of the year.

What we normally do on this campaign is behaviorally target content to users based on their application stage.

Why?  Because we know from previous tests that behaviorally targeting content for re-engagement purposes not only lifts our application completion rate, but provides more relevance to the user when they visit our site – instead of just seeing a standard campaign message each time.

Given the value of an application, and the lift we see, it’s well worth the effort to go down this path.

But this time, the gates of hell opened and out rode the fifth horseman.

We typically use 4 different stages, with one experience (content) per stage.  The challenge we always faced was that for each stage, we always wanted to run A/B tests to see which converted better – but could never figure out how to do it when it’s coupled with a behaviorally targeted campaign.

A few months ago, I worked with one of the Omniture Test & Target genius rock stars, implementation engineer Randall, who worked through a nested mbox example with me, which could be used to nest A/B tests within a single Landing Page campaign.  Unfortunately at the time we didn’t get to implement anything (or even try it – but it looked great on paper).

Knowing that our primetime Mid Year recruitment campaign period was nearly on us, I dusted off the email and had a good ‘ole read, as I felt it had some opportunities for us in a variety of ways.

And so the madness begins…

Always up for a challenge, I strapped on my Test & Target boots, and suggested that we could perhaps, possibly, maybe, ‘ish, try, have a crack at, putting together a behaviorally targeted campaign, where at each stage of the process we not only change the offer (easy) but run an A/B test (difficult) to test how well different offers convert people to the next stage.

Be careful what you wish for…because not only did they like that idea, they compounded it by throwing in another campaign on top of that one.

Mid Year campaign is normally restricted to Undergrad recruitment.  At least, that’s been the (now) historical position.

But no, this year, we’re doing simultaneous Undergrad and Postgrad Mid Year campaigns.

Yikes!!!  Go big or go home!  In for a penny, in for a pound.

So, to summarize, we want a simultaneous 4 stage behaviorally targeted campaign with a series of A/B tests within them.  And we need to switch users between campaigns based on whether they meet certain criteria, or whether they’ve viewed specific types of content.

Hmmm…a real humdinger!

Test & Target to the rescue

It gets a bit tricky to do, so I’ll do my best to explain it.

Before I do though, here’s an illustration of what was actually created.  Each of the rectangles with the little red circles is a separate Test & Target campaign.  You’ll see there are 11 of them.  The final bottom row is content…you’ll see there are 12 of them.  And you might also notice a total of 10 nested mboxes!

In a bit more detail, we’ve ended up with:

• 1 primary campaign as a Landing Page campaign that switches between an UG or PG experience, with a default offer for those we know nothing about.  The UG or PG experience then calls on (via a nested mbox):
• 1 of the 2 recruitment campaigns (UG or PG) as Landing Page campaigns so we can target one of the four  stages of the application, via nested mboxes, which calls on:
• 1 of the 8 A/B..n campaigns to determine the offer displayed

There’s a total of:

• 10 nested mbox offers…
• 12 content offers (the things people actually end up seeing)…
• 5 expression targets…
• And 6 profile targets…

Holy moly, I can hear you say.  Why so complicated?  It’s complicated because of the need to switch people between the campaigns based on what content and stage they’re at.

So, how does it all work?

The top campaign:

As we want to target initially by user interest (they’ve previously viewed Undergrad or Postgrad content, or they’ve visited an Undergrad or Postgrad course, or they’ve visited the Undergrad microsite or Postgrad site, or they’ve come in from an Undergrad of Postgrad email campaign, or they’ve visited the Figure Out Your Course tool or the Postgrad tool), we need to be able to get them into the relevant Undergrad or Postgrad campaign.

So, we need to use a Landing Page Campaign, which is set to re-evaluate the rules (and hence the offers) each time it displays.  This allows a user to see different experiences each time, based on the rules above.  It’ll switch a user to the opposite campaign if they go, say, from an Undergrad course to a Postgrad course.

But, we don’t want to show them an offer just yet.  We’re only doing this to determine which campaign they need to get into – and change that decision on the fly.

Hello nested mbox

On our home page, we already have an mbox (marketing box) defined, with default content.  So we start off by creating a campaign to use that mbox.

The following shows the top level campaign, targeting the default mbox on the page – HP_lowerleft.

Instead of serving content back, we want to serve back a different campaign (Undergrad or Postgrad), so we actually need to serve back a nested mbox as our offer.

A nested mbox is just an mbox served into an existing mbox, which then makes another call to Test & Target to get more content.

So, if I meet the criteria for Undergrad, then the content offer that Test & Target serves back to me contains a new mbox.  The content offer looks like:

<div class="mboxDefault">
</div>
<script type="text/javascript">
mboxCreate('UndergradNested');
</script>

I repeat that type of content offer for the Postgrad campaign offer, but call the other mbox ‘PostgradNested’.

From a conversion standpoint, we set the Conversion as an SiteCatalyst:event…meaning that whatever the user does, the campaign thinks they’ve converted, and as they restart with the same experience, it re-evaluates them each time, to determine which offer to show them.

That’s campaign #1.

We’ll call it the Mid Year Parent Campaign – and it’s the one at the very top of the illustration.

Now that I have that, I need to create two sub campaigns; one for Undergrad, the other for Postgrad. These campaigns will serve something back into the UndergradNested mbox, or the PostgradNested mbox.

Main Sub Campaigns

So, as I also want to serve back behaviorally targeted content, based on their stage of application, I need to repeat the above type of scenario, but have the experiences based on the users stage.

Stage of application

Once again, a Landing Page campaign allows a user to see different experiences each time, based on the rules evaluated.

So, we created another Landing Page campaign, with 4 offers, each offer targeting the stage that the user has completed:

1. They’ve started an application but haven’t completed it yet
2. They’ve qualified for entry, but haven’t started an application yet
3. They’re a repeat visitor and haven’t qualified yet
4. They’re a new visitor and haven’t qualified yet

But, again, we don’t want to show them an offer just yet – we want to show an A/B test for offers 3 & 4, and different content for offers 1 & 2.  So, again, we serve back a nested mbox offer, that aligns with the users stage.  In the example below, I’ve shown the nested mbox content for Experience D:

<div class="mboxDefault">
</div>
<script type="text/javascript">
mboxCreate('1stTimeVisNested');
</script>

A/B..n Sub-Campaigns

Now that I have the Undergrad main behaviorally targeted campaign created, I need to create the 4 sub-campaigns which will serve back real content that the user will see.

So, I create a new A/B..N campaign, target the mbox 1stTimeVisNested created above, and create 2 different experiences for it.  That’s the A/B test for the 1st Time Visitors who haven’t qualified.

I repeat that for Repeat Visitors who haven’t qualified, but this time I target the campaign at the mbox RepeatVistNested.  This one also has two offers (the A/B test for this campaign).

Then I create two more A/B campaigns which will serve back content into the respective mbox defined during the other two stages of the application.

Complicated I know – hope you’re still with me.

Rinse and Repeat

Once all that’s been created, it’s a fairly simple matter to duplicate each campaign for a Postgrad version, modify the offer to create new distinct mboxes for each one, and set up the A/B campaigns, with their respective offers.

In doing so, we now have a total of 11 campaigns and 10 nested mboxes, with 12 content offers.

Now to the targeting of it all.

Targeting Expressions and Profiles

Interestingly, this turned out to be the hardest part.

The very first campaign needs to determine whether to ultimately display Undergrad content or Postgrad content.

So, as we have OR’s in our rules, we need to use an Expression Target (basically Javascript that sits in the T&T target rules and returns a true or false).  We have to use an expression because the rules at the campaign level are all AND-based rules…which don’t work for us.

So, we have two Expression Targets on the main top level campaign…one to determine Postgrad the other to determine Undergrad.

By way of explanation, the Undergrad target expression basically says:

1) Get the value of the last campaign that the user clicked on (that’s our campaign tags)
2) Return true if the users last:
a) coursecategory was Undergrad, or
b) tool used was Mid Year, or
c) LastMicrosite visited was Undergrad, or
d) campaign tag contained “undgrad”, or
e) the current URL query string contains a special one for us to test it with!

The same is basically true for the Postgrad target, just different values.

These two expression targets are then used in the campaign, highlighted below.  Despite the fact that it says “…is present”, what it actually means is “… is true”.  Never understood why that is, but there we go.

Then we need to set up our Application Stage targeting – basically telling us if the user has Qualified for Entry and hasn’t started and app, or if they’ve started one but haven’t completed it yet.  So we added more targets as follows:

You’ll notice in both that there are a combination of both user and profile based rules.  User rules are script based and are set up in the Profiles area of T&T and profile based rules are values passed into T&T from an mbox.

We use a lot of mboxes across the site and pass quite a few profile parameters in through the mboxes – which makes it easier for us to target later.  All of our key stages have been pre-tagged with mboxes and various parameters.

The only one to use a user-based profile is our lastcampaign profile.  Anytime a visitor comes to our site and the visit contains a campaign tracking code, the code is automatically passed into Test & Target and saved into their user profile, via a script, shown below.

You’ll also notice some of the profile.parameters that have been passed in – note that you can’t edit them.

In testing all of this, I just couldn’t figure out why I always ended up in the repeat visitor campaign for either UG or PG.

The reason was easy to overlook, and worth mentioning:

I’d actually structured the order of offers back to front in the second level campaigns…stupid me, I did know this, I clean forgot when I created the campaigns (Omniture: it would be great though to be able to re-order experiences – but you can’t you have to delete and start again).  The reason being, you have to put the highly targeted ones at the top and the broadest match at the bottom, as T&T evaluates in the order that the experiences are displayed.  And thanks to Veronica at Omniture for spotting a misplaced apostrophe…they’ll get you everytime!

Testing everything

Yes, it’s a challenge – this many campaigns and offers means lots of new sessions, clearing of cookies, and re-establishing the stage of the user journey, but after a few hours, confirmation was established that everything was as it should be.

The biggest problem was that as we were serving back nested mboxes, we couldn’t preview the content in-situ as you would normally do through On-Site Preview, as it looks for the mbox on the page…and they don’t “exist” yet because they’ve not been served back yet.

But we go there.

Performance?

With all of these nested mboxes flying around, I was concerned by performance.  But, I was really happily surprised…it’s virtually undetectable.  Using WASP we’re able to see the order that the mboxes are served in and they match up correctly.

In Summary

So, there we have it.  Two behaviorally targeted campaigns, with triple backflip A/B twists thrown in.  The horse is back in the stable, the gates of hell are securely closed again and Rapture didn’t happen.

Test & Target came to the rescue and allows us to do what we need to do from a campaign standpoint.

I can sleep now – the campaign is live, you can experience the different offers by viewing the homepage, then a Postgrad course, then an Undergrad course, then repeating your visit later, or starting an app and not completing it.  If you feel so inclined…

One of the most powerful ways to enable an audience connection is through behavioural segmentation.

Many companies today segment from a business standpoint.  Don’t get me wrong, this is a good strategy and aligns your measurement and optimisation strategy with your business segmentation model.

Customer / non-customer segments.  Product A owners / product B owners.  Mosaic-based segments.  Geographic segments.  Lead / Non-lead segments.  These are all typically business-based segments, and you should definitely be segmenting using this methodology if your overall business does.

But I think there’s a higher level of segmentation – behavioural segmentation.

Behavioural segmentation in action

Every time someone visits your site they’re telling you what they’re interested in.  These behavioural segments are measurable and usable.  And moving from business-based segmentation to behavioural segmentation truly allows you to relevantly engage with your customers based on what they’ve told you about themselves, through either their activity on your site, or through forms they’ve completed.

At Murdoch, we recently re-developed our primary lead generation tool, called “Figure Out Your Life”.

FOYL, as it was affectionately known to us, was the University’s primary lead gen tool – it essentially asks you a number of questions and then suggests courses or careers that may be of interest to you.

Overall, the redesign was based on user feedback from focus groups but we took the opportunity to introduce behavioural segmentation into it, to not only measure those segments over time, using a combination of SiteCatalyst and SAINT classifications, but to enable more refined and relevant content targeting to each segment for optimisation and engagement purposes.

The new FOYL, now called Figure Out Your Course (or FOYC) asks 6 personality-type questions, and allows the user to rate their answer to each question, on a sliding scale, from 1 to 10.

The combination of their answers to the 6 questions results in 3 recommendations for courses they might consider.  

I’m not going to reveal the methodology behind tool – that’s confidential IP and very complex, but I will talk about the segmentation opportunities it allows.

How we achieved behavioural segmentation

From a segmentation standpoint, we decided that we wanted to firstly measure the segments to see what “types” of users are completing the tool, and secondly, through integration with Test & Target, we can then customise content to each user, based on how they answered each question.

To do so, we needed to capture each of their answers in an eVar (conversion variable), which must be remembered over multiple visits.

To enable more realistic clustering of segments, we decided that while the tool works on a rating between 1 and 10, we’d actually work our segments on a rating of 1 to 5.  So we “bucketed” each answer accordingly:

Moving the slider to position 1 or 2 makes them segment 1,
3 or 4, segment 2
5 or 6, segment 3
7 or 8, segment 4
9 or 10, segment 5

In doing so, each user now scores (from a segment standpoint) between 111111 and 555555, which makes a total of 15,625 combinations (111111, 111112, 111113, etc through to 555555), or 5^6.

By combining their scores for individual answers into a single variable, we end up with a per-person score, where each digit in the variable represents their chosen response to each question. 

So for example, if a person answers question 1 with a rating of 2, question 2 a rating of 10, question 3 a rating of 7, question 4 a rating of 10, question 5 a rating of 6 and question 6 a rating of 1, their overall segment score would be 154531.

We store this in an eVar and a persistent s.prop, and pass them to SiteCatalyst.

Results

What we end up with is a list of scores in a SiteCatalyst report as follows:

Not a lot of use, except that we can see the raw scores and the number of instances of each score.  You can see as well that they’ve started to cluster.  50 people have been through the tool and selected 141515 as their answers to each question.

Using SAINT classifications, we then created every possible combination and classified every result.  Despite it being 15,625 combinations, this only took a few minutes – gotta love Excel for this.

We’ve classified each digit location as the question, and each digit value as the score from 1 to 5.

For example, the classification for digit location 1 is “Indoors (1) or Outdoors (5)”.  The values range from 1 to 5.

Our classification file looks like:

We set “No FOYL” as the default for people who haven’t been through the tool yet – which also allows us to use T&T to engage them into the tool.

Using the classifications, we can now see a report that shows all responses to digit location 1…i.e. how did people answer that question:

So we can see that most people are answering question 1 with a segment rating of 3 (mid way).  Unfortunately, we can’t order the values numerically, they are ordered highest to lowest on their instances.

If we chart that as a pie chart, we see:

Now we repeat that for every question asked and pop it into a dashboard for an overview of results, and we can see:

We can also now sub-relate those individual segments with the courses they’ve viewed:

Our true measure by segment is lead generation, so we just add in those conversion metrics too, Lead Start and Lead Complete and we can see conversion by segment.

Discover

Using Discover, we can create those segments individually and compare them.  Here I’ve compared search terms against anyone that answered the Behind Scenes/Lead a team or Indoors/Outdoors with a 5:

The same segment can be used in SiteCatalyst 15 to segment your reports.

We also pass these segments into our email marketing platform so we can segment our ongoing communications further, generating a more personalised and relevant experience for the user.  We can now customise parts of the message dynamically, based on the segment (or segments) that they told us they’re in.

Test & Target

Now the really useful stuff.

Because Test & Target can also see those segments and values, we can target content to each segment as they re-engage across our content.  For example, we can vary messaging to people who prefer to work outdoors instead of indoors.

We can target course content to them based on their selections.

We can build multiple targets and combination targets to get the content to them.  If they haven’t been through the tool, we’d also know that too, and we can target messaging to try to engage them that way.

In summary

Every company has the opportunity to segment. And that’s how you move beyond reporting to insight.  Understanding how your segments interact with your content or how they convert differently allows you to further optimise their experience. 

There’s plenty of opportunity to segment for measurement purposes, but when you combine Test & Target with those segments, and start to target information based on those segments, it’s really powerful.

When you move away from just reporting, to segmentation, and beyond to segmentation based on user behaviour, you can really start to generate user engagement and relevance of content.

You just need to open your mind to the segmentation possibilities and find out what works for you.

Let me know how you’re segmenting your site visitors and what you’re doing around optimising their user journey based on their segments.

We’ve all got forms on our websites.  And chances are, you have multi-page forms.  But, do you know how they’re performing?  Do you know where people are abandoning your forms?  If you knew that, what could you do?

There’s lots of ways to track forms but they vary depending upon what you need to accomplish.  Multi-page forms, which are very common these days, are slightly more complex from a measurement standpoint, but you definitely want to get some insights into these types of forms.

Our online application form for enrolment is around 18 pages – only some of which require you to enter information.  So it’s important for us to know which pages people abandon on, and which form fields they last interact with.

Another example would be a credit card application form, which might be 10 pages.  Or an insurance form that might be 5 pages long.  And there’s no real benchmark for completion.  The benchmark to use is your historical data.  Then you try to optimise it to achieve a greater conversion from your own benchmark.

In the following post, I’ll look at different ways that you can measure forms using SiteCatalyst and Discover. This is a fairly long post, so I apologise in advance.

Success Events

The first thing you need to do is ensure you are setting some success events.  This will tell you the number of times a form was viewed and subsequently completed.

To do that, you’ll need to do a couple of things.

Firstly, you’ll need to use an eVar for the form name, and two success events – one for form view, and the other for form completion.  We actually use four different success events; Form Start, Form Complete, Lead Start and Lead Complete, being a positive optin.

On the form page, set the eVar to the name of the form, and set the success event, for example:

s.eVar8 = "Figure Out Your Life 2009";
s.events = "event2"; // this is our Lead Start success event

When the user submits the form, you can then set the eVar and the completion event, as follows:

s.eVar8 = "Figure Out Your Life 2009";
s.events = "event3"; // this is our Lead Complete success event

Now in SiteCatalyst, if you view the Lead Type report (assuming that’s what you called the eVar8), against Lead Start and Lead Complete success events, you’ll have some basic numbers, and you can create a calculated metric to understand completion ratios (lead complete / lead start).

Then you can trend the same report, picking up the Lead Conversion Rate and the name of the form, to analyse its performance over time against other marketing campaigns – for example:

One thing you’ll probably want to do though is contact support to get Event Serialisation turned on for these two success events.  This ensures that you don’t count the event twice during the same session, which is especially useful when they have an error and go back to the form which may (or may not) fire off the Lead Start event again.

But that’s not really what this post is about.  This assumes that you’re doing that anyway.

Form Field Analysis

What about the fields that they abandon on?  Irrespective of it being a multi-page form or not, you’ll likely want to know what fields they last interacted with.

You can get this by using the formAnalysis plugin.  See the nitty gritty bit at the bottom for implementation ideas…as always, check with Omniture Support or Engineering Services to make sure you’ve done it correctly as the implementation can be different from client to client.

It’s not a particularly pretty report, and it can be somewhat complex to implement, but there’s a heap of insights it can give you, enabling you to take a closer look at your forms and decide if you need to change the label, or the field itself, or indeed if you really, really, need that field.

We have a form on the Murdoch Uni site called “Stay In Touch”.  It appears in multiple places across the site.

The way we have configured our form analysis plugin is to use the pagename, followed by the formname, and then the plugin does the rest.

As you can see from the report below, the pagename varies depending upon which form the user filled in.

As you can see, the most common thing that they last interact with was the field “segment” – that’s a field that asks them to tell us who they are.  It actually appears across a number of the different (but same) forms across the site and seems to be fairly consistent.

As that was the last field they interacted with, we need to look at the next field, or the form overall.  The next field asks them to tell what they’d like to be kept in touch about…and it appears that it’s that selection that’s putting them off.

I’ve filtered the above report using a number of criteria to look only at “abandon”.  The filter was:

So, what…

What can we do about this abandonment?

Well, there’s a number of things in play here.  We have another form that’s about getting in touch with the University to ask questions – powered by RightNow.  It appears that on further examination using pathing from the forms above, we can tell that the user wasn’t actually looking to use this form – they wanted the Ask a Question form as that’s where most of the “abandoned” traffic went to.

Multi-page forms

Multi-page forms are common, and you can use SiteCatalyst Fallout Reports to see the completion from page to page.

There’s a gotcha here though – you can only use this for 7 pages.  So if your form is more than 7 pages long, you’re going to be out of luck if you want to see every page.

The other way, which sort of works, but can lead to a bit of trouble, is to just look at the page views across the forms, by filtering on the pagename.  The problem with this approach is that it doesn’t put them in the order that you want them…it only shows the number of page views.

Enter Discover.

Using Discover Fallout

Discover has a wonderful visual fallout report that allows you to add an unlimited number of pages, or steps, to a form fallout report.

The following (very long image) is a representation of our online application process.  It’s 19 steps and each step shows the amount of fallout per step vs those that went on, and if they left, where they went next.

The following is an enlarged area of the same report:

The thing that you’re looking for in this report is a larger than expected “lost”, as highlighted above.  Simply click on the green arrow and it will tell you where they went.  In the above example, the particular page where people “fallout” is the Upload Docs form, which requests documents to be uploaded.  Clearly users are not aware they need to upload documents, or don’t have them to hand, so they save the form and come back later – thereby causing an “abandon”.  We now alert them to the fact that they’ll need to upload various documents, minimising any fallout.

This is very handy report as it allows you to narrow down your analysis of fields to a specific page.  Start at that point to increase the conversions of your forms.

The other, really important capability, is that you can segment this report nine ways from Sunday to see if different segments interact with your forms differently.  We commonly look at Domestic versus International visitors through this lens.

And now to the nitty gritty bit

There’s a number of parts to get the form analysis plugin working.  Firstly, you’ll need to get the plugin from Omniture.  You’ll also need to define an s.prop in SiteCatalyst admin.  We’ve used s.prop18.

Then you’ll need to configure your s_code config section.  There’s a few variations, but ours is as follows:

/* Form Analysis Config */
s.formList="stayintouchform,form1" // Names of forms to track
s.trackFormList=true;
s.trackPageName=true; // Append the name of the page to the form name
s.useCommerce=false;
s.varUsed="prop18"; //sprop used
s.eventList="" //Abandon,Success,Error

s.formList is a comma separated list of forms that you want to track.  The name of the form must be the same name that is in the HTML, i.e. <form name=”stayintouchform”>, and should be unique across multi-page forms (to allow for better visibility).

In the s_doPlugins(s) section, you’ll need to add the following:

/* Form Analysis */
s.setupFormAnalysis();

Once you’ve got those in place, you’ll start to track each form field.  Remember that it’s the last field they interacted with that is recorded.  There are some other values as well, such as “Continue”, “Abandon No Data” and so forth, but they’re all fairly self explanatory.

And that’s about it really.  There’s also a really great post from Adam Greco, a.k.a. the Omni-Man, who talks about using specific events to track form completions, ratios, etc, without the form analysis plugin.

Final Thoughts

Form abandonment is a critical part of understanding user interactions on your forms.  It’ll give you better insight and allow you to improve your overall conversions on your cart completions, product selections etc, and should therefore be definitely considered as part of your overall implementation strategy.

One of the fundamental things you need to understand about Omniture SiteCatalyst is the difference between an s.prop and an eVar, and just what events are and when to set them.  They are at the heart of the product and provide the ability to customise it to suit your business needs.

If you don’t understand the difference, you’re going to be in a world of pain, and left dazed and confused.

This is, understandably, the most confusing thing to new SiteCatalyst users, and they take a bit of getting used to, especially when you start to combine them all together, but once you understand them, you’ll be on your way to generating custom ones that can really provide insight.

The clickable illustration on the right started as a Sunday afternoon musing, but then extended into a somewhat chaotic depiction of props, evars, events, campaigns, products and so forth – of which I’ve tried to explain a little more simply below.

s.prop definition

These are custom traffic variables.  They are used to count the number of times that certain values are sent into SiteCatalyst.  With the latest release of SiteCatalyst, you get 75 custom traffic variables to play with.

They are not persistent – meaning that once they get counted in SiteCatalyst they get forgotten.  Nothing else can get attributed to them.

Traffic data includes visits, visitors, page views, sections, sub sections, internal search terms, user type (segments) etc.  You can also enable pathing on these custom variables to understand the path that users take from prop to prop.

If you want to breakdown two traffic variables by one another, such as Pages by Browsers, then you must ensure that both variables are set on the same page.  The correlation report only shows instances where two things occurred at the same time.

If you wanted to understand internal search terms that eventually get the user to a form, traffic props are not the way to go.  For that, you need to use an eVar.  And in many cases, when you set a custom traffic prop, you’ll also want to set a custom eVar too.

Mostly you’ll just pass a single value into an s.prop…maybe the name of the sub section, or the name of a tool, or the type of user currently logged in, or the category of content etc.  There’s another type of s.prop, which is called a list s.prop.  List props take a delimited list of values, and then they’re split out into separate line items in SiteCatalyst.

Bear in mind that list props cannot be correlated…despite the fact they’re broken out by SiteCatalyst into their individual elements.

eVar definition

These are called conversion variables and are generally set on different pages.  Again, you get 75 of these too.

They are usually used to tie success events back to the last value that was stored in the eVar.  By definition, these are persistent, and you control, through the admin, how long they remain persistent (visit or timeframe or when something happens like a success event), and how to allocate a success event to them (most recent value is the most common setting).

eVar relationships

eVars can be related (or broken down) by one another.  There are two ways to achieve this – basic subrelations and full subrelations: 

• Full subrelations can be broken down by any other eVar that has either full or basic subrelations enabled.
• Basic subrelations can only be broken down by an eVar that has full subrelations enabled.
• The third type is no subrelations and they cannot be broken down by anything.

By default, campaigns and products are enabled with full subrelations out of the box.

Consider this:

If you want to know which internal search terms lead to the most form submissions, and which search terms lead to tool usage on your site, then Search Terms needs to have Full Sub Relations enabled on it.  That way you can break down Search Terms by any eVar, and the other eVars (such as Form Name and Tool Name) can also be broken down by Search Term.

Crossing eVars with sProps

You can’t.  You just, plain, can’t.  Accept this and move on.

You cannot cross traffic values with conversion values.  They don’t mix.  As soon as you remember that, and plan for that, you’re doing ok.  That’s one of the reasons you generally set an eVar every time you set a traffic prop. You can correlate two traffic props together (browser and subsection for exmaple), and you can subrelate two conversion variables together, but in SiteCatalyst, you can’t cross props and eVars. 

If you’ve got Discover, well that’s a different story.  You can pretty much cross anything you like with anything you like, against segments and times on the fly, to your hearts content!  Seriously, if you don’t have Discover, get in touch with your account manager for a demo – you will NOT look back.  And if you have a lot of eVars that you want full subrelations on, then you’re a prime candidate for Discover, not to mention if you’re using ASI slots for segmentation reasons – or you just can’t get that report that you’re looking for.  Discover will do it for you.  Period.

Events

Success events are counts of specific things that occur on your site, usually things like a form view, or a registration, or a login, or an application.  Success events are set and tied to an eVar.  Your reports will show the number of times that success events have been set against the specific values on the eVars.

Normal success events, such as when a registration form is viewed and then completed, takes two success events, one for the view and the other for the completion. 

So, let’s assume you have a registration form.  You want to know how many people view the form and how many people submit the form.

On the registration form page, you’d set the following:

s.events = "event1"; // this is your form view event
s.eVar1 = "Registration Form"; // this is the name of the form

Then, on the thank you page, you’d set the following:

s.events = "event2"; // this is your form complete event
s.eVar1 = "Registration Form"; // this is the name of the form

Notice that eVar1 is set to the same name in both instances, but has different success events set.

In SiteCatalyst, you’d create eVar1, named something like “Forms” which will automatically create a new report for you called Forms.  You’d view the Custom Conversion > Forms report, being eVar1, add in the metrics Form Views and Form Completes, and it will show you how many form views have happened (event1) and how many form completes have happened (event2) during the specified time period.

Special Events

Then there are special events; product views, shopping cart view, open, add, remove and checkout, and finally a purchase.  These are generally used for measuring products purchased and shopping cart activity.

A product example

So let’s assume that you are a financial institution and have information on various credit cards as well as an application form for each type of card.  You want to know how many times the card information has been viewed, as well as applications started and submitted, across a multi-page application process.  Additionally, you want to track the credit limit applied for on the card application.

On the credit card information page, you set the special event prodView (and it’s also best practice to set another success event as the prodView event is only available within the product reports).

So, you could use the following:

s.events = "prodView,event3"; // product view and a success event
s.products = ";Credit Card XYZ"; // this is the name of the product
s.eVar2 = "Credit Card XYZ";

The product string usually takes many more parameters, but as we’re only setting it for a product view, we only need to set the name of the product in the product string. 

The other parameters, that are required when something is purchased, are as follows:

• Category (legacy – leave blank so that you can use Classifications to better group products)
• Product Name
• Number of Units
• Total Revenue from Units
• Events and eVars (but we’ll save those as they’re more complicated but can be used for things like tracking shipping costs or discounts etc)

Note that you MUST start the product string with a semi-colon if you are not using the category.  You don’t generally use the first parameter, Category, because the best way to do that is to use classifications to group products together.

So, now you’ve got the product views measured, each time someone goes to the product page, event3 will be set against eVar2, and prodView will be set against the product Credit Card XYZ.  ProdView is one of those special event counters.

To get the Application Start metric, on the first page of the application you set the following:

s.events = "event4"; // application start event
s.eVar2 = "Credit Card XYZ";

To get the product purchase, the revenue, the amount and the successful submission, on the application thank you page you’d set the following:

s.events = "purchase,event5"; // purchase and application submitted event
s.eVar2 = "Credit Card XYZ";
s.products = ";Credit Card XYZ;1;10000"; // product;units;total revenue
s.purchaseID = "123456789"; // unique application code

The events set include the special event “purchase” and event5, in this case, the application submitted event.

eVar2 is the name of the product for the conversion reports.

Products lists the name of the product, the number of units sold (1) and the revenue (10000 – in this case its the credit limit applied for).

The purchaseID would need to be a unique identifier, possibly the application number, so that SiteCatalyst can de-dupe any entries.

Now you have your product reports populated with the number of units sold and the total credit limits applied for, being the revenue amount (if that’s how you track revenue).

To sum it up

Props are traffic variables. eVars are conversion variables.  Events are things that happen on your site and are tied to conversion variables.  You can’t cross the two together, but can cross props and you can subrelate eVars.  Oh, and you need to get Discover (‘coz it rocks). Did I mention that already?