2 Good Reasons to use Context Data

My colleague Carl Sandquist recently wrote “Although you may get a bit teary-eyed bid­ding farewell to expound­ing on the dif­fer­ences of eVars and props to your devel­op­ers, we’re sure you’ll even­tu­ally get over it.”

He’s obviously right about this: developers will shed no tears if they never have to see props or eVars ever again.

So let’s start the new year with a couple of notes about Context Data Variables.

Name Spaces

With Context Data, you can name space your data.

In the world of online tracking and optimisation, a “Data Layer” is the current state of art. It works a treat with tag management. It is one step towards separation of form and function. It is a good idea.

If you put a lot of meta data into the data layer, you will at some point run into issues with naming the data. Name spacing can help. An example:

The term “section” could describe the site section that a page belongs to. It could also be a section of the actual page, e.g. the header or the left navigation bar.

If you track page load, you would send the “section” that describes where the page sits in the site. On tracking a link click, however, you would send the “section” that specifies where the link was on the page.

If you create name spaces, you can use “section” in both situations and there will be no confusion. Call the former “site.section” and the latter “page.section” or maybe “template.section”.

Context Data supports name spacing, so you can assign a variable like this:

	s.contextData['template.section'] = "left nav";

On a retail site, you could have a name space for the product(s) you are displaying on the page. News web sites could use it for data persisting to the authors.

The great part for you, the developer, is that the data layer is likely your project and therefore totally under your control! I am sure you will have to build it up to support some marketing needs, but how you do it will be your decision. And since most developers are comfortable with name spaces in some form or shape, it shouldn’t be too hard for you to use them.

One word of caution: look at Carl’s screenshot of how it all looks like in a debugger…

You can see that the individual data items are encapsulated between two short URL parameters which act as a “name space on” and “name space off” pair. If your name space is called “page”, you would have one URL parameter called “page.” before your data and one called “.page” after it.

So, hold back on the length of your name space designations! You might otherwise run into issues with browsers not sending any tracking because the URL of the GET request is too long. Older IEs are notorious for this.

Maybe call it “tm” instead of “template”, and “p” instead of “page”. Make sure your marketer still has a list of what your name spaces mean! They are the ones who have to map the data to props and eVars!

Consolidation

Carl mentions this at the end of his posting, but I think it deserves more space: Context Data is great when you have a lot of (regional) report suites and you want to standardise, be it for multi-suite tagging or just because.

Let me explain the problem.

Suppose your company is running retail sites in two markets, say the US and the UK. Both markets have individual marketing teams, and both sites have in the past been tagged up with Adobe Analytics.

Unless the teams worked together and had similar goals and similar maturity, it is likely that the tagging on the two sites is not identical. The US site might store page section in s.prop2 while the UK site puts it into s.channel.

Now leadership has decided that they want to roll out to more countries. And they want a global view as well.

One way of creating a global view is to use multi-suite tracking, which basically means sending data to more than one report suite. (This can easily be done by listing more than one report suite ID (or “rsid”) in the s_account variable in the configuration section of the s_code.js file.)

Each individual site will be set up to track into an individual report suite plus a global report suite that is the same for all sites.

Now here’s the issue: because the UK and US sites do not use the same “variables” for the same data, the global report suite has mixed data in some reports. Not nice, not pretty, and certainly not useful.

Changing the implementation of either the UK or the US site would deal with this, but the changed site would in essence loose their historical data, or rather the continuity. If your friendly marketer wanted to see a report about site sections, she’d have to check one report for the time before the changes and another one for the time after. This is of course totally impractical.

But you can still do it, using Context Data!

The idea is to switch tracking on one (or both) sites to Context Data instead of the traditional props and eVars.

Your 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 and she can therefore set up rules on the UK report suite that match the old tracking and at the same time set up rules on the global report suite that match the new, standardised tracking!

The up side is that continuity is assured for the UK and at the same time the global report suite gets clean data.

You can easily see that for the rollout to the other sites, it makes sense to start straight with Context Data as well, of course.