Dynamic Variables – still a thing?

In April 2013, I wrote about “Dynamic Variables“, a mechanism that helps remove duplication in the tracking URLs, making the tracking requests potentially shorter.

Even at the time, the original reason for doing so was no longer a show stopper: Internet Explorer up to version 9 had the annoying habit of not requesting any URLs longer than 2048 characters or so. But Analytics s_code version H.22.1 had introduced a truncation feature that would make sure the URL never grew beyond that limit.

The downside, of course, was that you’d lose some of your tracking data, so Dynamic Variables still made sense.

Then, in September 2014, came AppMeasurement 1.4.1 and brought HTTP POST support, meaning the Javascript would no longer truncate the call, but just work around IEs limitation by sending it as a POST rather than a GET.

Since then, there has been no need to keep the URL short, really.

Other Reasons

If you know Analytics, or you remember my post from 2013, you know that Dynamic Variables have two more use cases:

  • They can be used to read HTTP headers, e.g. the User-Agent field.
  • They can read cookies, as long as the server can see them.

Those two use cases are still valid.

And to repeat what I wrote last time: using Dynamic Variables, you can read cookies that the tracking server can see.

If you’re tracking on your own domain (e.g. “metrics.jan-exner.de”), the tracking server can read all cookies set on “jan-exner.de”. Since you can just as easily read those in Javascript in the page, why bother?

If you’re on 3rd-party cookies, though (e.g. “ags055.sc.omtrdc.net” or “janexner.112.2o7.net”), then Dynamic Variables can read cookies set by the tracking server, including the “s_vi” cookie that holds the Analytics visitor ID.

Could be useful.

Audience Manager

If you are using Audience Manager on your site, you have two options for integration with Analytics:

  • You can either integrate client-side, using what we call “DIL code”, or
  • you can use “server-side forwarding”, where Analytics passes all data over to Audience Manager somewhere in the backend.

Both cases have their advocates, the second is the way forward, and if you deploy these days, you really should go for SSF.

Dynamic Variables are one (admittedly tiny) reason for doing so.

The Analytics backend sends data to Audience Manager at a point where Dynamic Variables have already been resolved, meaning that Audience Manager will see what you meant it to see.

With DIL code, you’d have to write some Javascript that translates back from Dynamic Variables, plus you wouldn’t be able to use Dynamic Variables to send HTTP headers or values from cookies to Audience Manager.

Unlikely to be a big deal, but this post wouldn’t be complete without mentioning that.

2 thoughts on “Dynamic Variables – still a thing?

  1. Love your posts Jan, especially how you don’t forget the finer points and little details. They may be small things but it helps people make better implementation decisions from a complete understanding. Thank you!


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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.