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)





Tagged with: , ,
Posted in eVars vs sprops

SiteCatalyst – Never data-warehouse it when a data extract will do

I’ve seen people rely on data warehouse to pull some pretty simple reports. Make sure you’re taking advantage of the ‘data extract’, which allows for quick and typically ‘by date part’ generation of csv’s of for some combo of [date + dimension] Here’s an example – someone asks for a quick overview on some specific email tracking code, but they’re not sure what exactly it was. They just know it had a ton of traffic several months ago.

data extract interface sitecatalyst


Under “more actions” select ‘extract data’, then in order to get the date you need to click on the blue date about the table builder. Then change the granularity to ‘daily’. Then your table will look like mine.

After that, grab say, the top 500 tracking codes by visits, add other metrics and voila, after a quick email and pivot table you can find whatever it is they were trying to figure out what ‘drove a ton of traffic’ a ‘few months ago’. The nbr of rows will be:

days * nbr daily tracking codes

If you need more than 2 columns of segments, sorry, gotta use DW or perhaps a quick session in ad-hoc analysis (formerly Discover). But that’s annoying sometimes and has limited utility for pure data extraction. It’s more of an exploratory tool or something to pick-up on trends (reasoning after the fact!).



Posted in sitecatalyst data extract

Using SiteCatalyst to Manage or Analyze Paid Search

Someone emailed me a question – how do you use SiteCatalyst to manage paid search? My best answer is, you do not.

I’m not saying to avoid using it, but have realistic expectations regarding what it can do for you.

1) Make sure your Google provided, AdWords pixel is set-up properly to measure transactions, leads or whatever it is you’re spending all that money on. That’s free and it works well. One thing to be aware of is the transaction is credited to the “DATE OF THE CLICK” – for a long time I wondered why performance got better over time….it was not an optical illusion.

2) Use SiteCatalyst to identify that your traffic is indeed paid search. The first way to handle this is to update your paid search detection settings – check the screenshot below:


Once you click on paid search detection in admin tools as shown above, you’ll be able to enter a query string parameter that’s consistently in your paid search URL’s. Since you probably have Google Analytics set-up anyway and since you’ve probably linked your AdWords and Analytics accounts, it’s not a stretch to assume that you have ‘auto-tagging enabled’. Here’s further reading on that:  https://support.google.com/adwords/answer/1752125?hl=en

Assuming you do have that enabled, each URL will have something appended to it. Here’s an example from a search I did for ‘web analytics consultant‘ – yes you can get an expert for $10/hr but not me! In fact, my rate is at least an order of magnitude higher so feel free to contact me if you prefer quality work.


Above, note the gclid=gibberish thing. That’s what you want to enter in your paid search detection settings. Ok, you might be wondering, what about the thing after the =? Don’t enter that, “gclid=” is good enough. The crazy alphanumeric string after it will change every click. It’s like a snowflake, no two are ever alike but they’re all cold.

So you’ve done that. Now what reports will be impacted by this? Back in the reporting and analytics section of the world you should have something that looks like this:



The paid distinction runs off your definition of what paid search is under paid search detection. Duh!

BIG PROBLEM – google paid search is encrypted, just like organic search. Translation – it can’t pull the keyword that was formerly accessible as q=what you searched for via the URL. So don’t worry ‘keyword unavailable’ is not an errant expanded broad match result you just spent a ton on 🙂

So after all that work what do we have? Well, you know how much came from Google Paid vs Google Organic. You’ve got your adwords pixel which is a ‘single source attribution’ system and you’re assigning revenue to the date of click. Next time we’ll take a look at why numbers between systems will never match-up and why!


Actually, wait – there’s a masochistic approach I neglected to mention.  You can use Omniture SiteCatalyst Campaign Tracking (gotta get my on-site SEO working) and do the following. Let’s say your campaign tracking parameter is cid. If you don’t know this, check your s_code.js file. If you don’t know that, ask someone else.


Then, using SAINT classifications set-up a hierarchy like

key, campaign, adgroup, keyword

when you download your saint file, you can copy the key column, then text to columns on the pipe | symbol and you’ll hav a 4 dimensional mapping which has your original string, campaignID, adgroupid and the keyword. Now, this will be the term you bidded on. There are various ways to choose campaignID or adgroup including just using the name of the campaign, or having a reference table, or doing something clever with adwords value track – https://support.google.com/adwords/answer/2375447?hl=en.

You can also have other dimensions, mobile, network, etc…blah blah blah – but that’s your call. I don’t know why you’d do this beyond the fact that many people do. It adds complexity, a different system to manage and conflicting data points. But wait, isn’t that half our lives as data analytics folks?

again – YMMV




Posted in sitecatalyst paid search

SiteCatalyst – Key Metrics Report – Why 5?

I think it was the V15 release where SiteCatalyst released the ‘key metrics report’ – which basically allowed you to create a table and or visualization of up to 5 metrics. I’ve been asked, ‘why only 5 metrics’? That might be like asking why there’s one grand canyon, or why clouds are as high as they are….

If this is seriously limiting your work, you might have something to learn about SiteCatalyst, but here’s a workaround:

1 – Go to say, the tracking code report – then under ‘more actions’ – choose ‘extract data’



2 – in the report section, change it to ‘report suite totals’



3 – set-up your date range and granularity (do you want it by day, month, etc…) and add all the metrics you want. To be really clear here,


4 – continue the process and schedule the CSV – it’ll probably come in a few mins unless you’ve gone ahead and asked for something ridiculous.

Happy Extracting,



Posted in sitecatalyst data extraction

FTP SAINT Upload (SiteCatalyst) – the .fin file

One of the nice things about SiteCatalyst (Adobe Analytics) is the longtime feature of SAINT classifications. Why’s it called that?

  1. SiteCatalyst – duh
  2. Attribute – give additional names or categorizations to things
  3. Import – bring it into the system
  4. Naming – see attribute
  5. Tool – “SAIN” just wouldn’t have done it

I believe now they call it ‘classifications importer’ in the admin panel because they changed the name of the product, but us old-school analytics veterans still call it SAINT!

Here’s the deal though – you can’t export more than 50k rows via the browser. More often than not you need to export a csv to an FTP site (ftp.omniture.com and some convoluted user/pass) then import via csv to an adobe specified FTP site. If you don’t have this set-up you either need someone to do it for you, or you need admin access.

One thing you need to watch out for that appears needlessly complex in the documentation is the .fin file, which tells Omniture the import job is ready to rock. What in the world is that? You just spent 4 hours doing vlookups, sorting, manual row edits and finally you have your classified masterpiece but you’ve got a freaking .fin file you still need to generate.

Don’t worry – here’s how to do it:

  1. Take the name of the tab delimited text file you’re about to upload with fresh classifications (let’s use omnitureconsultant.txt) for a keyword rich example.
  2. Open a blank notepad file – leave it blank, really.
  3. Save it as omnitureconsultant.fin
  4. When you’re in your FTP client, edit the file name so that the .fin file is not .fin.txt (see image below)
  5. Drag the big classifications file in
  6. Drag the .fin file in
  7. Wait for an email confirming import (this is specified during the FTP site set-up back in the admin panel). If you didn’t set-up the FTP site, it’s probably going to someone else 🙂



That’s really it. Don’t be afraid to use SAINT – it’s just like adding columns to a spreadsheet so you can slice and dice the data in different ways. There’s also a secondary use which has similar protocol – “data sources”, which allows you to classify data or modify info about products or demand channels (POS) like call center, web, retail, etc…

Stay classified,




Tagged with: ,
Posted in saint classifications

New Content Coming Soon!

Real soon 🙂


Posted in Uncategorized

Belmont Stakes & Randomness


Belmont Stakes

Belmont Stakes 2009

So I went to the Belmont Stakes today and bet on 11 distinct races. 2 of 11 bets paid, one deserves a mention. Upon attempting to place my bet on the 6th or 7th race, $3 to place on 13…I found that 13 was scrubbed; without knowing anything about the race I said confidently, “well then the 7 horse”. And of course, that horse won!

You can never understimate the impact that random events have (and will continue to) on your life…better to know what you don’t, rather than dwell on all you do. 

The other race I bet on a horse to place and it came in 2nd…very high probability horse though. My girlfriend won the first 3 and the 5th race…wow!

Tagged with: ,
Posted in probability
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