Trimming the fat with dynamic variables

Raise your hand if you’re cap­tur­ing some of the same data in your Cus­tom Traf­fic vari­ables that you are cap­tur­ing in your Cus­tom Con­ver­sion vari­ables. I can’t say for sure, but I’m will­ing to bet that there’s greater than a 50% chance that you, Mr.-or-Ms. Blog Post Reader, raised your hand.

Now raise your hand if you’re cap­tur­ing the same data in mul­ti­ple eVars to get mul­ti­ple views of vis­i­tor acqui­si­tion through dif­fer­ent allo­ca­tion and cookie expi­ra­tion settings.

Now raise your hand if you’re cap­tur­ing the page URL in a Site­Cat­a­lyst vari­able on every page view.

Finally, raise your hand if there is infor­ma­tion in HTTP head­ers (such as the user-agent string, or the cook­ied vis­i­tor ID value) that you are cap­tur­ing or would like to cap­ture in Site­Cat­a­lyst variables.

If you raised your hand in response to any of these ques­tions (and your cowork­ers are now star­ing at you, won­der­ing why you just raised your hand while star­ing at your screen), let me intro­duce you to dynamic vari­ables, an imple­men­ta­tion tech­nique intro­duced sev­eral months ago that isn’t being used as widely as it prob­a­bly should. The idea is that when you’re col­lect­ing a cer­tain data point—say, inter­nal search terms—in a vari­able, Site­Cat­a­lyst should be able to copy that value to other vari­ables quickly, eas­ily, and dur­ing data pro­cess­ing rather than dur­ing data col­lec­tion. You shouldn’t (and, in fact, don’t) need to pass the same value into mul­ti­ple vari­ables directly on your site!

Why is this impor­tant? Well, a few rea­sons, really.

1. It can help keep your image request short. A base­line Omni­ture image request, with no cus­tom vari­ables what­so­ever, is around 450 char­ac­ters. When you start adding vari­ables, this num­ber increases quickly. This can become a prob­lem on cer­tain mobile devices and, for really long requests, in all ver­sions of IE.
2. Dynamic vari­ables give you easy access to data points that are oth­er­wise dif­fi­cult or impos­si­ble to capture.

Here’s how it works: In your imple­men­ta­tion, you set a vari­able equal to “D=[the data para­me­ter that you want to cap­ture]” and Omniture’s servers take care of the rest. So, let’s say you’re cap­tur­ing inter­nal search key­words in eVar1 and also want to pass them into prop1:

s.prop1="D=v1"

Here are a few other basic examples:

s.eVar7="D=pageName" // captures the pageName value (pageName=) in eVar7
s.prop15='D=v50+":"+c6'; // concatenates eVar50:prop6 into prop15
s.prop5=s.eVar5="D=g" // passes the page URL into both prop5 and eVar5
s.eVar20="D=v0" // captures the campaign in eVar20

The last exam­ple addresses those of you who are dupli­cat­ing cam­paign track­ing codes into mul­ti­ple vari­ables to ana­lyze acqui­si­tion based on dif­fer­ent allo­ca­tion (most recent value, orig­i­nal value, or lin­ear) or cookie expi­ra­tion set­tings. Use dynamic vari­ables to copy val­ues with­out hav­ing them writ­ten out in each case.

If you’re using the JavaScript Debug­ger or a packet mon­i­tor to view your request, you will see the dynamic vari­able in there. For example:

This is exactly what we want; we’re dynam­i­cally copy­ing the page name over to prop1. “D=pageName” is shorter than the actual s.pageName value of “my site’s home page;” we saved nine char­ac­ters in our image request. And since Site­Cat­a­lyst knows what the s.pageName value is, it can dupli­cate that value dynam­i­cally to prop1 as it’s pro­cess­ing the request.

NOTE: The vari­able abbre­vi­a­tion used must match the vari­able para­me­ter name passed in the image request. Some vari­ables have mul­ti­ple accepted para­me­ters used in dif­fer­ent cases (e.g., “page­Name=” and “gn=” both pass the page name, but the lat­ter is most often used in mobile and hard-coded imple­men­ta­tions), but the dynamic vari­able usage must match the para­me­ter in the given request. For exam­ple, if the image request uses “page­Name=” to pass the page name, then “D=pageName” is accept­able, but “D=gn” is not. If the image request uses “gn=”, then “D=gn” is accept­able, but “D=pageName” is not.

As Kevin Rogers men­tioned on his blog (see link above), really robust imple­men­ta­tions can have trou­ble in IE. In my expe­ri­ence, this is often because of dupli­ca­tion of vari­ables. Com­pare these two options taken from the image request:

. . .c1=some%20value%20here&v1=some%20value%20here. . . (46 char­ac­ters)
. . .c1=some%20value%20here&v1=D&3Dc1. . . (33 characters)

I’ve even seen some imple­men­ta­tions that are pass­ing the page URL into both a prop and an eVar (and, of course, the page URL is cap­tured auto­mat­i­cally in the g= para­me­ter), where cap­tur­ing the URL in three dif­fer­ent places accounts for a whop­ping 700+ char­ac­ters! I’m not say­ing that you shouldn’t pass the URL into a prop and an eVar, but you could cut hun­dreds of char­ac­ters out of your image request using dynamic vari­ables to copy the g= para­me­ter into vari­ables for you.

Since this func­tion­al­ity was orig­i­nally devel­oped for mobile measurement—mobile devices often have URL length requirements—the full list of dynamic vari­ables is con­tained in the Mobile Device Report­ing imple­men­ta­tion guide, avail­able within Site­Cat­a­lyst. If you’re look­ing at the doc­u­ment, you’ll find the table of pos­si­ble val­ues in appen­dix A.5, on page 20 of the PDF (page 15 of the manual).

The other great thing that you can do with dynamic vari­ables is cap­ture HTTP head­ers, includ­ing the val­ues of cook­ies passed along with them. For example:

s.prop1="D=User-Agent" // captures the user-agent string in prop1
s.prop25="D=s_vi" // captures the s_vi (visitor ID) cookie value in prop25

Note that using dynamic vari­ables in this man­ner will not cause any pars­ing of header or cookie val­ues. What­ever is present in these fields is what you get in your report­ing. Any other header can also be cap­tured using the header name (e.g. Ref­erer, Accept-Language, etc.). This can be really help­ful for advanced pro­fil­ing and segmentation.

NOTE: Cap­tur­ing the vis­i­tor ID may have lim­ited use­ful­ness in many cases. If you receive more than 500,000 monthly unique vis­i­tors, you will exceed the max­i­mum num­ber of unique val­ues allowed for what­ever vari­able you choose to receive this data. Also beware of going gran­u­lar just because you can; if cap­tur­ing this data doesn’t help you opti­mize your busi­ness, it’s prob­a­bly best not to do it.

Being able to cap­ture cook­ied val­ues so eas­ily also helps when you have a CNAME (first-party cookie) Site­Cat­a­lyst imple­men­ta­tion and have your own site cook­ies that you’d like to read into vari­ables. For exam­ple, let’s say you cap­ture a cam­paign ID and store it in a cookie named “mktg_camp” using JavaScript. You can then read that cookie and set the value of the cookie into eVar1 by putting the fol­low­ing on each page:

s.eVar1="D=mktg_camp"

This would cause the cam­paign ID, found in the “mktg_camp” cookie to passed into Site­Cat­a­lyst on each page view in much the same way that the s.getPreviousValue plug-in does.

So there you have it: dynamic vari­ables in a nut­shell. I hope this func­tion­al­ity opens up some great new pos­si­bil­i­ties and/or allows you to cap­ture more insights in fewer char­ac­ters. As always, please leave a com­ment with any ques­tions, thoughts, or sug­ges­tions that you may have! I’m also avail­able Twit­ter or LinkedIn, or by e-mailing omni­ture care [at] adobe dot com.