eVars vs s.props – a shrewd approach (and custom events)

Some people still might not be happy with the current literature regarding eVars and s.props. Here’s an incomplete cheat sheet if you feel puzzled regarding the difference between s.props and eVars when implementing SiteCatalyst


  • they have a memory, which is based on a cookie set on the browser of the visitor who ‘hit’ the eVar – you control this in the administration console of SiteCatalyst
  • with that memory, the value that you pass into the eVar, can be related to both custom events, standard events (purchases, revenue, add to cart, checkout, remove from cart) and calculated metrics.
  • you can control how long the eVar remembers the visitor who interacted or hit the eVar – this is referred to as the expiration of the eVar
  • you can control how the value that you sent into the eVar, is allocated, for a given visitor, in the event they interact with multiple values – this is referred to the allocation settings of the eVar
  • the none category of an eVar represents the visit or event data for visitors who (whom?) did not interact with or have the eVar set on their machine. That merits an explanation. Let’s say I’m using an eVar to keep track of the last product viewed on my site, but I forgot to implement on a new template that launched last month. In that case, anytime a visitor ONLY viewed a product on that template, or viewed no products at all, will show up in None for that eVar report, since they were never tagged.
  • the eVar only understands what you pass into it – if you send data related to your campaigns into an eVar, it will know nothing about other campaigns, traffic sources, channels, etc…
  • you can classify the eVar using SAINT classifications – to that end, they can function as a nice single source attribution tool if you’re running some type of trackable online marketing (single source meaning the eVar will only keep track of the source whose data is sent to the eVar)


  • you can’t attribute custom events or standard event completions to them – data warehouse or ad-hoc analysis allows for reporting like this, but it’s not as convenient as going into the web interface.
  • they do allow for pathing analysis – this means that I can see the relationships between the values set within a given s.prop (that may need an example)

Let’s say you have a site with 5 main types of pages:

  • Homepage
  • Category
  • Sub-Category
  • Product
  • Checkout

Now, with the exception of the homepage, each other page-type represents perhaps thousands of actual URLs. If you set an s.prop on each template like s.prop4=”Category”; or s.prop4=”Product”;, you could see aggregated statistics for the % of people that pass between various page-types within their session. Note – that you need to use the same s.prop – I used s.prop4 as an example, but you can use anyone you’d like. Note, that by default, only s.pagename and s.channel have ‘pathing enabled’ by default.

If you want pathing enabled for an s.prop, you’ll need to call client care (last I checked) – there’s no additional cost and any support rep should be able to swing it over the phone.  If you have no props (too bad) and you’re trying to understand this, just review your next page flow report, same idea.

So, other than counting the values you pass into them and allowing pathing, s.props aren’t all that great. In fact, if I could only use eVars or s.props, I’d be an eVar guy and I doubt many people would disagree with that. Pathing can typically be handled via smart use of the section (s.channel) and page (s.pagename) to begin with.

What about Custom Events?

Events are just things that people do. eVars are a way to group visitors into buckets so you can view their behavior (the custom event, standard event or calculated metric). eVars are breakdowns, events are actions. A simple analogy – imagine viewing your search engines report – the name of the search engine is the ‘value of the eVar’ and the visits and revenue are the events.

One caveat around events — they can be set to count once per instance or once per visit, if you have a complex site or nuanced user behavior going into your event driven calculated metrics, make sure you check on this setting via the admin panel so you’re certain of what you’re telling people. In the past, event ‘sessionization’ or counting once per visit was a client care call, now it’s DIY.

An instance of an eVar or s.prop (Advanced)

How do you know if an event or eVar is being set? How do you know if it’s been set consistently? Here’s a tip – SiteCatalyst allows you to view a metric about the eVar. Which is like saying a metric about the dimension. Well, it’s a number of times the dimension or eVar is set.

instance of an event - data warehouse sitecatalyst

In data warehouse, under metrics, under ‘custom insight’, you’ll the names of your eVars or s.props, then you’ll see (instance of eVar34) or whatever you called it. If you plot that out by day, if you’re ever suspicious about data quality, you can see the consistency or lack thereof in the eVar instances across the site. This is more of a sanity check than anything – eg, you might compare pageviews on a page that should set an eVar to eVar instances that are set on that page if you’re ever scratching your head regarding the consistency of that eVar being set.

eVar out,


too long didn’t read version:

  • eVars remember stuff you send ’em, control the cookie and allocation
  • props are sort of useless and don’t relate to events or sales data
  • events are actions, eVars are ways of grouping visitors into buckets based on traits or characteristics
  • instances of a prop or eVar are available in data warehouse (per screenshot)






paid search expert, sitecatalyst/omniture consultant, professional search engine optimization

Tagged with: , ,
Posted in eVars vs sprops
One comment on “eVars vs s.props – a shrewd approach (and custom events)
  1. Martí says:

    Good post Jeff. I’ve always thought that props were sort of useless as well, but recently I find a nice application for them to identify customer journeys in terms of KPI’s. Let’s say that you have 3-4 different goals in your site and you want to know how users are flowing between them.

    In this case, you can use a prop (pathing enbaled) that will only be fired when a goal is reached and then, you’ll be able to see the “goal routes” of your users.


    Goal 1 – Goal 2 – Goal 1
    Goal 2 – Goal 3
    Goal 4
    Goal 4 – Goal 3 – Goal 1
    Goal 2 – Goal 2

    It’s a simple trick that can help analysts identify KPI paths @ visit level…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Expert Omniture SiteCatalyst Consultant
jeffrey james - analytics consultant
Try Me - 30 Minute Troubleshooting or Strategy Discussion
View Jeffrey James's profile on LinkedIn - Omniture Consultant, SiteCatalyst Implementation Consultant and Consulting
  • Omniture SiteCatalyst Implementation/Reporting
  • PPC Management - large scale campaigns and scripts
  • Big-site Technical SEO Strategy
  • Google Analytics (and Premium) Consulting
>> Click to Email
%d bloggers like this: