Trimming the fat with dynamic variables
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.
- 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.
- 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:
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.
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.
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.
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.