A month ago, I said I'd be creating a Part 2 to my first cross-domain tracking post that will attempt to address some of the questions and run some additional tests within a few days. Although 30+ doesn't quite qualify as "a few", I'm back to attempt to shed some light on a bit more of the nuance behind cross domain tracking.
I ran a test to specifically determine whether _setAllowHash was truly needed or not. Previously, I was uncomfortable with the fact that the cookie values on different domains were different, as it's a quick and surefire way to verify a visitor traveled across domains. However, Google advertised that setAllowHash, the mechanism that made it all possible before, was no longer needed. They're a pretty good company that has some development under their belt, so I figured they deserved the benefit of the doubt. The test was as follows:
I picked two domains without Google Analytics, we'll call them Domain A (domain-a.com) and Domain B (domain-b.com). I used FireBug to run a custom tag on both sites that fired to a UA code that I owned and operated. The tag on Domain A was:
While the tag on Domain B was:
In addition, I chose a link randomly on Domain A and modified it using FireBug to include the following onclick event and custom href:
The simple test was to execute the tag on Domain A, click the link, then execute the tag on Domain B. Simple, straightforward, and difficult to screw up. I noticed in the image requests that the cookie values on both domains were different. A good start, as that was one of my concerns. I also noticed that the cookie values from Domain A were appropriately appended to the query string in Domain B. So far, all good. I ran another test just to put more than one session in the profile.
The next day, I checked my GA profile. The results? Two visits, two unique visitors. It would appear that Google is able to recognize the cookie values within the query string and attribute two different sets of cookie values to the same visitor. Those sly devils.
I'd like to do a few more rigorous tests, but it looks like the _setAllowHash is truly not necessary, even if it does make me a little nervous. Good on ya, Google.
A much appreciated comment on the previous blog noted some confusion due to subtle differences between how sites tell a user to track across domains. I feel like it is a potentially very common source of confusion, so I'd like to call it out directly within the content of this post. The question was as follows:
I was curious why some code on internet had 'abc.com' and others had '.abc.com' and both seemed to be touted for use for subdomains tracking (guess newer GA code said 'abc.com' tracks subdomains also).
I was curious on your take for this most comprehensive example I found, do you think their solution is still valid [example is best one i found, but code is from 2009] Advanced: Structure Your Account With Roll Up Reporting And More
They use _setAllowHash sometimes which i thought is funky. and also setDomainName is 'none' on the 3rd party checkout, and not set at all on 'c.com' (not sure why)."
My long-winded response was the following:
As far as your initial question, the only functional difference between setting the domain name to ".abc.com" versus "abc.com" is the value that the GA tag will hash the domain to, since the leading period will in fact change it. However, if you disallow hashing within the code, both examples will set the cookie at the domain level, allowing cross-sub-domain tracking.
As far as the example itself, I completely understand the confusion, and I'll do my best to clear it up. In short, within the requirements set by the blog post itself, it's definitely a viable solution. As for the "why", I'll split it up into multiple sections, one for each domain. For reference, the first image under the heading "The Strategy" helps illustrate the problem.
For domain a.com, you have multiple sub-domains, as well as a completely separate domain, www.mystore.com, to track across. The sub-domains require a domain name of ".a.com", so the cookie will be accessible regardless of whether you're on www.a.com, or blog.a.com, etc. The hash is disabled and linking is enabled to configure cross-domain tracking to www.mystore.com. Disabling the hash means that the tag will accept the cookie value on completely separate domains, which would enable you to create a funnel from a.com to mystore.com and track visitors from original visit referrer to purchase. Because you're using both cross-domain and cross-sub-domain, you need the whole kit and caboodle.
For b.com, you're only concerned about tracking across sub-domains. According to the picture, b.com does not link to the e-commerce site onmystore.com, so you do not need to disable hashing or allow linking or any of that business. However, due to the cross-sub-domain tracking, you do need to set the cookie domain to just ".b.com", similar to how the domain name is set to ".a.com" in the previous scenario.
For c.com, you're only tracking one site:www.c.com, no sub-domains, and no third-party e-commerce domains. Therefore, you do not need to do any domain, hash, or linker configuration.
For mystore.com, the "none" shortcut is used for two reasons: 1. They need to disable hashing, and 2. The site does not have any sub-domains to track across. Specifically, passing "none" automatically calls setAllowHash(false), in addition to setting the domain name to the full domain, which would bewww.mystore.com in this case. The hash needs to be disabled to accept cookie values from the a.com domain.
I hope that clears it up a bit. I do want to also note that the current version of the GA base tag, without doing any setDomainName calls, automatically defaults to just the domain. For example, if you run the base tag on www.a.com, the cookie will be set to "a.com" by default. Note that for the purposes of hashing, the string "a.com" is used instead of ".a.com". However, most often I will still set the domain name explicitly because I don't like any mysteries or "magic" with my code."
To add some additional spice, note that if you do not include _setDomainName in your base tag for sub-domains, such as sub.a.com, the cookies will set themselves to the full domain path if no other available cookies exist. You'll want to watch out for this scenario in case a user may hit a sub-domain instead of your "www" domain first for any reason.
Also note that using "none" for _setDomainName is always just a way to save on code lines. I was raised in a school of programming thought that discourages tricks to save on code lines, so I've always preferred more lines of code when they help with understanding.
Witty Header for Configuring Profiles for Cross Domain Reporting
Another good question came through in the comments regarding reporting. The question was as follows:
"Is the UA the same for both domains so under the same web property or would you set each domain up under a separate UA/Web Property."
When looking at this help doc from Google, Tracking Multiple Domains, It appears that they UA's are the same.However, we were advised by a GA rep to keep them separate. Conflicting information for sure.
If you're setting your tag up for cross domain tracking, I'd be more than just my bottom dollar that you want to report both domains into the same profile for analysis. The only way to do that in GA at the moment that I know of is to use the same UA code on both domains. I treat the UA code like a bucket. If you put the domains into two separate buckets, you'll need to look inside those particular buckets in order to see that data. The only way to see it together is to put it into the same bucket.