Raise your hand if you’re capturing some of the same data in your Custom Traffic variables that you are capturing in your Custom Conversion variables. I can’t say for sure, but I’m willing 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 capturing the same data in multiple eVars to get multiple views of visitor acquisition through different allocation and cookie expiration settings.

Now raise your hand if you’re capturing the page URL in a SiteCatalyst variable on every page view.

Finally, raise your hand if there is information in HTTP headers (such as the user-agent string, or the cookied visitor ID value) that you are capturing or would like to capture in SiteCatalyst variables.

If you raised your hand in response to any of these questions (and your coworkers are now staring at you, wondering why you just raised your hand while staring at your screen), let me introduce you to dynamic variables, an implementation technique introduced several months ago that isn’t being used as widely as it probably should. The idea is that when you’re collecting a certain data point—say, internal search terms—in a variable, SiteCatalyst should be able to copy that value to other variables quickly, easily, and during data processing rather than during data collection. You shouldn’t (and, in fact, don’t) need to pass the same value into multiple variables directly on your site!

Why is this important? Well, a few reasons, really.

  1. It can help keep your image request short. A baseline Omniture image request, with no custom variables whatsoever, is around 450 characters. When you start adding variables, this number increases quickly. This can become a problem on certain mobile devices and, for really long requests, in all versions of IE.
  2. Dynamic variables give you easy access to data points that are otherwise difficult or impossible to capture.

Here’s how it works: In your implementation, you set a variable equal to “D=[the data parameter that you want to capture]” and Omniture’s servers take care of the rest. So, let’s say you’re capturing internal search keywords 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 example addresses those of you who are duplicating campaign tracking codes into multiple variables to analyze acquisition based on different allocation (most recent value, original value, or linear) or cookie expiration settings. Use dynamic variables to copy values without having them written out in each case.

If you’re using the JavaScript Debugger or a packet monitor to view your request, you will see the dynamic variable in there. For example:

Debugger

This is exactly what we want; we’re dynamically copying 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 characters in our image request. And since SiteCatalyst knows what the s.pageName value is, it can duplicate that value dynamically to prop1 as it’s processing the request.

NOTE: The variable abbreviation used must match the variable parameter name passed in the image request. Some variables have multiple accepted parameters used in different cases (e.g., “pageName=” and “gn=” both pass the page name, but the latter is most often used in mobile and hard-coded implementations), but the dynamic variable usage must match the parameter in the given request. For example, if the image request uses “pageName=” to pass the page name, then “D=pageName” is acceptable, but “D=gn” is not. If the image request uses “gn=”, then “D=gn” is acceptable, but “D=pageName” is not.

As Kevin Rogers mentioned on his blog (see link above), really robust implementations can have trouble in IE. In my experience, this is often because of duplication of variables. Compare these two options taken from the image request:

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

I’ve even seen some implementations that are passing the page URL into both a prop and an eVar (and, of course, the page URL is captured automatically in the g= parameter), where capturing the URL in three different places accounts for a whopping 700+ characters! I’m not saying that you shouldn’t pass the URL into a prop and an eVar, but you could cut hundreds of characters out of your image request using dynamic variables to copy the g= parameter into variables for you.

Since this functionality was originally developed for mobile measurement—mobile devices often have URL length requirements—the full list of dynamic variables is contained in the Mobile Device Reporting implementation guide, available within SiteCatalyst. If you’re looking at the document, you’ll find the table of possible values in appendix A.5, on page 20 of the PDF (page 15 of the manual).

The other great thing that you can do with dynamic variables is capture HTTP headers, including the values of cookies 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 variables in this manner will not cause any parsing of header or cookie values. Whatever is present in these fields is what you get in your reporting. Any other header can also be captured using the header name (e.g. Referer, Accept-Language, etc.). This can be really helpful for advanced profiling and segmentation.

Visitor ID report

NOTE: Capturing the visitor ID may have limited usefulness in many cases. If you receive more than 500,000 monthly unique visitors, you will exceed the maximum number of unique values allowed for whatever variable you choose to receive this data. Also beware of going granular just because you can; if capturing this data doesn’t help you optimize your business, it’s probably best not to do it.

Being able to capture cookied values so easily also helps when you have a CNAME (first-party cookie) SiteCatalyst implementation and have your own site cookies that you’d like to read into variables. For example, let’s say you capture a campaign 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 following on each page:

s.eVar1="D=mktg_camp"

This would cause the campaign ID, found in the “mktg_camp” cookie to passed into SiteCatalyst on each page view in much the same way that the s.getPreviousValue plug-in does.

So there you have it: dynamic variables in a nutshell. I hope this functionality opens up some great new possibilities and/or allows you to capture more insights in fewer characters. As always, please leave a comment with any questions, thoughts, or suggestions that you may have! I’m also available Twitter or LinkedIn, or by e-mailing omniture 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.