A fundamental thing you need to understand about Omniture SiteCatalyst is the difference between an s.prop and an eVar, and 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, feeling very 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 soon 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.
So, what is an ‘s.prop’?
They are custom traffic variables, and in the latest release of SiteCatalyst you get 75 to play with. 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.
s.props are used to count the number of times that certain values are sent into SiteCatalyst.
They are not persistent – meaning that once they get counted in SiteCatalyst they get forgotten. Nothing else can get attributed to them.
Using s.props
If you want to break down 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.
But, if you want to understand internal search terms that lead users to a form, traffic props are not the way to go. You need to use an eVar. 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, the type of user currently logged in, or the category of content etc.
List props
There’s also another type of s.prop, 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 that SiteCatalyst breaks them down into their individual elements.
eVar definition
These are called conversion variables and are generally set on different pages. Again, you get 75 of these.
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 sub-relations and full sub-relations:
- Full sub-relations 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?
