Dynamic Variables

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.

9 thoughts on “Dynamic Variables

  1. Pingback: Tracking w/o Javascript | Web Analytics for Developers

  2. Pingback: Redirect Tracking | Web Analytics for Developers

  3. Pingback: Ode to Charles & Map Local | Web Analytics for Developers

  4. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  5. Pingback: Data Elements vs Data Layer | Web Analytics for Developers

  6. 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

    Like

  7. 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?”)

    Like

    1. 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?

      Like

  8. Pingback: Useful Data Elements – Web Analytics for Developers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s