Articles in The '__utmv' Tag

What is the “User Defined” report, and how do I use it?

by MoreVisibility

Have you ever been in the Visitors section of your favorite Google Analytics profile and wondered what the heck “User-Defined” was? Did you ever want to know how you could make use of it? Do you have any idea what I’m talking about today? If you answered “Yes” to any of the three questions I just asked, continue reading.

Along with powerful features like Advanced Segmentation and Custom Reporting, Google Analytics allows the option for website owners to add an additional label to visitors who reach a certain point or complete a certain action on a website, such as visiting a key website page or purchasing something from a merchant’s online store. These labels are usually known as Custom Segments (or Custom Segmentation), and it’s a very powerful tool in obtaining deeper insights into website visitors who perform specific tasks and accomplish specific actions.

Making use of the User-Defined report in Google Analytics requires a bit of extra coding help from your IT department or webmaster, but it’s totally worth the short amount of time it takes to implement. For example, let’s say that I wanted to add a label of “customers” to any visitor who reaches my shopping cart’s “Thank You” confirmation / receipt page. What I would do is add an additional line of code to my Google Analytics Tracking Code (GATC), which would look exactly like this:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-XXXXXXX-1");
pageTracker._trackPageview();
pageTracker._setVar("customers");
} catch(err) {}</script>

Notice the line in bold that includes _setVar – when this is present on a page within the Google Analytics Tracking Code, an additional cookie – the __utmv cookie – gets set on a visitor’s computer, with its sole purpose being to identify the visitor by the label (or value) that you used in the code. If you notice up above, you will see “customers“, which was the label that I wanted to use.

Now, on their next visit to the site, they will be identified as a part of the “customers” segment in the User-Defined report, allowing you to perform analysis on all visitors who have purchased something from your online store. Neat, huh?

You can also use the pageTracker._setVar function when someone clicks on an important link on your site, or makes a key selection on an important form that you want visitors to fill out. For example, if you wanted to add a custom label to any visitor who clicks on your “Live Help” applet, you can ask your IT department or webmaster to add an “onClick” event, and give them the following line of code:

onClick="pageTracker._setVar('Needs Help');"

When all of your coding is complete, check the User-Defined report after about a day or so and you should see something like this:

Some things to note about Custom Segmentation / the User-Defined Report:

1. As we talked about, when a person visits a page calling the _setVar function, the __utmv cookie is set on their computer. This is a persistent, first-party cookie that has a lifetime of two years. This means that every time a user with a __utmv cookie returns to your site, the label assigned to the user will continue to identify them as such until they either delete the cookie or visit another page with another call to _setVar with a different label.

2. The purpose behind something like a User-Defined report – and Custom Segmentation in general – is that it is not designed to be updated very often. This label, for the most part, should be a permanent one for a visitor. You should only use _setVar on pages like a receipt page of a shopping cart, or an account registration “success” page for a visitor who becomes a member of your site. You shouldn’t use _setVar on your homepage, or use several different _setVar’s with different labels scattered across many pages of your website.

3. Google Analytics – at this time – only has the capacity to store one custom segment at any one time for one website. So if you are using multiple calls to _setVar on your site, Google Analytics can only store the latest value that a visitor runs into in the __utmv cookie.

4. However, Google Analytics uses what they call the “first association” of the session for visitor session calculations. So if you are using multiple calls to _setVar on your site, be aware that if a user runs into the first one, and then runs into the second one in the same visit, their Goal Conversion and Pages per Visit metrics would be attributed to the label of the first encounter with _setVar.

5. For page view calculations, Google Analytics uses the most recently defined value. So if a person runs into the second instance of _setVar on your site, all of their pageviews afterwards – including the current pageview – will be attributed to the second _setVar’s label, even though as we just learned in #4 above, visitor session information is attributed to the first encounter of _setVar.

A full, technical explanation of _setVar can be found here.

What are we going to do at 3:14:07 UTC, January 19, 2038?

by MoreVisibility

Start the countdown right now! In a little under 29 years from now in the year 2038, Web Analytics engineers at Google, Yahoo, Omniture, Coremetrics, and WebTrends will have some very tough choices to make – and it’s never too early to start thinking about them!

This isn’t a trivial issue like Y2K or something like the digital TV transition day on June 12th of this year – no, no, no! This has the potential to seriously compromise cookie integrity, and potentially “break” visitor tracking, industry-wide!

What is happening in 2038?

On Tuesday, January 19th at exactly 3:14:07 UTC, all computer software programs (including Web Analytics Cookies) that store system time as a signed 32-bit integer (like a Unix timestamp) will start to “wrap around”, storing time as a negative number, causing every system using signed 32-bit integers to interpret time as 1901, and not 2038.

Whoa, Whoa! Back Up – I have no clue what you’re talking about.

Okay, let me try to break this down for you. Almost every 20th century computer uses a signed 32-bit integer which keeps track of system time on your computer, on servers, ATM machines, iPods and iPhones, and so on. This “signed 32-bit integer” business is also known by another name – Unix Time (or also “POSIX” time). This time is represented by the number of seconds since January 1, 1970.

If you take a look at your browser’s cookies, you’ll see endless strings of numbers and dots, like this:

The cookie selected here in this image is the __utma cookie from Google Analytics, and the 10-digit number that I have highlighted represents the first time I visited the Google.com website. This number – 1239628694 – is a Unix Timestamp, and when you do the math (or use a conversion tool somewhere online), this number translates to Mon, 13 Apr 2009 13:18:14 GMT (of course, I most likely cleared my cookies – yes World, I clear cookies from my computer, too!)

So what’s the problem again?

Okay – the problem with this comes due to the way modern computer programs calculate this 10-digit number. That’s what you need to know (Warning: This next party is very geeky). They almost all use a very standard 4-byte integer to count up the seconds, which is 31 bits long, able to contain a maximum value of 2 to the power of 31. The 32nd bit is the sign, which of course is positive (+). When you do the math, the maximum number that computer software programs can reach and stay positive is 2147483646. When you add one more second to it – 2147483647 – the positive sign will become a negative sign, and instead of Tuesday, 3:14:07 on January 19, 2038, computers everywhere will display the time as Friday, 8:45:52 on December 13, 1901.

Can’t this be fixed? Can’t we just ignore the date and move on?

Unfortunately, it’s not that simple. Most every operating system stores system time as a 32-bit integer, and system time is a very big component of a functioning software program (they absolutely need to be able to come up with a positive time stamp). So, it’s not an easy fix – most likely, entire software programs will need to be re-written and re-programmed to avoid Y2038K.

This includes personal computer operating systems, ATM machine software, other electronic devices with computer-like components, and, yes, Web Analytics cookies.

Okay – Y2038K? Give me a break – this is TWENTY-NINE and a HALF years away! I think you’re jumping the gun here.

You’ll be surprised how fast 29 and a half years goes by in computer programming. Think of this – we’re in the year 2009, and we’re using a timestamp that starts counting seconds from 1970 (39 Years Ago), which was first published in 1988 (21 Years Ago). Most of us are still using Office 2003 (6 Years Ago).

29 Years is right around the corner – so I hope that we can come up with some kind of conversion tool, some type of new timestamp calculation, some new 64-bit integer system that can seamlessly transition all software programs and Web Analytics Cookie Timestamps for the next generation!

*Note: Some of this blog post is obviously “tongue and cheek”. I am not really sounding the general alarm about what will happen in 2038 – but hey, it’s never too early to start planning for the future! :)”