Google Analytics Cross Domain Tracking and _setDomainName()

Question

I\'m trying to set up cross domain tracking between two totally different Domains (not sub-domains). Looking through different pages of Google\'s documentation seem to give

Answer 1

I thought mysite.com will track across that site and its 1st level subdomains (like mysite.com and cats.mysite.com), and .mysite.com will track across that site and its 1st AND 2nd level subdomains (like mysite.com and cats.mysite.com and store.cats.mysite.com).

I base that off what google and some other articles say.

none will disallow any subdomain tracking (so I assume it sets it to set the cookie's domain to: www.mysite.com).

Im guessing the default option auto will set it via document.domain to www.mysite.com (but maybe mysite.com if not on the www domain based on Eduardo's answer above/below to allow allow smarter 1st level subdomain tracking).

The auto/none are guesses from me, not sure what it would put for the domain if you came on blah.mysite.com and had those none/auto options set.

Answer 2

If it is cross domain

tracking,_gaq.push(['_setDomainName', 'mysite.com']);

or

_gaq.push(['_setDomainName', '.mysite.com']);

does not make any difference, as cookie information is not shared across these two different domains any way.

I've set up tracking between domain 1 and domain 2, one way tracking. Initially as suggested in Google Analytics I've added _gaq.push(['_setDomainName', 'none']); on both of the domains. It was for new Google Analytics A/B testing, verification for A/B testing resulted in error. So, I removed _gaq.push(['_setDomainName', 'none']); from domain 1 and left it on domain 2 as it is and it worked perfectly fine.

I've documented it here.

Answer 3

Ben, the best explanation is on the Google Documentation page - http://code.google.com/apis/analytics/docs/tracking/gaTrackingSite.html#domainToNone. Get to know this page, there are a lot of ways to configure your GA setup and there is no definitive way of saying 'this is how you need to setup cross domain tracking' without knowing a lot more about your desired configuration. The scenarios on that page should certainly help.

There are 3 distinct reasons for using the different variations of _setDomainName.

• 'none' - you only need to use this feature when you want to track a top-level domain independently from any of its sub-domains, since this parameter will make the cookies of a domain inaccessible by its sub-domains.

• 'mysite.com' - Use this when tracking between a domain and a sub-directory on another domain. For example, your 'mysite.com' profile should also record hits from 'yourblog.othersite.com'.

• '.mysite.com' - Use this when you want track across a domain and its subdomains. This will treat top- and sub-domains as one entity and track in the same profile. For example, 'mysite.com' profile should record 'blogs.mysite.com' and 'shop.mysite.com'.

I recommend setting up some test profiles and experimenting with your configuration, that way you don't 'dirty' your real data.

Hope this helps!

Answer 4

The Docs pages are a little behind, because there were some recent changes that changed the best way to do it.

The default settings for _setDomainName is 'auto'. This will set the cookie to your full domain, unless you're on the www domain, in that case it sets to the mysite.com without the leading dot. This settings can cause problems, and I avoid sticking with them. I allways change it

There are 2 options of setting a domain name for www.mysite.com.

• _setDomainName('.mysite.com') -> This is necessary when you want to track all the subdomains as well.
• _setDomainName('www.mysite.com') -> You should use this one if you don't want to track your subdomains.

In 99% of the cases I go with the first option. Setting it for the top domain but using the leading dot. You'll see a lot of people advocating against the leading dot. Like this old but good post from roirevolution. The concerns around the leading dot is that it can cause cookie resets. But it only happens if someone already have the cookie. If this is anew implementation you don't have this problem.

_setDomainName('none') is equivalent to _setDomainName('auto') + _setAllowHash(false). But since _setAllowHash(false) was deprecated I guess _setDomainName('none') should be deprecated as well.