So, following a recent “back to basics” post, a reader requested that I write something describing how custom traffic props are actually useful.  How about customer segmentation achieved through traffic props?

Custom traffic props are used for counting traffic-based activity, to gain insights into user behaviour across our sites.  By default, custom traffic props only come enabled with the metric Page Views, which, by itself is, admittedly, not a lot of good.  But, with a couple of minor customisations, you can get valuable insights from the props very quickly.

This post is actually about customer segmentation – in our case measuring student activity versus staff activity versus “anonymous” activity.  In your case, it’ll probably be customers vs. non-customers.  It’s about understanding what they do differently (not how they convert necessarily, because for us, they’ve already converted). In a retail, financial or ISP environment, it might be about how customers interact with your content, or your help site versus non-customers.  What do they do differently?  What can you do to improve their interactions?  How do they use search differently?  Do they spend more or less time with you?  Are there signals that are pre-cursors to abandonment?

You don’t have to stop at the customer vs. non-customer segments either.  There’s plenty of other customer segments that you can apply throughout the brand funnel, as they move from being just a browser to a high value loyal customer.

And each major segment can sub divide into sub-segments.  For example, the Loyal Customers can be High or Low value loyal customers, they could be in danger of abandoning you, they could be a brand advocate, highly active in social media.  If you can segment them and re-identify them when they return to your site, you can present them different offers and different content to move them to the next “stage”.

All you need to do is reset the value in the traffic prop each time they move to the next level.

Customer Segmentation

We have segmented our traffic by user type for about two years now, to understand the differences in our audience types across a number of key areas on our site, such as search terms, content, tools, average visit duration, key activities and so forth. 

We ultimately re-designed our staff and student main pages, in part based on the information from the analytics.  We looked at: 

• key sites those segments were consistently going to (we have over 500 separate sites on the Murdoch domain) ;
• key content within those sites;
• search terms that consistently popped up
• primary entry and exit pages, bounce rates, page bounce rates
• key paths to content
• average visit length
• average time on page
• average pages per visit
• page velocity for each segment

We then built out a set of new pages designed for each audience, with the most common content and destinations specific to each audience type.  We’re about to expand upon this by launching transactional-based mobile site, designed for the iPhone, iPod and iPad series.

All of this came from using a single custom traffic prop – prop25 – User Type.

And some very interesting things came from those traffic numbers too.  Things like the volume of traffic from each segment:

And the seasonality of searches, not to mention the differences in keywords (note the differences in terms, especially the seasonality spikes across the student based search terms below:

From the search terms alone, coupled with top destinations, we were able to put together a Search As You Type functionality across our site, that aids faster access to the most popular content destinations, based on the keyword, or partial keyword that is entered.

A couple of quick wins

Enable Pathing

The first thing to do is turn on Pathing for the custom traffic prop, via a request through live support.   Even though you may not actually use pathing on the prop, pathing enables the following additional metrics:

• Average Page Depth
• Average Time Spent on Page
• Entries
• Exits
• Reloads
• Single Access
• Visits

You may also (probably should) request that you get Unique Visitors turned on for this prop – but you’ll have to do that through you account manager.

Set up correlations

The second thing to do is set up some correlations between this prop and others, for instance:

• User Type and Search Term
• User Type and Site Section
• User Type and PageName

So, now to the nitty gritty part

Firstly you’ll need to ensure that you have the following plugin:

• getAndPersistValue

You can download this from the help section of the admin.  Follow the instructions to place this in your s_code.

You’ll also need an eVar, which shouldn’t be a problem as we now have 75 of them, courtesy of SiteCatalyst v14.9.  Note that if you’re intending on using props or eVars that are numbered higher than 50 (the old amount), then you’ll need to update your s_code to version H22 or higher.

The first thing to do is locate specific areas of your site that you can identify a user type.  This might be on the logged in page, or it might be a specific page of content only for a specific type of user.  In our case, we set prop25 (User Type) when the user either:

1. Logs into our portal (either staff portal or student portal)
2. Views either the Staff homepage or the Student homepage

We have a little piece of code that sets the eVar depending upon the content they view:

/* Set User Type */
userloc = location.href.toLowerCase();
if(userloc.indexOf("my.murdoch.edu.au/staff") != -1){
s.eVar25="Staff";
}else if(userloc.indexOf("murdoch.edu.au/staff/") != -1){
s.eVar25="Staff";
}else if(userloc.indexOf("murdoch.edu.au/students/") != -1){
s.eVar25="Student";
}else if(userloc.indexOf("my.murdoch.edu.au/students") != -1){
s.eVar25="Student";
}else{}

So now we have set the eVar25 (a conversion variable for User Type), we need to set s.prop25 to the same value and pass it on every request.

/* Set User Status*/
//Check existence of persisting prop25
s.prop25=s.getAndPersistValue(s.eVar25,'s_prop25',7);
if(!s.prop25&&!s.eVar25) {
s.prop25="Anonymous";
s.eVar25=s.prop25;
}
//Set persisting prop25 to value of the eVar25.
s.prop25=s.getAndPersistValue(s.eVar25,'s_prop25',7);

The getAndPersistValue plugin takes 3 parameters:

1. The name of an eVar to get the value from
2. The name of a cookie to store the value in
3. The duration of time in days to store the value

So in the above code, we’re first putting the value of eVar25 into a cookie s_prop25 and storing it for 7 days.

Then, if the neither prop25 and eVar25 exist (in other words we’ve not identified them yet), then we set prop25 and eVar25 to “Anonymous”.

Then we set prop25 to the value of eVar25, store it in a cookie called s_prop25 and save it for 7 days.

Each time the s_code executes, it will now pass in prop25 at the same time it passed in things like keywords (prop5) and pagename and site section etc, enabling us to do correlations on it.

Additionally, as we have pathing enabled on prop25, we have Visits, Time Spent and Average Page Depth for each User Type.

Some additional valuable insights from traffic props

Another interesting thing to do with custom traffic props is to concatenate them with other traffic props and enable pathing on the resulting traffic prop.

For example, if you concatenate your Campaign codes with pageName, into a new traffic prop, then you can see what paths users take when they interact with the campaign, likewise you’d be able to see bounce rate by segment and so forth. 

/* External Campaign Pathing */
if(!s.campaign){
s.prop26=s.pageName;
}else{
s.prop26=s.campaign+"|"+s.pageName;
}

The above will use another traffic prop and concatenate the campaign tracking code, if it exists, to the page name.  For more info on this one, check out my campaign pathing post.

Another insight you can gain is page scrolling, either at the unsegmented level, or by each segment.

And then there is form analysis and abandonment – all achieved through your custom traffic props – but I’m saving a post on form analysis for a later date, possibly the next one!

Final Thoughts

Despite traffic props being basic counters, there’s quite a few imaginative things that you can do with them to get further value and insights.  And customer segmentation is key to understanding your audience online and improving conversions.

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?

One of the big problems with single page microsites is that traditional measures, such as bounce rates, engagement time, scrolling etc, all go out the window because there is no “second page” activity by the user.

Take, for example, a recent press-release microsite that we did at Murdoch University.  The press release is about snake bites and what owners can do to protect their pets.  There’s a bunch of information on the page, including an infographic, downloadable files, images, and other stuff.

The problem is, as the user interacts with the page content, they don’t actually move from page to page – which represented quite a challenge in the way it’s measured.

For instance, as there is no “second page”, there is no time spent on page metrics – because to measure that, you need the time difference between page 1 and page 2.

Bounce would be around 100% too…it’s the landing page, and it’s the exit page.

SiteCatalyst doesn’t record time between clicks when you use custom link tracking.  And even if the user interacts with the infographic (downloads it), clicks on the Flickr gallery exit link etc, there’s still no time recorded and no “second page”, so that doesn’t help either.

So, what to do?

Well, it’s possible to do it, but it takes a tiny bit of extra code to enable it all.

Assuming that your page of content has some interactivity on it that the user can click on, you can treat those clicks as page views.  In doing so, you’ll have all of the standard metrics available to you in SiteCatalyst, including pathing.

Our single page of content has a right hand side module that expands/contracts to reveal other content, such as documents, contact information, images and so forth.  We record clicks to those sections as separate page views, by using some custom code attached to the link and a separate JS file (see the nitty gritty bit below).

Each interaction, for example, a click on the tab to expand the content on the right hand side, will then appear in the pages report and you can then add in your desired metrics, including bounce, time on page etc.

One thing to note though, time on page will essentially be interpreted as the time on the piece of content between clicks.  If you want true time on page, then you should use average time on site, providing you’re reporting this into a separate report suite.

The other benefit to this is that you can also see how much time they spend within each “section” on the right hand side.

So, to the nitty gritty of it all

Firstly, make sure you have the s_code implemented normally on the page.  When the page initially loads, it fires off all of the information as usual including campaign codes, referrer and so forth.

Then add a special class and a unique ID to every link on the page that you want tracked, add in the special JS file (see below) and you’re basically up and running.

Clicks as Page Views

To get the clicks tracked as separate page views, you need to fire off the s_code again, each time a click occurs.

We created a piece of custom code that enables you to just name the link using an ID and add in a special CSS class on each link.  Then, with the custom JS code as well, located at the top of the page, each time the user clicks on a link, the ID is passed to the custom code and the s_code refires.

For example:

<a href=”#”
class=”omn_click head”
id=”FlickrLink_low_res“>Snakebite low res images</a>

The special class is “omn_click” and the ID must be a unique ID – we’ve named ours as if it were a page name, so that we can understand it better in the reports.

The custom JS file that we use is called “omniture_clicktracking.js” and you can download it from our site and use it as you see fit.  You’ll need to modify the props and eVars though depending upon what you want tracked.  The s_code for the particular page can also be viewed.

The custom file gets the name of the ID through a bit of JS wizardry and creates a new object called vars.  Then by passing in the new values that we want to see, it re-executes the s_code but passes in the new values, by using s.t(vars); instead of just s.t();

The code snippet below shows what I mean by that.

vars = new Object();
vars.pageName=omn_code;
vars.eVar3=s.eVar2 + ":" + omn_code;
vars.eVar4=vars.eVar3;
vars.eVar7=vars.eVar3;
vars.eVar5=s.prop5;
vars.eVar10=s.prop10;
vars.hier1 = vars.eVar3.replace(new RegExp(/:/g),"|");
s.t(vars);

One thing to remember is that there are values that are already set because the s_code has already fired on the page when the page loads.  So, by getting it to re-fire, those existing values will be re-sent to Omniture.  The trick is then to change only the values you want to change.

We make sure that we change the pageName variable and a few others, so that in our page reports, we have the name of the site:section:pagename as site:section:link clicked (see below for how we change the pageName using the s_code)

/* Set Page Name */
if(!s.pageName) {
s.pageName=s.prop1 + ":" + s.prop2 + ":main page";
}else{
s.pageName=s.prop1 + ":" + s.prop2 + ":" + s.pageName;
};

The second time this code runs, when they click a link, it executes the “else” statement.  It concatenates prop1, prop2 and the pageName (being the ID from the link) together to form the new pageName.  Then the rest of the s_code executes, passing all of the other s.props, eVars and events into SiteCatalyst.

Now we have an ability to properly measure user engagement on this page, by treating the links as separate page views, bounce rates are accurate and time on page becomes visible to us.

Hope that helps.