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:

Debugger

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.

Visitor ID report

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.

12 comments
Andreas Dierl
Andreas Dierl

Hi Ben, great post as usual. All, I was going to add this comment since there were questions from time to time about multiple items, having a fixed string before the variable, product string, etc. All of the above is working. You just need to have the right syntax. The prefix always has to be at the beginning and is D= out of the box. (can be changed with e.g. s.dynamicVariablePrefix="$$";). So the content of your variable is always D=a+b+c where a,b,c... can be a variable (it's short name) or a fixed string like "xyz" (enclosed in "" (double-quotes)) So you might want to use single quotes for your Javascript variable to write easier code: s.prop1 = 'D=...'; fixed text at the beginning: s.prop1 = 'somevalue'; s.prop2 = 'D="Text:"+c1'; fixed text at the end s.prop1 = 'somevalue'; s.prop2 = 'D=c1+"Text"'; multiple vars, multiple text: s.prop1 = 'somevalue'; s.prop2 = 'someothervalue'; s.prop3='D="Text:"+c1+"//"+c2'; product syntax: s.eVar2='somevalue'; s.products='D=";myProduct;;;;evar15="+v2'; What you should NOT do: s.prop1 = 'test'; s.prop2 = 'D=c1'; s.prop3 = 'D=c2'; don't reference a variable that contains a dynamic value. If you don't like single quotes, you'd need to escape the double-quotes in the string itself: s.prop2="D=\"Text:\"+c1"; Hope that helps, Andreas

Eric Matisoff
Eric Matisoff

Since v15 doesn't have s.pageType, I'm trying to use Dynamic Variables to populate s.pageName with "404 ERROR: " then the URL. I've tried: s.pageName='"404 ERROR: "+D=g'; s.pageName="'404 ERROR: '+D=g"; s.pageName="404 ERROR: "'+D=g'; Might just end up with: s.pageName="404 ERROR: "+document.location.href; Any thoughts? Thanks!

Andy Batten
Andy Batten

Can a dynamic variable be nested? So, would this work? s.pageName='D=c1+" / Hello World"'; s.prop1="Test Section"; s.prop2="D=pageName"; I'd want s.prop2 and s.pageName to be "Test Section / Hello World".

Emily Hill
Emily Hill

Thanks Ben. Our developers are going to love me now! (P.S. Minor added bonus - makes my QA process much more mentally stimulating vs. reading the same variable value fives times per image request!)

Fraser Kemp
Fraser Kemp

Ben great post as ever - Great tips which I was not aware of, and quite fitting to a problem I need to resolve for a client. The company I am consulting for has large traffic sites which in some cases are trying to pass 9314 (gulp) characters into the product variable (dynamic variables cannot help here unfortunately, only Data Insertion API) - On their main product results page they have 2300 characters being passed into the product variable and as a intermediate solution before I get everything reworked to server side processing this just might be enough to pull their character strings here below 2048. Great Stuff! Fraser

Rudi Shumpert
Rudi Shumpert

Great tips here Ben! Thanks for posting ! -Rudi

James Dutton
James Dutton

Hey Ben, This is very interesting, I had no idea this was possible. Then again, as we discussed in our Beyond Web Analytics podcast there are many many things SC can do that aren't obvious. Will you be publishing this into a knowledge base white paper - would be useful to capture clear guidelines on the scope of all variables and how they are named in the gif request. What's also interesting here, is that some of this functionality could be replicated through a VISTA rule - eg the typical s.prop1 = s.eVar1 = "meta data"; - but with the new approach you describe here I'm wondering if the product team would consider enabling some kind of VISTA Light service (ie free) that allowed basic variable manipulation to occur through the admin console? In any case, this is certainly very helpful - as always! Cheers, James.

Ben Gaines
Ben Gaines

Ha! I hadn't considered the positive externalities associated with dynamic variables. :) Thanks Emily!

Ben Gaines
Ben Gaines

Wow. . . 9,314 might be a record :) Hopefully this does help out!

Ben Gaines
Ben Gaines

I have published this information in the Knowledge Base, in article ID 10099. You can also find a list of variable abbreviations to use with dynamic variables in that article. Your question regarding VISTA is interesting and well-reasoned. I'm sharing your suggestion with our Product Management team; it's great feedback and they'll welcome it.