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.

15 thoughts on “Context Data Variables & Processing Rules

  1. Pingback: Migrating to Tag Management | Web Analytics for Developers

  2. Pingback: Tracking Apps vs Web Pages | Web Analytics for Developers

  3. Pingback: Redirect Tracking | Web Analytics for Developers

  4. Pingback: “Data Layer” Tips | Web Analytics for Developers

  5. Pingback: 2 Good Reasons to use Context Data | Web Analytics for Developers

  6. Pingback: Processing Rules – Positive or Precise | Web Analytics for Developers

  7. Pingback: At the Oscars | Web Analytics for Developers

  8. Pingback: Cross-Device Linking – what Adam said | Web Analytics for Developers

  9. Pingback: KPIs and Success Events | Web Analytics for Developers

  10. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  11. Pingback: Analysing Mobile Apps – Tagging | Web Analytics for Developers

  12. Pingback: Analysing Mobile Apps – Analysis | Web Analytics for Developers

  13. Pingback: Using Data Feeds for Debugging | Web Analytics for Developers

  14. Pingback: Tagging Forms (w/o Losing Money) | Web Analytics for Developers

  15. Pingback: Using Analytics Live Stream | Web Analytics for Developers

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