Why Context Data is cool when you have multiple Report Suites

A very, very long time ago, when the world was in a much simpler shape, when there was only simple, one-cell life forms in some murky ponds, and the air had high levels of CO₂, NH₃, and CH₄, when temperatures were much higher than today, and rain would fall for millions of years on end, making the Archean a really bad holiday destination for time travellers… sorry, slightly overshot here.

Back in 2014, I told you that one good use for Context Data was when you wanted to consolidate tracking on different and differently configured sites into one Report Suite.

It’s been 7 years, so maybe now is the time to explain that in a little more detail.

In those 7 years, we have seen the emergence of Virtual Report Suites. For most people, VRSs are a good way to split their overall pool of data into manageable chunks tailored to individual or groups of stakeholders.

Today, if you need separate reporting for the UK and France, you no longer track into two Report Suites. Instead, you track into one, “global” Report Suite, then use VRSs to separate “UK data” from “France data”, so to speak.

If you haven’t consolidated, here is how Context Data can help you.

The Situation

Let’s stick with the example above.

You have a UK site and one for France. They are similar in form and function, and the tracking is mostly similar, too, except for some smaller differences in assignments of events and eVars.

I’ll be specific, here, so that we can look at the solution in detail.

Say the UK site tracks page name into pageName, prop1, and eVar1. It also sets an extra event (event1) called “Page Views (custom)” on every call.

The French site, on the other hand, tracks page name into pageName and eVar4, the language into eVar3, and it sets event4 as “Page Views (custom)”.

There clearly is a mismatch here!

So, if we wanted to consolidate, there would be questions:

• How would you we do it? Hard cut? Temporary double-tracking?
• Which Report Suite would we use?
• What would happen to the mismatched eVars and events?

This article is about Context Data and technicalities, so we won’t dwell on question 1 too much. Let’s just say that it might make sense to track everything into the UK Report Suite from now on (making it the “global” Report Suite), and to also track the data for the French into their existing Report Suite for some time, so that they have historical data without undue breaks or effort.

The Solution

The other question, then, is: what would happen to the mismatched eVars and events? And is there some way to mitigate any issues?

Short answer: there is, Context Data!

Long answer: this can be done in 5 steps.

1. Add missing “variables” to the “Global” Report Suite (fka “UK”)
2. Create Processing Rules on the “France” Report Suite
3. Change tracking on the French site, slightly
4. Create Processing Rules on the “Global” Report Suite (fka “UK”)
5. Change tracking on the French site, again, even more slightly

Let’s walk through those three in detail.

Add Missing “Variables”

In the example above, the French site is tracking language into eVar3, but the UK site does not track language at all.

So the first job would be to decide whether language was needed.

If so, is there a free eVar in the UK Report Suite that could be used?

You are lucky, there is: eVar22 had been earmarked for something that never happened, and so it is available.

This case, adding a “variable” is the easiest. Sometimes, data would be missing, and we would have to think about default values, or maybe “data that only makes sense in a specific VRS” (which would be fine!). Or sometimes, there might be data points that are very similar, but not quite a match.

I guess in those cases, we would have to discuss with the two businesses, figure out why they need the data.

Three possible outcomes, or maybe four: 1) the data is not needed, really, and so we drop it, 2) we agree on how one of the sites does it, and align the other, 3) we find an approach that both sites like, and we change the tracking for both, or 4) we cannot find a solution, and so we keep tracking both (meaning we need another free eVar in the new global Report Suite).

You may or may not be surprised to hear that I do not like outcome #4, but that it is by far the most likely to happen.

OK. Next step.

Processing Rules for “France”

You are going to switch some data to Context Data. If you remember what I wrote 7 years ago, then you know that Context Data has to be copied explicitly using Processing Rules.

So these are the first step, let’s create them.

This time it’ll be very easy: You need one single Rule, like this:

This Processing Rule takes whatever is in the “language” Context Data and puts it into eVar3. It also copies pageName into eVar4 and sets event4.

It only does this when the tracking call contains a “customPageView” Context Data Element, which you will send on Page Views, only.

At this stage, you can proceed to changing the French site to send Context Data.

Change Tracking

Now, on the French site, you can must change the tracking.

So you log into Launch, find where eVar3, eVar4, and event4 are being set (may I recommend the excellent Launch Parser by Urs Boller for this? It can search our Library…), then remove those.

Instead, you set the “language” and “customPageView” Context Data elements.

You can do that in a Custom Code Action, like so:

s.contextData["language"] = "fr";
s.contextData["customPageView"] = "customPageView"

You could also use an Extension (there is one, I know, more on that later).

Once you have made the changes, you should see if they worked. That is really easy to do. Just look at the URL of the tracking calls sent on the site.

What would originally have looked something like this (lots of parameters omitted):

https://REDACTED.sc.omtrdc.net/b/ss/REDACTED/10/JS-2.22.0-LBQ1/s4982150407448?AQB=1&ndh=1&pageName=home&v3=fr&v4=home&events=event1&AQE=1

Should now look more like this:

https://REDACTED.sc.omtrdc.net/b/ss/REDACTED/10/JS-2.22.0-LBQ1/s4982150407448?AQB=1&ndh=1&pageName=home&c.&language=fr&customPageView=customPageView&.c&AQE=1

It is important to make sure that eVar3 (v3), eVar4 (v4) and event4 are nowhere to be seen on the tracking call!

And with that, you are almost done.

At this point, tracking on the French site should not have changed, at all.

You have changed the way the data is “transported”, from eVars and an event to Context Data, but the overall setup is the same because the Processing Rules copy the data back into said eVars and set the event.

Processing Rules for UK

Now it is time to prepare the new “Global” Report Suite to receive that data.

For that, you create a Processing Rule on this Report Suite.

This is the crucial point in all of this: Processing Rules are specific to Report Suites!

So, for the “Global” Report Suite, you would create a very similar, yet different Rule, like so:

Change Tracking (again)

With all of this in place, the “Global” Report Suite is now ready to receive data from the French site.

So you go back into Launch, into the Property for the French site, into the configuration of the Analytics Extension, and you add the Report Suite ID for the “Global” Report Suite to the already listed “France” Report Suite, effectively telling the French site to track into both.

Note that if we had decided on a cut-over, we would replace the rsid for the French site, rather than adding a second one.

And to be really sure that everyone gets this: if you add a second rsid, you will incur cost!

One last check to see that the tracking calls are actually going to both Report Suites, and you’re done.

Notes

There may be situations that call for more complex Processing Rules. But the basics are always the same:

Change tracking so things are “transported” in Context Data, then add Processing Rules on all the Report Suites that are concerned to channel that data back into the respective eVars and events.

I know I may sound like a broken record: Processing Rules are per Report Suite.

This is the important part here, and the part that makes them so versatile in this situation.

A note on sending data into Context Data using Launch: I do not like Custom Code, you probably know that.

I wrote an Extension, some time ago, that would allow you to set Context Data from the Launch UI.

Feel free to use that!

By today’s standards, the Extension looks incredibly ugly, though, so if someone would like to spruce it up, feel free!

It is also missing an Action Type that would be really useful in our scenario: an Action that would allow you to set a specific eVar as Context Data, and automatically remove it from the tracking.

Again, feel free to write that code. You could fork my Extension, use it as a base, or you could send me a PR. Both would be awesome!

And one last note: very soon, in a situation like the above, the actual question will be “shall we move to the AEP Web SDK?” and the answer will be “Yes!”

I have waited 7 years to post this, and now the expiry date on this article is coming up fast.

Unfortunate.