New Multiple Custom Variables in Google Analytics
Amid all the other information you can gather about a visitor and his visit, the ability to add dimensions unique to your site makes the reports more actionable.
Having a single user-defined variable in Google Analytics has long been a sore point for users. Google recently announced the rollout of multiple custom variables to every account. This addition can dramatically change the kind of analysis users can do with Google Analytics.
Multiple custom variables can be scoped to a visitor (as has always been the case) or just to a visit or even a page. They are very flexible and can be adapted to almost any scenario.
How to Create Custom Variables
There is new JavaScript to create multiple custom variables. The _setVar() method has been deprecated in favor of _setCustomVar(). This new method accepts four arguments: slot, name, value and scope. Because the variables are sent in the __utm.gif request, they must be set before _trackPageview() or before an event is fired on a page.
This code would create this visit-level variable in slot 1: "visit type=prospect".
Creating multiple variables on a page would just be a matter of calling this JavaScript once for each variable and passing the appropriate parameters.
Visitor-level variables
These are stored in a cookie. Once created, they last for as long as the visitor's cookies last, or until they are overwritten. If multiple visitor-level variables are set to the same slot during a visit, the last one set will be reported. They do not apply retroactively to previous visits.
Visit-level variables
These apply to the current visit. If a visit-level variable is assigned to a slot being used by another variable (regardless of its scope), it will be overwritten. If multiple visit-level variables are assigned in the same visit to the same slot, the last one set will be reported.
Page-level variables
These apply to the current page. Five page-level variables may be set simultaneously on a page. If any other type of variable is assigned during a visit to the same slot as a page-level variable, the page-level won't be reported.
Limits to Multiple Custom Variables
Because there are only five variable slots available, there is a limit to the number of custom variables that can be set in a visit. Once a slot has been used during a visit, care must be taken not to overwrite that variable later during the visit.
As a rule of thumb, each slot in a visit is reported independently. If multiple variables are assigned to the same slot during a visit, the last visit-level variable will be reported.
Examples
- If no visit- or visitor-level variables are used on a site, every page can have five variables with different name-value pairs.
- A visit-level variable is assigned to slot 1. Later during the visit, a visitor-level variable is assigned to slot 1. The visit-level variable will be reported. Any subsequent visits will be attributed to the visitor-level variable because it's still stored in the cookie.
- During the same visit, a page-level variable and a visit-level variable are assigned to slot 1, in any order. The visit-level variable will be reported. The page-level variable will not, regardless of whether it was reported last.
Best Practices
Because of these limitations with scope and quantity, the best practice is to decide ahead of time what types of segments you need to track on your site. From there, break them down by scope. Then assign each slot a scope, and never use it for anything but that type of variable.
For example, a company might decide to reserve slot 1 for visitor-level variables, slot 2 for visit-level variables and slot 3 for page-level variables. They may use slot three to set a variable for every single page, but they would know that slots 1 and 2 could only be used sparingly. If the company decided they needed multiple variables of the same scope, they would assign slots 4 and 5 accordingly.
To use these variables to their fullest, it is best practice to give each variable a broad name that could hold any number of values, instead of a binary value. For example, instead of creating a variable for "registered user" with a value of "yes" or "no", create a variable named "user type" with values like "registered", "prospect", etc.
How Multiple Custom Variables Are Reported
Multiple custom variables can be found in a new report under visitors, labeled "Custom Variables". (Data from using the _setVar() method will still appear under the "User Defined" report.) Each slot is reported independently. So, if the same variable name is used for multiple slots in a visit, they will report separately.
Each variable shows how many visits included it at some point. Clicking on the variable name in the reports will bring up a table of values. These are values that were assigned to that variable name during visits.













Comments
Cross Domain Custom Variables
Thanks so much for this great article. You mention that "Page- and visit-level variables don't need to be passed to the new domain".
My current code on www.mydomain.com is
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA- zzzz-X");
pageTracker._setDomainName("none");
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._setCustomVar(1, "UserType", "VALUE1", 3);// registered or non-registered user
pageTracker._setCustomVar(2, "RegID", "VALUE2", 3);// populated RegID only if person logs in
pageTracker._trackPageview();
} catch (err) { }
</script>
My custom variables are page level. (Should I use scope = 1 instead?)
Should my cross domain (sub.otherdomain.com) code be:
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-zzzz-X");
pageTracker._setDomainName("none");
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();
} catch (err) { }
</script>
Can I drop the custom variable code altogheter in the otherdomain pages?
I am only trying to see how many reistered vs non registered users are coming to the site.
Page and visit-level custom variables
It depends on how you want to track those variables. Technically, your code is fine. The page-level and visit-level variables only need to get passed once. You really shouldn't be passing the exact same page-level variable on every single page if it's supposed to be measuring whether the visit is from a registered user. That sounds more like a visitor-level variable to me. Maybe visit-level, if you're just wanting to see whether a visitor has logged in during the current visit.
Visit-Level Custom Variables not showing up
I used the visit-level scope but the variables are not showing in the report. I am trying to understand why.
This code is on EVERY page. Is that why? But the membername or loginstatus should at least show up in the report. They both dont. they do when I change the scope to 3.
---xxx---
pageTracker._setCustomVar(1, "UserType", "Member / OR Guest", 1);// utmv cookie is set this works fine
pageTracker._setCustomVar(2, "MemberName", "UIDVALUE", 2); // Code placed on page only on Logon
pageTracker._setCustomVar(3, "LoginStatus", "Member_Logged_In /Not_logged_in", 2); // helps to know how many members came but did not log on
---xxx---
Using multiple custom variables
Geeta-
Make sure that either _trackPageview() or _trackEvent is called after those variables are set. Also, allow some time for those variables to show up in reports. Since it's just been rolled out, there have been reports that the variables have taken longer than 24 hours to populate.
Page and visit-level custom variables
Thanks! Yes I think this is what will work for me.
(1,VisitorType,"logged_in OR guest",2)
(2,RegID, "Reg ID",2)
(3,UserType,"member OR non-member" 1)
Only the custom var with scope 1 gets saved in the __utmv cookie and that gets passed across to the other domain which has my ecommerce stuff. The other two variables dont get passed across the domain. there is no Custom var code in my other domain. In my reports will I be able to corelate RegID with say the Finish page of otherdomain (my ecommerce site)?
Trouble with Custom Variables and _setDomainName = none
Hi
Good post. I've tried using Custom Variables and I think this works fine until I try to use them across multiple domains.
In order to send a first party cookie to another domain I need to set
_gaq.push(['_setDomainName', 'none']); but when I do this I don't get the utme information. Do you know why this is?
/ Niklas
Custom Variables and Multiple Domains
Niklas-
I need a little more information about what your code looks like to really troubleshoot this issue. Multiple custom variables should work just fine across multiple domains, but the utme information isn't going to show up in the query string with the other cookie information. Visitor-level variables are stored in the __utmv cookie, and that displays in the query string.
On a separate note, I would recommend setting a specific domain for _setDomainName, instead of calling "none". This way you can tell it to set cookies at a domain level, regardless of subdomains. In any case, it gives you more control over what's happening.
question about setCustomVar cookie
How does _setCustomVar work? Does it append data to an existing cookie or does it drop a new cookie?
I created a custom variable and am seeing results in Analytics, but I don't see a utmv cookie on my computer. Not sure what's going on.
How Does _setCustomVar Work?
Great question! It depends on the scope of the variable you set. If it is a visitor-level variable, it goes into the __utmv cookie and sticks with the visitor for future visits.
In the case of page-level and visit-level variables, it is not put into a cookie, but instead it's passed only in the __utm.gif request. This happens with every pageview or event.
Interesting
I find this very interesting. It's true that I know can pass cookie information using the querystring and the new tracking method as you saw for yourself. Just got this working after some help from the Google team. Apparently there is a flaw in the official docs (or so I claim) when you use the _link method in your links. They got the syntax wrong, could be good to know for the future.
After investigating this alot I have the following theory.
Scope 1 and 2 are page and session based and there is no point in trying to transfer these cross-domain.
Scope 3 creates the _utmv cookie and should be able to pass cross-domain but I've found no way in doing this.
I've created a test page at http://www.dynamicdog.se/customdd.htm which creates a visitor level cookie using
_gaq.push(
['_setAccount', 'UA-xxx'],
['_setDomainName', 'auto'],
['_setAllowHash', false],
['_setCustomVar', 1, 'Member Type', 'NewSuperUser',1], // Scope 1 = visitor-level
['_trackPageview']
);
After returning to dynamicdog.se I can see the _utmv cookie but when I click my link to the .com site it passes all the params but the _utmv. Can't see why really and but the use is somewhat limited anyway.
What is the difference between the _utme and the _utmv cookie?
Why set .domain.com and not have the "auto" setting figure it out? Is it the same principle for extended domains such as .co.uk
Best wishes
/ Niklas
Custom Variables and Multiple Domains
Niklas-
Maybe we're doing something different, but when I go to that test page and then go back to the home page and click the link to the .com site, it transfers everything over, including the correct __utmv cookie.
_utme is not a cookie, but it is a parameter passed in the __utm.gif request. It holds special values, like event tracking information and custom variables.
Page- and visit-level variables don't need to be passed to the new domain, since they only get passed to the server when they are initially set. Tying those variables to the visitor happens on the back-end. Visitor-level variables will be passed to the new domain in the __utmv cookie.
Finally, specifying a value for _setDomainName instead of just passing auto will allow you to set the cookies to the domain level, instead of the subdomain level. The same principle applies to any change in the top-level domain name. If you don't and won't ever use subdomains, it's not strictly necessary to set the specific domain.
Thanks
Haha off course it does. Must have been something fishy with the program I was using. Thank you for clarifying the difference between parameters and cookies. Will investigate this further.
Let's say you have three domains
site.com
site.se
and sub.site.com
And you want to track each as a seperate site with different UA:s. Is it then correct to use setDomainName("sub.site.com") for the sub? And use setDomainName(".site.com") if you wan't to share the sub with the main domain?
Thank you for your answers and for a good blog
/ Niklas
Asynchronous tracking across multiple domains = problem
Ahh. Thanks for the insight. The problem I was having was not with the Custom Variables setup but with the new Asynchronous tracking across multiple domains. Have you had a chance to try this?
Using
In swedish
With the old tracking code found on this site everythings works fine, but this new one simply won't work. Any clues to why?
Btw, what's your opinion on setDomainName? Let's say you have three languages and you value each one as important, would you still set a primary?
Thanks for your help
Best regards / Niklas
Asynch Code for Cross-Domain Tracking
At a quick glance, it seems to be working fine on your site. It passes the cookie information over to the new domain and sends the right information to GA. I guess I don't know what you mean that it doesn't work at all.
I would recommend setting a different value for every domain for _setDomainName. This has nothing to do with which domain is your primary domain. It has everything to do with how the cookies are set. In other words, on www.mysite.com I would pass '.mysite.com', on www.mysite.se I would pass '.mysite.se', etc. If the value of _setDomainName doesn't match the domain in the address bar, the cookies won't get set and no information will be sent at all to GA.