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:

[Screenshot]

Context Data in the Debugger

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:

[Screenshot]

Processing Rule for Author Data

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.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Tagged with: , , , , ,
Posted in Javascript, Page Code, Principles
15 comments on “Context Data Variables & Processing Rules
  1. […] blog article with s.pageName, two events and an eVar. Later, we will provide an example with Context Data Variables, which in theory should be […]

    Like

  2. […] you are using Context Data Variables and Processing Rules, of course. If you tag a mobile app, you should use Context Data Variables if only for this reason! […]

    Like

  3. […] tracking (plus plugins), tracking w/o Javascript, tracking links & actions, tracking apps, Context Data & Processing Rules and server-side data modification, you have a huge arsenal at your disposal to make pretty much […]

    Like

  4. […] Remember Context Data Variables & Processing Rules? […]

    Like

  5. […] friendly marketer has to set up Processing Rules to get the data into the right reports, but the point is that those rules are report suite specific […]

    Like

  6. […] last year, while discussing Context Data with a web developer (which in turn led to me explaining “variables” in Adobe Analytics […]

    Like

  7. […] is that instead of aligning “variables” across all report suites, you switch to using Context Data & Processing Rules on those that are different, allowing for an easier […]

    Like

  8. […] could create a Processing Rule that sets the event on the “Thank you” […]

    Like

  9. […] is the same as on the web. You identify actions and track them. With the Mobile SDKs, you use Context Data “Variables” to do that. Success Events, props and eVars do no longer work. Remember the article on Apps vs […]

    Like

  10. […] how I did not once talk about specific “variables” or Processing Rules at all! You essentially get a lot of very tailored and therefore useful stuff right out of the […]

    Like

  11. […] are sending, with a notable exception: Context Data is NOT part of the Data Feed unless you have a Processing Rules that copies the data into a […]

    Like

  12. […] you are using Context Data or a Data Layer: just send the data with a nice, self-explanatory […]

    Like

  13. […] hits go through Processing Rules and VISTA, the visitor profile is applied, but that is it. They are pretty much the same data that […]

    Like

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

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: