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


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


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.

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


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