custom variables_custom events

7/29/2019 Custom Variables_custom Events

1/12

Like any software product you use, there are a few key elements that you need to

understand to be successful. In working with clients I have found that many do not have

a good understanding ofthe three fundamental building blocks of SiteCatalyst: sProps,

eVars and Success Events. When I was an Omniture client, I will admit that I had much

more important things to do with my time than to learn about Omnitures variable types

and their capabilities. However, over time, I came to understand that these variables are

the foundation of all SiteCatalyst reporting, so if I wanted to use Omniture reports to

measure my website success and/or justify my re-design theories, I had better suck it up

and learn about these three variable types. I hope you will do the same. In this post I will

review sProps and will cover the other two types in my next posts.

I want to share an analogy with anyone who might be trying to more firmly grasp some of

the elementary concepts of Omnitures SiteCatalyst analytics software. Ill outline the

meaning and intended use of:

eVars - (s.eVarN) aka custom commerce variables

s.props(s.propN) aka custom insight variables

custom events (s.events)custom events

Imagine theres a bustling marketplace. You have many entrances, many shoppers, many

browsers and in all likelihood a few shoplifters. If you were trying to better measure

various metrics such as the ratio of those who enter the market to those who purchase,

or even how many times people pass through a certain entrance youd have quite a job to

do. Youd have to be so many places at once with your eyes on more than you can

possibly keep track of.

Cast a wide net and tag every entrance with java script tags! Custom insight variables or

s.props will count whatever pass through them. Perhaps youd like to find out the use

frequency of the N entrances to the market. Lets use

s.prop1=entrance 1 each time someone passes through entrance 1, and use

s.prop1=entrance 2 each time someone goes into entrance 2. Keep in mind that

although the values were passing through the custom insight variable vary, the actual tag


2/12

(s.prop1) will stay the same for purposes of continuity. We can go into the SiteCatalyst

admin and name s.prop1 entrance frequency.

So now you know where people are coming inthats nice. Say you want to know how

many people go into store X in one month. Every time someone passes through the

entrance point of store X you trigger a custom event, say s.events=event1 Now each

time a shopper passes into the store the tally of event1 which will probably be set to

counter if youre not aggregating a monetary value the event count will increment

upward by 1.

An astute reader will now say, Jeff, what is this? You can just use a custom insight

variable, why are you being all fancy using this custom event stuff eh?? Excellent point

Ill reply! I could use an s.prop and each time someone passes through the store entrance

pass through the store name. So whats the fundamental difference?

Well, when someone leaves the store it will also count them when you use a prop,

whereas with the custom event you can serialize the event count so that you only

increment the event once per session or visit. Is it better to know the number of times

something passed through a gate or the # of unique people who went into the store that

day? Both have a certain value (and that was a rhetorical question) but as well see next,

the custom events utility reaches further beyond that of the s.prop in the case of

measuring commercial activities.

Okay, so we have the bustling marketplace, lots of people entering here and there, going

into stores and we know from where they enter and which stores are most popular. The

whole point of going there is to get them buying!!!! Spend your money with meeeeee

says the marketplaces collective wisdom.

Which entrance leads to the most revenue? Which store generates the most revenue?

Lets think about thisif we pass revenue into the s.prop, wait you cant do that it just

counts the frequency of what gets placed into it, and how would you know what entrance

they came into? If we set the custom event to currency (an advanced setting in the

sitecatalyst administrative console) we can pass the revenue of each store into a custom

event, but youd have to use multiple custom events for each store. How can you get the

data in 1 report.


3/12

Well first, to save face with any knowledgeable readers Omniture SiteCatalyst uses the

s.products=" tag to count revenue and product data so the custom event set to currency

isnt necessarily applicable here.

With that said, we can use the custom commerce variable aka the eVar

(s.eVarN=something). A key feature of the eVar is its use of persistent cookies. Each

eVar has its own unique attribution settings and you can control:

How long the persistent cookie will persist for.

Whether credit will be given to the first or last touched (first or last what, right? Whatever

you put into the tag s.eVarN=whatever is in here).

I dont think any cookie expiration length is typical, but attribution to the last item

touched is. There is a great debate regarding the accuracy of this but in my view (without

getting into great detail) I think its the best measurement.

So lets set our eVar to persist for 1 day. When someone comes into the mall we have an

entrance eVar, when someone enters a store we have a store eVar.

Someone comes into the mall -

s.eVar3=west gate entrance

Someone comes into Macys -

s.eVar4=Macys

At days end you can run an eVar report for each custom commerce variable against

revenue and youll see which entrance generated the most revenue and which store

generated the most revenue.

In all fairness in this strange example we could use the store name as the products

variable in the s.products string and eliminate the need for the eVar4 report but thats

too tangential to this discussion.

Another cool thing about the custom insight variable is you can correlate them with other

traffic variables. So if I wanted to know which articles were most popular in my

international news section of my news content site, each time a page was viewed in that

section, the article name would be passed through the prop. Check it out:


4/12

s.channel=international news

s.propN=9 out of 10 politicians at home and abroad are corrupt: public easilyforgets

You could then correlate channel and prop and see how popular articles were within the

section.

If you need consulting shoot me an email at [email protected] or catch me on

LinkedIn:

Traffic Variables

Traffic variables (known to old-timers as sProps) help to track page-by-page site traffic

activity. Site Traffic is normally measured via Page Views, Visits or Unique Visitors. The

primary purpose of sProps is to allow you to breakdown Page Views, Visits and Unique

Visitors into meaningful buckets. While SiteCatalyst provides reports to see total Page

Views, Visits and Unique Visitors for your site, most web analysis needs to take place at a

much more granular level. Without sProps, you would not be able to see such things as

which pages are the most popular or what percentage of pages were viewed in the USA

vs. Canada, etc. The following is an example of the most commonly used sProp report,

the Most Popular Pages report:

Not Persistent

An important thing to know about sProps is that they are not persistent. This means that

they do not retain their value from one page to the next, a concept that often confuses

Omniture customers. I find that the easiest way to understand sProps is to think of the

most commonly used sProp: Page Name. Lets assume a visitor to your site starts their

visit on the Home Page and the value Home Page is passed into the Page Name sProp.

From the Home Page, the visitor clicks on a link and is taken to the Contact Us page.

You would certainly not want the value of Home Page to persist and be passed into the

Page Name sProp on this next page or it would look like the Home Page had two Page

Views instead of each page having one Page View.

Pathing

Another important thing to know about sProps is that they are used for Pathing. Pathing

is the ability to view the order in which values are passed to a particular SiteCatalyst sProp


5/12

for a specific Visit. For example, lets say that each page on your site has a pagename and

the values passed to the Pagename sProp are Page A, Page B, and Page C respectively. If

Pathing is enabled for that sProp, SiteCatalyst would record the order in which the values

were passed and allow you to view reports that show the percentage for which all site

users went from Page A to Page B, etc I will definitely be talking more about Pathing in

a future post.

STEP 2 Assign Events to pages

Example 1: Travel and Hotel industry, using the standard shopping cart events.

View Destination (Hotel) Packages = prodView

Enter Travel Dates = asAdd

Review Order = checkout

Confirm Order = purchase

Example 2: Banking industry, using a combination of predefined e-Commerce events and

custom events.

View Banking Products = prodView

Complete Online Banking Form = event1

Success Confirmation = event2

Example 3: Auto industry, using a combination of predefined e-Commerce events and

custom events.

View Model = prowView

Complete Dealer Request Info Page = event1



6/12

Example 4: General content site where the user can register for access or complete an

interest form, using just custom events.

Request for Information = event1


STEP 3 TAG PAGES WITH EVENTS

Example 1: Travel and Hotel industry, using the standard shopping cart events.

View Destination (Hotel) Packages page

s.events = prodView

Enter Travel Dates page

s.event = scAdd

Review Order Page

s.events = scCheckout

Confirm Order page

s.events = purchase

Example 2: Banking industry, using a combination of predefined e-Commerce events and

custom events.

View Banking page

s.events = prodView

Complete Online Banking page

s.events = events1;

Success Confirmation page

s.events = events2;


7/12

Example 3: Auto industry, using a cobbination of predefined e-Commerce events and

custom events.

View Model page

s.events = prodView

Complete Dealer Request info Page

s.events = event1

Success Confirmation

s.events = event2

Example 4: General content site where the user can register for access or complete an

interest form, using just custom events.

Request for Information page

s.events = event1

Success Confirmation page

s.events = "events2";

EVENT INCREMENTOR COMPONENT

The event incrementor feature allows a custom amount to be specified for a specific

event. The incrementor is most often used for tax or shipping and handling fees.

SYNTAX

The syntax to use the event incrementor is as follows, adding another filed to the

products string:

s.products=Category;Product;Qty;TotalPrice:eventN=Increment Amount;


8/12

By default, success event are configure as Counter type events (as discussed earlier in

this section). Counter events simply count the number of times a success event is set.

Some success event applications (especially when incremented in the product string

instead of on the page) require that an event be incremented by some custom amount.

You will usually want to change the event type either Number or Currency when

incrementing via the product string. Because the incremented amount is set in the

product string the incrementor applies to individual products.

Conversion (Success Events) [Inside Omniture SiteCatalyst]

Friday, 8 August 2008 @ 6:00, by Adam Greco

SiteCatalyst Conversion Variables

Omniture SiteCatalyst breaks its variables into two types: Traffic and Conversion. As

discussed in my last post, Traffic Variables allow you to segment traffic metrics (i.e. Page

Views) and utilize Pathing, whereas Conversion Variables allow you to quantify and

segment the success actions taken by your site visitors. The Conversion area of

SiteCatalyst is made up of two distinct variable types - Success Events and Conversion

Variables (also known as eVars). In this post I will discuss Success Events, followed by

Conversion Variables in my next posts.

Success Events & KPIs

Before exploring Success Events, it is worthwhile to discuss Key Performance Indicators

(or KPIs). Hopefully you are familiar with the term, but just in case, KPIs are the metrics

used to determine the health or success of your website. If the goal of your website is to

get visitors to purchase things then your KPIs might be Revenue, Orders & Units.

Alternatively, if the goal of your website is to generate leads, then you may monitor a

Leads Generated KPI. The reason I bring up KPIs here is because most website KPIs

take the form of Success Events in SiteCatalyst so the two go hand in hand. When I begin

working with an existing client, the first thing I look at is whether the key actions they


9/12

want visitors to take on their site are defined as Success Events and if so whether these

Success Events have data. Unfortunately, more often than not, I find that clients have

done much more with their Traffic Variables than they have with their Conversion

Variables.

SiteCatalyst Success Events

SiteCatalyst Success Events are Conversion Variables that count the number of times site

visitors complete an action on your site. Unlike Traffic Variables which serve as

dimensions or breakdowns of a Page View/Visit/Unique Visitor metric, Success Events are

always numbers. Through tagging, you tell SiteCatalyst when users have taken the

action(s) that you want them to take and Success Events are increased accordingly.

Therefore, each SiteCatalyst Success Event has an associated graph that shows its metric

total for any given timeframe (see example below).

Success Events can be either Standard or Custom. Standard Success Events include a

select few actions that are prevalent on retail websites such as Revenue, Orders, Units,

Cart Additions, etc Custom Success Events are available for use for any site action you

deem worthy of tracking. Omniture provides the ability to have up to 86 Success Events,

though many of these are reserved for use in Genesis Partner integrations (future topic).

As a rule of thumb, I tell my clients that if there is an action on the website that is

fundamental to the existence of the website, it should be tracked as a Success Event. If

you or one of your co-workers wont get promoted (or fired!) based upon the outcome of

the Success Event, it may not be worthy of being a Success Event. In reality, I find that

most of my clients use fewer than 20 success events, mainly to avoid analysis paralysis!

Conversion vs. Traffic

One area where I see clients get confused is in the relationship between SiteCatalyst

Traffic Variables (also known as sProps) and Conversion Variables. In SiteCatalyst, there is

a clear distinction between these variable types such that each variable type has its own

specific purpose. When you think of Traffic Variables you should think about Page Views,


10/12

Unique Visitors and Pathing. When you think about Conversion Variables you should

think about Purchases, Lead Form Submissions, etc

In SiteCatalyst, you would never attempt to segment/breakdown Success Events by a

Traffic Variable (You can do this in Omniture Discover, but not in SiteCatalyst). For

example, in my last post we saw an example where Page Views were broken down by

language (English or Spanish). In SiteCatalyst, you would not breakdown a Revenue

Success Event by the Language Traffic Variable to see Revenue where visitors preferred

Spanish. This is because the primary purpose of Traffic Variables is to count Page Views

and enable Pathing, not break down Success Events. However, dont panic because in

subsequent posts we will learn how Conversion Variables allow you to do this and much,

much more!

Real-World Example

Lets say go back to our fictitious Omniture client Greco Inc., which has one of its web

properties in the Online Education space. A key component of their online education

website is to get visitors to view a demo of an online course so they can get a flavor of the

overall experience of being an online student. In this case, when the visitor clicks to view

the Course Demo, Greco Inc.s marketing manager works with IT to set a Success Event

and thereafter can track the progress of this metric using the associated SiteCatalyst

report:

In summary, this post covered the basics surrounding Success Events and when they

should be used. In future posts I will cover the following additional items related to

Success Events:

Adding Success Event reports to dashboards for dissemination to website stakeholders

Downloading Success Event data to Microsoft Excel so it can be merged with other data


11/12

Using Success Event data in SiteCatalyst Calculated Metrics and Conversion Funnels

Setting Alerts to be notified when Success Event data changes

Ensuring Success Events are not set more than once (de-duplication)

More advanced uses of success events

In the last two posts we have begun to learn about Omniture SiteCatalyst Traffic Variables

and Conversion Variables (Success Events). As previously discussed, Traffic Variables

allow you to segment or breakdown Page Views, Visits and Unique Visitors, while Success

Events capture metrics around conversion actions taken by site visitors. In our Traffic

Variable post we saw how we could segment/breakdown Traffic metrics by Language, but

learned that Success Event metrics are not broken down by Traffic Variables in

SiteCatalyst. So what if we want to be able to show the percentage of Lead Generation

Form Submissions broken down by Language? Perhaps we want to see Shopping Cart

Additions broken down by Zip Code or Campaign Tracking Code. There are lots of cases

where you will want to segment/breakdown Success Events in a similar manner that

Traffic Variables allow you to break down Traffic Metrics. So how do we do this?

Conversion Variables to the Rescue!

The purpose of Conversion Variables (also known as eVars) is to allow you to breakdown

Success Event metrics in a similar manner that Traffic Variables allow you to breakdown

Traffic metrics. While this sounds easy, Conversion Variables are actually one of the most

confusing topics for SiteCatalyst customers because there is a lot to learn about how they

behave (which is why this is only Part I). I will describe the key points here and then try to

make sense of it all through some examples.

Unlike Traffic Variables, Conversion Variables are persistent meaning that once a site

visitor gets assigned a value, that value sticks with them until you (SiteCatalyst

Administrator) tell SiteCatalyst to clear it out (unless the user deletes their cookies or uses

a different computer). For example, if you have a Conversion Variable that stores the


12/12

custom variables_custom events

Documents