Quick Tip: Save Variables

In the post about “Variables” I neglected to mention one important characteristic of Adobe Analytics: with each Report Suite, you get 75 props (traffic variables), 75 eVars (conversion variables) and 100 events.

Now everyone who has ever worked in the field will tell you that 75/75/100 is ample for everyone. And it really is.

But sometimes, marketers or analytics teams disagree.

So how about I share a tip that you can pass on? It should make you look good!

Save “Variables”

Remember how these “variables” are like buckets? You put a label onto a bucket (“page language”, for example), then you throw values into it (“en”, “fr”, “de”, …). The system then builds reports essentially by counting the values in each bucket and presenting the count in a UI.

And what I said above means: there are 150 buckets in total that you can use. 75 of them behave one way, the other 75 a slightly different way. But they are still buckets.

Given that there are 75 + 75 of them, what happens if your marketer wants to have more different labels? What if he has used all available buckets?

My tip: combine them, then use SAINT to separate at report time.

Let’s go through an example.

Presume that we are using prop1 for page language and prop2 for site section.

On any given page, the code could include these lines:

	s.prop1="en";
	s.prop2="women:dresses";

I am not going to go into much detail about what reports your marketer can get out of this, suffice to say that they can see the most popular page languages and site sections in two separate reports.

We can free up one of these traffic variables.

Let’s remove prop2. All we need to do is track the values into prop1 as well, like so:

	s.prop1="en|women:dresses";

See what I did there?

I used the “|” symbol to separate the two values but I wrote them into one single traffic variable. The other one is now no longer needed. Success!

Well, partly.

At this point, your marketer will hate you.

Instead of their good old report on languages, they now get one that mixes languages and sections, which does not help.

Classification Rule Builder to the Rescue!

You (or your friendly marketer) can create a classification on prop1 that mimics the old separation, like so:

[Screenshot]
Classified Combined Variable
In order for the actual values to be classified correctly, you use SAINT Classifications.

You would normally download all values, assign the classifications in Excel, then upload the file back into SAINT. Tedious. And outdated!

Since the release of the Classification Rule Builder, you can automate the classification of values like we have here.

You basically set up a rule that says “split this thing at the ‘|’, use first part as language, second part as section”.

[Screenshot]
Sample Rule for Splitting Values
You need two rules because you want to split into two values:

[Screenshot]
Set of Two Sample Rules for Splitting Values
The system now scans all values every night and applies the right classifications itself.

Success!

Notes

Check how many values you have in each variable and how many valid combinations exist! If the number of combinations is very high (exceeds 500000), you might want to pick different variables to combine.

The variables that you combine do not have to be related in any way! You could combine “gender” and “language” or any other combination that you are currently tracking.

One big restriction: for the metrics to make sense you really only should combine values that are actually being set in the same situation.

The example we used — page language & site section — works well because those two will be set on every page of the site.

Especially for the eVars, you really need to make sure only to use this method when both values are being set. Remember how eVars persist? Well if you put two values into an eVar, then later only overwrite one (maybe s.eVar15="|blue";), you are effectively also overwriting the first part, only with an empty string.

Also: for eVars, the settings of the two variables that you want to combine have to be identical! And for props, do not combine those that are used for Path analysis.

There you go, one handy tip for your marketer and analytics colleagues. You’re welcome.

5 thoughts on “Quick Tip: Save Variables

  1. Chris Brown

    Now there’s a power-tip if ever there was one, Jan!

    You mention that the combined variables don’t have to be related, which is true, but if it’s possible to combine a series of values on the basis of a common theme, feature or function, which you allude to in the paragraph following, it helps make sure that the report navigation (and the report ‘breakdown’ menu) in the Analytics interface makes sense to the friendly marketer.

    In your example, the variable name is set to a concatenation of the two sub-variables. This illustrates your point really well but it could become a bit unwieldy in practice. Start combining a few different values and that variable name will become quite long and will start wrapping itself over numerous lines in the navigation menus. Menu items for classified values get suffixed with the word, ‘ Reports’, so it actually gets even longer! Using the theme as a variable name neatly categorises all of the attributes of that theme beneath a “My Theme Reports” sub-menu. The ability to re-define the navigation menu structure via the Admin Console doesn’t apply to classification attributes so it’s all the more important to consider this upfront.

    One other small point to add: as well as considering the number of combinations, it’s also worth considering whether concatenating the values (and using delimiter characters) could exceed the 100 (prop) and 255 (eVar) character limits. If that’s likely to happen – and you really are in a tight squeeze – it might be possible to use the Classification Rules to substitute an abbreviation with a corresponding lookup value.

    Like

    1. Really good points, Chris, thanks!

      To answer your first two paragraphs, let me take the extremists point of view: I would _never_ expect anyone to look at the standard menu. Instead, I would create custom reports and build a completely new menu structure for my users. Because of that, I can put the classified reports wherever users expect them and give them any names I like (and they understand).

      Essentially, the actual “variable” carrying the data becomes almost irrelevant, both in terms of naming it and the way the data is being carried (combined or not, who cares).

      Your second point (third paragraph) is indeed a limitation I forgot to point out. And I love the workaround!

      Like

  2. Pingback: SAINT API and API Explorer | Web Analytics for Developers

  3. Pingback: Tagging Forms (w/o Losing Money) | 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