Analytics Pros

What's all the fuss about Google Analytics cookies and "domains"?

Whether you're a brand new user of Google Analytics or have a UA account number below 50,000. i.e. "UA-42442-1" - just a way to brag you've been using GA a looooong time :), understanding the cookies used by Google Analytics and the critical issues surrounding the domain to which those cookies are written and read is paramount to accuracy and reliability of your Google Analytics data.  The number one problem I consult with clients on solving relates to cookie domain issues.  It most commonly manifests in the form of "self-referrals", i.e. you see your own domain name listed in the "Referring Sites" report.  THAT is because of a cookie domain problem.  Other issues of high bounce rates, inflated visitor and visit numbers, and deflated time on site and pages/visit metrics also relate to cookie domain problems.

So, what's all the fuss about?  It's about everything important to using Google Analytics, and it begins with the cookies.  So, go grab a glass of milk and your favorite tasty snack (if we're talking cookies I prefer the home-made oatmeal chocolate chip kind) and read the rest of this post to understand the critical functions in Google Analytics that impact cookie domain settings.

Setting #1: _setDomainName()

This method defines the domain the ga scripts will read and write cookies.  There are three options for setDomainName:

First, The _setDomainName("auto") option
The "auto" - this is what is set by "default", i.e. if nothing is defined, auto will be used.  The "auto" setting tells the script to use the current JavaScript value location.hostname for the GA cookie domain (domain.site.com), unless that hostname begins with "www." or is a root domain (no sub-domain, such as "site.com"), in which case the GA cookie domain will set to use "site.com".  So, the "auto" setting on a sub-domain would result in the GA cookie domain being set to "domain.site.com".

No, the "auto" setting works just fine if your website doesn't have any sub-domains other than the universally accepted "www." prefix (which is technically a sub-domain itself).  You'll get into trouble, though, if you DO have any sub-domains where you use "auto", because it will result in visitors to pages on those domains having GA cookies set to "domain.site.com", not "site.com" as they were using on the main site.  That's how you end up with referrals from "yoursite.com" in your GA referring sites report.  It also inflates your Visits, Unique Visitors, and Bounce Rate, and deflates Time on Site and Average Pages per Visit.

Second, the _setDomainName("none") option
The second option is the dreaded "none" setting is the second option for setDomainName.  I saw "dreaded" because I loath this setting as it is the number three cause of problems I help clients solve.  I suppose on one hand if there was no "none" setting I'd have a lot less work to do fixing implementations... but really, I'd rather help people improvee their websites rather than triage implementation problems!

This setting does two things: first, it sets the GA cookie domain to whatever the location.hostname is and, unlike the "auto" setting, it doesn't gracefully handle the "www" and "no www" scenario, so watch out! If you're using "none" and you haven't setup a 301 redirect to consolidate "www" and "no www" into one domain you'll have more cookie fragmentation.

The second thing the "none" setting does is set the "domain hash" setting to "false".  This is the same thing as the setAllowHash(false) setting.  Turning the domain hash to false is essential if you are going to use the cross-domain linking feature of Google Analytics.  Thus, someone sometime somewhere thought it important to say you should use the setDomainName("none"); setting if you're going to use the linker option.  This is a bad idea! In my opinion and years of experience with GA you almost never, ever, EVER have a good reason for using "none" because it just it causes headaches for you and serious heartache for Cookie Monster (well, actually I doubt Cookie Monster cares about Google Analytics). 

So, what should you do with the "none" setting?  Nothing.  Unless you're really experienced with GA and have a very compelling reason to use it and fully understand the implications.

Third, the _setDomainName('custom value') option
The third option is defining a custom value for setDomainName.  This is what you should do on a case where you have sub-domains involved.  My recommendation is to always use the "auto" setting on your primary domain pages, and use a custom defined value for setDomainName on sub-domain pages that references the primary domain.  Note that, contrary to the instructions from Google on this, I do not recommend ever using a "leading period" because the "auto" setting doesn't use a leading period, thus if you leave "auto" running on your main domain's pages and use a "leading period" on your sub-domains you will see cookies be reset each time a visitors moves between a page on the main domain and the sub-domain.

Thus, using setDomainName("site.com"); should be done when you need to unify tracking between a main domain and sub-domain(s).

Setting #2: _setAllowHash()

The setAllowHash setting only needs to be used when there is a possibility you will need to use cross-domain tracking.  If you're like me and want to plan for the unexpected, then you should just use this setting by default on ALL pages of ALL domains you track.  Changing this setting down the road will cause cookie disruption.  If you're going to use the _link function then you must use setAllowHash(false); along with setAllowLinker(true).

The setAllowHash(false) option simply changes the portion of the Google Analytics cookies that encodes the cookie domain as a number to the number "1".  For example, the "hash" when left "on" would turn a domain like "site.com" into a hashed number such as "35235943", while using setAllowHash(false) would leave that number as simple "1".  This only becomes important when you're passing cookies across two domains using the linker function, since the "hashed" domain number must remain consistent.  If it is consistently "1" then things work.  If it's hashed against the current domain, and the cookie value you copy is from another domain, things break.

In Conclusion

The absolutely critical thing to learn from all this is that you must think about what you're installing.  Yes, Google Analytics is "available, easy, and free" - but it's not really that "easy" to setup properly.  Google Analytics is a powerful, enterprise-class product, according to their own words, and last time I checked "easy" and "enterprise-class" aren't identical twins.  Anyone signing up for Omniture or WebTrends and spending the money on those tools is going to think about how it's installed to make sure that it is done right.  So why not do the same with Google Analytics?  You're saving a ton of money by going with GA, so do yourself another favor and invest at least some time, if not some money in consulting from my company or another authorized consultant, to make sure your bases are covered and the data you'll get is reliable.

Display # 5101520253050100200

Forgot By: on 2010-Jan-21 03:03:51 Forgot to mention using custom values for subdomains but then I saw this: "Thus, using setDomainName("site.com"); should be done when you need to unify tracking between a main domain and sub-domain(s)." Shouldn't it be setDomainName("subdomain.site.com") ? for subdomains and then "auto" for site.com, site.net etc? Thanks / Niklas

Re: Niklas By: calebwhitmore on 2010-Jan-21 10:16:03 @Niklas: Thanks for reading and for the comments! You can't use ".co.uk" for your setDomainName value as that is not a primary domain but rather a domain extension.  Just like you couldn't set a cookie for ".com"  you can'tset it for .co.uk or any other domain extension.  To track users consistently between several different domain extensions you will have to use Linker and set your _SetAllowLinker(true), _setAllowHash(false), and use _link() on all links between every domain.  That is very hard to do and the point where I say either standardize on one primary domain and use country-specific sub-directories, or don't try to track users between the domains and accept the cookie fragmentation.  And really, if you have country-specific sites, the need for a user to go between two different country-specific domains should be minimal, right? Re: your second question - no, you can't use setDomainName("subdomain.site.com") unless you want the cookies on subdomain to be specific  to that sub-domain and notshared  with the primary domain. Best, -Caleb

Utmz By: Mehdi Laanait on 2010-Mar-10 12:30:42 When I use setDomainName("auto") on my primary domain and setDomainName("myprimarydomain.com"), I get 2 different utmz. (with firefox). But when I use "none", everything is ok. What's the problem?

Re: is it that simple? By: calebwhitmore on 2010-Mar-10 12:41:51 No, you would NOT want to do what you are proposing.  TLD's (.com, .se, etc...) will require different cookies.  On each domain you need to use _setDomainName("site.com"); along with _setAllowHash(false); and _setAllowLinker(true);.  Then, you'll need to use the _link() function for all links cross-domains.  For this I recommend the LinkTagger script from AnalyticsMarket.com (by Actual Metrics), which will automate Linker tagging for all appropraite links on a global basis. Best, -Caleb

Re: Utmz By: calebwhitmore on 2010-Mar-10 12:44:37 What you're running into is an issue you'll encounter when moving from using "none" to using "Auto" or another setting.  If you clear your cookies and only have "auto" on your primary domain and _setDomainName("site.com"); on your sub-domain, you'll share cookies.  If you use "none" on the primary and sub-domain you WILL get two sets of cookies.  IF you do that and then change back to using correct settings for your sub-domain, you'll still have remnant cookies unless you clear them out. This is one reason why planning your implementation for GA at the outset is so critical.  Once cookies get placed on visitor machines they are sometimes hard to eradicate when you change your GA settings, and the results will create really strange looking data accuracy issues. Best, -Caleb

_setDomainName & Subdomains By: José Montiel on 2010-Jul-04 21:38:24 Great article, simple and straight to the point. On question though. Why not just use _setDomainName('.mysite.com') on my main site and all subdomains? This option will handle mysite.com, www.mysite.com & sub.mysyte.com. So, What is the point of use auto on my main site? Thanks

Re: why use auto plus setDomai... By: calebwhitmore on 2010-Jul-19 10:19:37 @ Jose: thanks for reading, and for posting your comment!  As you've noted, yes, using setDomainName('site.com'); will work across your primary and sub-domains.  So, why use "auto" on your main site?  So that you can measure other places that might be loading your site and detect them.  Since setting setDomainName("site.com"); forces GA to use cookies for the defined domain, if that domain is 3rd party to the current domain it won't get and cookies.  Thus, when someone views your site through Google translate or Google cache, or someone steals your site and copies it onto another domain en whole (trust me, it can happen!) you would never know, since the setDomainName("site.com") won't work on Google.com or what other domain might have your tag and run it. So, using "auto" on the primary domain is a fail-safe method to ensure you have visibility into what's happenning on your main site wrt content use from other domains, proxies, translation engines, caches, etc... NOTE!!!  You *cannot* use "auto" on your primary domain and ".site.com" on your sub-domain.  The use of "auto" creates cookies SANS THE LEADING PERIOD, which will conflict with the use of a leading period in setDomainName();.  Also note, if you use setDomainName(".site.com"); and then add, say, Google Website Optimizer tags to your pages, it will result in cookie armogeddon as the two cookie settings conflict with eachother.  This is another reason why I advocate NEVER using a leading period.  Google advocates using a leading period because, yes, it's technically more compliant with standards and is, in fact, how it should be done.  HOWEVER, it's clearly not as big a deal as they claim because the "auto" setting, which is used by far more often than a custom setting, uses no leading period. .......... @Ryan: Your new code looks right at first glance.  To answer your questions: 1) Yes, use the same code, but be sure to customize the setDomainName method for each domain.  Remember when you're linking users between two different primary domains you have to ensure that *each and every* link is tagged with the _link() function.  Note this can be automated with our APe solution. 2) You absolutely CANNOT roll-out this code one part of the site at a time.  If you do it will cause complete mayhem to your GA cookies and undermine the long-term viability of them.  First, using the setAllowHash(false) setting creates cookies that can't be used by pages *not* using the hash(false) setting.  Second, you need to avoid having tags anywhere that would create cookies with hashes on a primary domain and cookies without hashes on a sub-domain, or vice-versa.  IF you have a gap in tagging and do create cookies with different hash settings on different domains or sub-domains the GA.js code will select the utmz cookie for the non-hashed local-domain version and use the hased cookies for the primary domain for utma, utmb, and utmc.  This will seriously mess up your Traffic Source reporting because it bifurcates traffic source data from visitor and session data. .................. Hope this is helpful! -Caleb

Subdomain, Primary Domain, and... By: Ryan Dwyer on 2010-Jul-08 13:22:20 Hi Caleb - I'm picking up midstream with a client of ours and we're adding a subdomain to the mix of properties that we want to track under one umbrella.   I'd like to second the recent post made on July 4th by Jose as that is the coding modification I plan to recommend to our client. Current situation: existing code was set to track one primary domain, not multiple subdomains or alternate primary domains.  The existing code and proposed code are posted here. Existing code: var pageTracker = _gat._getTracker("UA-xx"); pageTracker._trackPageview(); Proposed code (utilizing a new asynchronous code, we'd also swap the inital js call so the entire tag is asynchronous):   _gaq.push(['_setDomainName', '.site.com']);   _gaq.push(['_setAllowLinker', true]);   _gaq.push(['_setAllowHash', false]);   _gaq.push(['_trackPageview']); 1) Would I use the same code for alternate primary domains down the road such as dickies.co.uk or blogspot/dickies.com? 2) If we rolled out this code to the highest traffic portion of the site first how might that affect cookies if a user went to the homepage (with new tracking code) and then went to purchase (with old tracking code)? Appreciate any help you can lend...good advice won't be forgotten! :) Cheers, Ryan

Is it that simple? By: on 2010-Jan-21 02:41:06 Good post. There seems to be many people advocating for different solutions. This was the first time I saw a solution using Auto. Let's say you have three domains .com, .se and .co.uk and each one has a subdomain. Regardless of where the visitor lands you wan't to track there visit across all domains and subdomains as a single visit, transferring cookie data. Would you just set auto for .com, se and .co.uk, disable domain hashing and set linker to true? Using _link on links between the sites. Are you saying this would work?