Here’s a fun feature: dynamic variables.
Remember how in the article on variables we talked about how data is transported into Adobe Analytics?
You basically write data into props or eVars, and sometimes into both.
As an example, let’s put this onto a page:
s.pageName="Blog:130423:Dynamic_Variables"
s.prop1="blog"; // site section
s.prop2="blog:principles"; // site sub section
s.eVar1="blog"; // site section
The resulting tracking call will contain the following in the URL:
...&pageName=Blog:130423:Dynamic_Variables&c1=blog&c2=blog:principles&v1=blog&...
There is definitely some duplication there. I’m not even a real programmer anymore and I still don’t like duplication. There is also a practical reason to get rid of the duplication: Internet Explorer.
Versions of IE prior to 9 will only request content if the URL is shorter than 2048 characters. So if we put too much data into the tracking call, IE might actually not track anything at all!
Now since version H.22.1, the Javascript library will take care of that by truncating the URL on IE if necessary, but if you still use older code or if you simply value your data, you should make sure you stay below 2048 characters for tracking calls.
So let’s fix the duplication!
Dynamic Variables
Dynamic variables are basically placeholders that are evaluated by the collection servers. They can point to other parameters on the tracking call, to HTTP headers, or to cookies.
Let’s rewrite the example above:
s.pageName="Blog:130423:Dynamic_Variables"
s.prop1="blog"; // site section
s.prop2='D=c1+":principles"'; // site sub section
s.eVar1="D=c1"; // site section
See what we did there?
By using the special notation D=, we told the collection servers to use the value in c1 for v1, effectively copying prop1 to eVar1.
We also told the system to use the value of c1 for the first part of c2.
The tracking call URL will now look like this:
...&pageName=Blog:130423:Dynamic_Variables&c1=blog&c2=D=c18+":principles"&v1=D=c1&...
Right, yes, this is longer. But if you go back to the article on debugging and check the long URL that was sent on our test page, you can see that using dynamic variables did actually make sense.
Using dynamic variables, you can also tell the system to read HTTP headers and cookies, like so:
s.prop15=D=User-Agent; // read the HTTP User-Agent header s.prop21=D=s_vi; // read the value of the s_vi cookie
Be warned about the latter: the cookie has to be accessible to the collection servers, of course, meaning it needs to be set on whatever your tracking server is set to.
If you are using 1st-party cookies, the collection servers can read cookies set on your domain, but if you use 3rd-party cookies, it can only read cookies set against whatever domain it is you’re using for tracking.
Web Analytics for Developers 
Hi Jan, all clear on this. How about the hit or visit date being passed dynamically. I tried this in my library…
* TIME STAMP */
s.eVar48 = “D=t”;
but seeing as the way Adobe sitecat handles dates (Jan=0) all of my passed dates are a month behind!. I’m assuming I could use a processing rule to amend but I’d rater have the correct code out there.
Any thoughts?
Thanks
Matt
theguardian.com
LikeLike
I’m having a problem Jan and trying to wrap my head around this concept. I’m struggling and getting a little pushback on dynamic variables bc I’m probably not explaining it correctly but noticed other sites were using it so searched for it and found your article coincidentally!
Because in an implementation I’ve worked on in the past (to correct it) we had around nearly 5 million unique values for url variable in a prop (it was pulling current url AND the FULL url) and a few million for page name a month I believe bc it was pulling pagename +page number but it also had category:sub category: pagename: and page number…. You probably already know why there was so many uniques already after saying that much… However I brought to the table that we use dynamic variables- to pull the url parameters for many MANY other variables pulling the same data that was ALREADY in the url parameter… When explaining dynamic variables to my team I’m not sure if I got explained it or if they understood the concept correctly bc they were afraid of using a dynamic variable and it “stripping” the url parameters off. They thought when using dynamic variables to copy the prop with current url- that it would end up stripping it off and rolling up all the data into that one basic url with no url parameters on it anymore.
I attested at that it doesn’t do that and that it simply can copy over those url parameters (bc a dynamic variable occurs before the processing rules I believe) – and that we could shorten the image request and also just pull those over to the other variables we are pulling the same data into using dynamic variables… Additionally it was my understanding that it can help in many ways and that it can/will strip off the http/https to quit de-duplication of the pages based on the protocols and treat them one-in-the-same…
This made a lot of sense to me and seemed non-sensical to NOT use dynamic variables to shorten image request, copy over url parameters to other variables currently already pulling in the same data using dynamic variables. However they still think that its going to strip the url paremeters off of the prop/current url and that it won’t be useful and end up rolling all the data up into the url. i.e. https://www.examplesite.com/socks-category/outdoor-socks?source=google-paid would be rolled up into http://www.examplesite.com/socks-category/outdoor-socks. (but wont a dynamic variable take the ?source=google-paid and copy it over to whatever other variable we want and actually make the data more “digestable?”)
LikeLike
Hi KD,
I don’t think the mechanics behind Dynamic Variables has anything to do with cutting off or not cutting off anything.
There’s a setting for the s.pageName variable, though, could that be the issue?
LikeLike
Hey Jan,
I noticed in our implementation of multiple report suites and a global report suite- that some of our report suites are capturing a value passed by campaign for two evars- directly from the datalayer. It is assigning first touch to one evar, last touch to another evar. Here’s where things get interesting though…
On one report suite/site- we are capturing first touch evar similar to the other sites, but the last touch evar is using a dynamic variable for last touch (grabbing it from first touch value). We have processing rules w/ rule builder for first touch- and I noticed that first touch and last touch look nearly identical in the reporting, and the thought occured to me- this can’t be right. Because both first and last touch have similar data, same classifications (mind you- we don’t have rule builder classifications for last touch) and I can’t for the life of me figure out anything else that might be causing it, other than maybe the post-processed value for first touch is being retained after being classified and being passed over to the last touch evar. Not sure if this makes sense- but curious if you know much about first/last allocation configured evars and use of a dynamic variable when I’d imagine the visitor/experience cloud ID is retaining the first touch value and passing it over to last touch incorrectly.
My solution was to remove the dynamic variable for last touch and basically map it directly to the data layer value just like the other sites but also in hopes to fix and assign the correct value/campaigns for last touch. It’s the first thing that came to mind when I saw that it’s the only uniquely different thing from our other report suites and there’s no classifications, different values/data for the two evars in the other report suites.
LikeLike
Hi Daniel,
That should not happen with Dynamic Variables. As far as I know, they are resolved on the collection servers, and further down the line should not look any different.
Have you seen any change after you removed them?
Cheers,
Jan
LikeLike