Context Data Variables & Processing Rules

When Processing Rules were first released in SiteCatalyst 15 in 2011, they were perceived by many as a light-weight alternative to VISTA Rules.

That’s not entirely wrong. The big improvement that they brought, though, was their usage in conjunction with Context Data Variables. It really makes sense to mention both together.

So, what are Context Data Variables & why do Processing Rules make most sense along with them?

Context Data Variables

Let’s look at the normal “process” when a web site is tagged:

• A marketer discusses analytics with a consultant
• They agree on a set of analytics “micro-solutions” that they think should be deployed (like Shopping Cart Analysis or Internal Search)
• They draft a “Solution Design Reference” or a “Tech Spec” that contains a list of “variables”
• The marketer then hands that list to a developer — you.
• As a developer, you do not necessarily know what a “Success Event” is, a “prop” or an “eVar”.
• You’ll end up talking to the consultant, who will try to explain to you how SiteCatalyst works.
• You tag.

The result will be some Javascript code on your pages.

There can be friction in a couple of places in the process.

Enter Context Data Variables.

The idea is that developers should not have to learn yet another system and nomenclature. They should be able to simply dive in and produce code.

The friendly marketer should be able to say something like “we need to track the author on blog articles” and the developer — you — should be able to just do that, without having to look at some variable assignment matrix or a huge Excel sheet.

So how does it work? Technically?

In essence, Context Data Variables are the Adobe Analytics version of Hashmaps.

The example would look like this:

    s.contextData['author'] = "Jan Exner";

In my books, that is a definite improvement over something like:

    s.eVar64 = s.prop64 = "Jan Exner"; // author in prop64 & eVar64

Two reasons:

1. Easier to understand & code.
2. Less error-prone and easier to review.

I think it is pretty obvious how this makes development better and probably faster as well.

It even makes debugging easier. Look at how the system transmits Context Data Variables over the wire:

All of the Context Data is on the URL between a “c.” and a “.c” parameter. And it is as easy to spot as the variables themselves. Look for “author=Jan Exner”. Yup, there it is.

But how does the backend know how to create reports?

Processing Rules

This is where Processing Rules help.

When the data arrives on the collection servers, Processing Rules can put it into the right place, be that a prop, an eVar or an event.

What that does is move the responsibility of the mapping to where it should be: into the hands of the marketer and the implementation consultant.

It also allows the marketer and/or implementation consultant to change where the data goes at any point without implementation changes. This is useful in most cases and almost vital for mobile apps!

Let’s look at an example:

The rule contains three parts:

1. A condition — Context Data for “author” must not be empty.
2. An action — copy value into eVar64.
3. A second action — copy value into prop64.

On pages where the developer — you — has set an author, the Processing Rule will populate both eVar64 and prop64.

Easy.

Attention! One really important thing: if data that sits in a Context Data Variable is not assigned to some variable using a Processing Rule, it will simply not be tracked at all!

Notes

In case your friendly marketer doesn’t know what Processing Rules or Context Data Variables are, send them to this blog article!

Before using Processing Rules, users of Adobe Analytics have to pass an exam. The exam is not overly difficult, and there is a “cheat sheet” available that will both help with the exam and also with the creation of rules later on.

The cheat sheet can be found here: Processing Rules Cheat Sheet – A4

Being a developer, you know that if a change can potentially impact existing data, you should be extra careful and ideally have someone look over your shoulder while you make the change.

My suggestion would be to explain to your marketer what “pair programming” is and why they should do the same when working on Processing Rules.