Omniture SiteCatalyst 15: Context Variables & Processing Rules

A big deal was made at the Omniture Summit of the segmentation available in SiteCatalyst 15. While the advantage of this feature is obviosu to everyone, I do not consider this to be the most significant part of the upgrade of SiteCatalyst to version 15. I consider the greatest new feature of SiteCatalyst 15 to be two things, that when put together, could change how every implementation of SiteCatalyst is undertaken and managed on a regular basis. These two things are context variables and processing rules. Below, I will detail what context variables and the processing rules are, and then discuss how they can be used in conjuction to streamline a SiteCatlayst implementation.

Context Variables:

Those familiar with SiteCatalyst are aware of what events, props and eVars are. With the release of SiteCatalyst 15, there is a new type of variable, the context variable. Here’s what you need to know about context variables in general:

  1. There are an unlimited number of context variables
  2. There is no character limits on what you can place in a context variable
  3. You can name a context variable with any name you prefer (meaning that developers don’t need to worry about eVarX, propX, etc.)

To detail how a company might use a context variable, I will provide a code example of custom download measurement via traditional SiteCatalyst variables vs. context variables. The goal here is to track the name of the download, the URL of the download and a success event for the download.

Site Catalyst 14 and Prior (assume eVar1 and eVar2 are set by the implementation):

s.eVar1="download name"
if (s.eVar1){
s.prop1=”D=v1″
s.events=s.apl(s.events,’event1′,’,’,2)
}

s.eVar2="Download URL"
if (s.eVar2){
s.prop2="D=v2"
}

SiteCatalyst 15:

s.contextData['Download Name']="download name";
s.contextData['Download URL']="download url";

That’s it!

SiteCatalyst 15’s solution is a little simpler (at least in terms of coding), huh?! What makes this great is that giving direction to your developer for implementation is extremly straight forward, and anyone looking at these varibles in the code, should be able to easily determine what’s gonig on. Keep in mind that you can make the names of the context variables anything you like. So now that these context variables are in place, the developers are no longer needed in the implementation of SiteCatalyst (for downloads anyway!).

Next, Processing Rules will bridge the gap between the context variables and SiteCatalyst reporting. So below we will continue discussing the implementation of download measurement while using the context varialbes above with the new processing rules.

Processing Rules:

Many may be famailar with Omniture’s Marketing Channel Report and the processing rules that go along with that great feature (if not you should be!). Now, Omniture customers can create processing rules in a similar way that will allow them to set events and variables (as well as more advanced options) based on simple or complex rule sets. To demonstrate how this is done, we will assume that our developers have implemented the two “download” context variables above.

Now you can login to the admin console of SiteCatalyst and setup two easy rules:

  1. If “contextData[“Download Name”]” is set at anytime, move that value to eVar1 and prop1 as well as set event1
  2. If “contextData[“Download URL”]” is set at anytime, move that value to eVar2 and prop2

That’s all you have to do to implement custom download measurement once your context variables are in place.

Context Variable and Processing Rule Caveats:

This could warrant an entire other blog post, but here’s a brief summary of a few caveats of which to be aware when using context variables and processing rules:

  1. You will have to upgrade to the H23 version of the s_code (i.e. Omniture data collection code) in order to leverage context variables.
  2. While context variables can be unlimited in length, you will still need to be aware of the total 2080 character limite in Internet Explorer. Also, the props and eVars within the reporting itself still have their limits. The advantage of the unlimited length is that you could create a processing rule to evaluate the entire context variable’s value. Ex: if a campaign code contains “google” then set eVar3 as “Paid Search.”
  3. Don’t get your hopes up for SAINT here, the processing rules will not populate SAINT classifications.
  4. Context variables are not stored. Once they are captured and used in any processing rules, they are not maintained by Omniture. So, any processing rule (as should be expected) would not work on old context or other data.
  5. Obviously, the improper setup of a processing rule could compromise an entire SiteCatalyst implementation since processing rules are essentially a “VISTA Lite.”
  6. Debugging an implementation could be tricky using context variables. While you can see the context variables in a debugger, it is the eventual processing rules that would determine how a report is actually populated. This means that not only will you have to validate the site-side implementation, but you will also have to validate the setup of any processing rules. Here’s an example of what you might see in a debugger (easy to read, and no more c1, v1, etc…):
    SiteCatalyst 15 Context Variables in Debugger 

  7. The product string, cannot be set using context variables or processing rules. The product string is simply to complex. If advanced manipulation of the product variable is needed, then Omniture Engineering may need to be involved with an actual VISTA solution (unless you can do it on the code-side of course).

So, while segmentation is a great feature (maybe even the one that most users will value), the above features will enable Omniture customers to more easily manage implementations. The post above only scratches the surface of what can be done with context variables and processing rules. If you have any other questions,  leave me a comment below!

14 thoughts on “Omniture SiteCatalyst 15: Context Variables & Processing Rules

  1. I do believe this is the single most interesting thing I’ve read about sc15 yet. My job as an implementation consultant just changed dramatically, didn’t it?

  2. Hey Jason,
    Great article, and very interesting for those of us that weren’t able to attend the summit. Quick question, it looks like what you’re describing here is a complete replacement of evars and sprops to the new s.contextdata variable. Is this the case? And can I then assume that – based on the no-storage of this data – that a better working relationship between the developers and SC admins will be required in order to manage the data? Sounds like an interesting process question..!
    Cheers, J

  3. @Jenni Precisely! Implementation just got a lot easier to handle, and the amount of analytics coding decreased. As an example, you could even create a rule that looks at the URL and grabs a query parameter’s value to place into a variable. No more getQueryParam or coding required. You wouldn’t even need a context variable to do this, just a processing rule.

  4. @James I wouldn’t say that it’s a replacement, but you most definitely could treat it as such (with the exception of using to set the product variable). And in terms of the working relationship between developers and SC admins, I’d say that this makes things easier in that you can share a common language without having to discuss eVars vs. props, etc… You’re definitely correct in that there is a process question to be answered here. I’m not yet sure that everyone should rush right out and yank all eVars, props and events in favor of the context variables and accompanying processing rules. However, from an implementation side I put these on my blog earlier and it was vastly simpler than the old code that I had.

  5. I hadn’t heard of these new features and they do sound really promising.  Will the processing rules allow the admin to use regular expressions when setting variables, similar to the Google Analytics profile filters?

  6. @Peter I do not believe that you can use regular expressions at this time. That’d be a great feature request, and is one that I’ll add to the Idea Exchange. Also, not that not just any admin user will be able to use this tool. You will first have to pass a certification course. At that point, Omniture ClientCare would then be able to grant your specific SiteCatalyst user account with access to that tool within the admin console.

  7. @Jenni I totally agree with you. I think it will make the communication between us implementation consultants and the client’s website vendor a lot easier. Human-readable variable names are definitely easier to understand than s.props and eVars.

  8. Pingback: 15 for 15: Code version H.23.2 released | Web Analytics Pro

  9. I wanted to use the same for an implementation that I am currently doing, but my Account Manager advised against it for a reason that you have not mentioned in the caveats. Could you please confirm if you agree with it. She says:
    Processing Rules is not a direct way of capturing data and direct methods are more ‘reliable’ than such indirect once.
    Hence she suggested that all the variables be captured as far as possible on the page itself.
    Also – am a certified Advanced User – would I still need to go through this separate exam? How can I take it? Is there an associated fee?
    Thanks for the help.
     
     

  10. @Gaurav
    I’d probably agree with your AM at this time. I think it’s a better idea right now to just capture things yourself. Another reason for that is so that you can more easily debug your analytics implementation. If you heavily rely upon processing rules and context variables, then the SiteCatalyst debugger (or whatever tool you use to debug your implementation) may not reflect the data that is actually presented in your reporting.

    As for the exam, it will be separate, there will probably be a fee and I do not believe that it is yet available.

  11. There is no fee for the exam, it is simply 30 multiple choice questions across 6 pages and it quite straightforward.

    Regarding GetQryParam, processing rules are now considered the “modern” way to parse out URL payloads but remember no de-duplication as GetValOnce would not be deployed.

    There will be people that say that it is dangerous to use this as a “sticking plaster” approach however we all know that in the real world we have deadline and DevQues, so this can only be a good thing.
     

  12. Pingback: #AdobeSummit Takeaways: My Favorite Tips | Gilligan on Data by Tim Wilson

  13. Thanks! great post Jason.
     
    I was wondering how is this different from using the Dynamic Tag Management System or any other Tag management system.  We define variables in the data layer and using the TMS set the variables (eVars, sProps and events).  thanks in advance.

  14. Areef – The primary difference there is that while these these context vars are just normal JS vars, the syntax I’ve shown here is the only favorable syntax that can be used so that the values passed in are available to be used by the processing rules on the Admin side within Adobe Anlaytics. This still requires you to place custom JS on the pages of your site as well of course.

    DTM (Dynamic Tag Management) can use any JS vars or objects (or anything existing on the page really) that you place on a page and then set the appropriate analytics events, variables, etc, on the client side of things. In general, DTM is much more powerful than these context variables and processing rules. If you have any questions about DTM our would like to see a demo, just give me a shout. DTM is in place on this blog as well. It’s been much easier to get my analytics in place here than it ever has been in the past thanks to DTM.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>