Processing Rules in SiteCatalyst version 15

Processing Rules in SiteCatalyst version 15

For those of you who follow my blog and were expecting a post detailing which if of my six things that I wanted for SiteCatalyst version 15 actually got implemented in version 15 have been disappointed for the last 14 months. They’re going to continue being a little disappointed as well, because I’m only going to discuss two of them in this post. Sorry. That one is number one on the list and number two, which have both been done through a similar new feature called processing rules.

What are Processing Rules?

Processing rules allow you create rules on your data in between it being collected and presented in reports. More specifically for those who use them, they process data before it gets to the VISTA rules.

This is very important as previously if you wanted to change the way your set up worked you’d have to change the code on the page before you could do anything. This meant you might have to wait for quite a long time before you could start collecting data. Now you can set the rule up and it will start processing the next day.

How Do I Get Processing Rules?

It’s not easy. No, Adobe don’t just want anyone to get access to the rules because they could cause all sorts of chaos with the account.

Firstly you have to have version 15. These rules don’t work in version 14.

Secondly you need to pass a little test, which is slightly more complicated than it sounds. Be sure that you read the instructions on the test centre. My advice, without wanting to give away what the exam is about, is to scrub up on context data variables.

At the moment the test is free (look up knowledge base 10655 for the detailed instructions), but don’t bank on it always being free!

What are Context Data Variables?

This is a very convenient sub section of this blog post, isn’t it? Context data variables are variables that you can set in your on page code that don’t have any effect.

Sounds odd, doesn’t it? Taken out of context of processing rules they make little sense (apart from in VISTA rules), but in the context of processing rules they make a lot more sense.

So the rules are that they are set like:


in the html on the page (or in the s_code through an automated route). So for this blog post I could have:


and now I have a variable that is being passed through, but not populated in any reports at the moment.

This allows me to decide at a later date which variable I want to put that data into through processing rules.

How Do I Create Conditions For My Rules?

Conditions for the rules are vital and you should think about this long and hard before you create rules about the conditions that you put on them. It’s rare that you’ll want to blanket your rules on all of the values that you have associated with them, so think about when and where.

You have many more options for conditions than you do for actions. There are a whole list of variables that you can create your conditions on, that you can’t take action on (more of that in a second). Most notably you can take information from the referrers without being able to do any action to change the referrer.

This won’t help solve the problem that some of your twitter referrers are now instead of, for instance, but it might help you isolate them into another variable by creating a condition that if the referrer is or then it puts the value into another report.

What you can create your conditions on is the value of any of your existing standard or custom conversion and traffic variables, plus any of your hit attributes (referrer, user agent, IP address, etc). Interestingly you can also use query strings of urls and query strings for referrers – this is useful where you’ve forgotten to put campaign codes on links into the site.

Note that you have a number of options for you conditions, as you’d expect. You can use it for situations where the value is equal to something – this will create specific conditions on an only option. But you can also set it when values start, end or do not start or end with your option. There is also an option for if the variable has been set or not. This is useful for populating a report where you’ve forgotten to do it in your s_code (particularly important on your pathing reports!).

How do I Create Actions For My Rules?

The actions you can do are slightly limited. You can change any of your custom variables that you could set in the code on the page is a good rule of thumb (with the exception of the products variable).

This rather conveniently includes setting events. Going back to my original post from last year was the annoyance that I couldn’t set events based on rules in the background and this effectively solves that problem. I also suggested that I’d like to default custom traffic variables being copied to custom conversion variables – you can effectively do this through the processing rules as well.

On a side note, I’d recommend doing both these things through the coding on the page if you can (or via these rules until you can do it through the code). You are limited to 50 rules, so you could only do 50 of your custom variables.

Your action rules allow you to do a number of things:

  • Overwrite data with new data. Although technically this is called overwriting, if your variable isn’t set in the first place you are overwriting a blank value. Note that these processing rules happen in order, so if you overwrite a variable in rule one, in rule two you are going to be looking at the variable you have overwritten, not the original variable set on the page. You can overwrite conversion variables, traffic variables and standard page related variables (page names, urls, hierarchy, etc). They don’t have to be the same variables that you set your conditions on in the first step. You can overwrite them in the following ways:
    • A value from another variable (so you could choose to overwrite prop1 with the value from eVar 1 for example)
    • A concatenation of other variables (so you could overwrite prop1 with the value from eVar1 and eVar2)
    • A custom value (so you could set your prop1 to be ‘Alec’ if you really wanted to, based on your conditions)
  • Delete the value of the data. Again this doesn’t have to be the same variable as the one you set your condition on, but you can remove the data point if you decide that you’ve set it in the wrong place.
  • Set an event. You can set any event that you like and you can tell it to be whatever value you like, including making it equal to any other conversion variable, traffic variable or event.
Some Examples of Processing Rules
Off the top of my head here are some common examples of places you might want to use the variables:
  • Creating a custom conversion variable for your referring domains, keywords, etc report. This sounds slightly ridiculous – copying one report to another, but custom conversion variables have one slight advantage over the standard referrer reports. That difference is the ability to do SAINT classifications on them.
  • Capturing different campaign parameters in the same report. One common mistake is using the wrong campaign parameter on inbound links and it being too late to do anything about it after it has been created. Using this report you can capture your campaign variables in the campaign report irrespective of how they were set up. There is also the option of creating campaigns where none existed before by using the rules to create a new campaign
  • Creating conversion events in a similar manner to Google Analytics. If you want to create some rules for your conversion events then this is possible here.
  • Split your campaign variables into different reports. If your affiliate time out window is 90 days, but your paid search time out window is only 30 days you’d probably want them in different eVar reports so that you can match them with how the third parties report with their expiry rates. However you’ll also want them in the same report so that you can monitor their performance in a standard way.
And many, many more. I’m sure I could go on for ever!

Leave a Reply

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