Understanding Google Analytics "cookie domain" settings

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.