VKI Studios is now Cardinal Path! www.CardinalPath.com
Learn more about Cardinal Path

Tips Tricks, Traps and Tools: # 3 of many: Quick Diagnostics

As practitioners, we are often approached to troubleshoot a GA installation.

The site owner is perplexed and cannot figure out a problem that may look something like this:

  • Your campaigns show they are driving traffic to your site.
  • Your goals and eCommerce reports show conversions.
  • However, the campaigns do not appear to be the bringing in those conversions and transactions.
  • Can our campaigns be that lousy or is something else wrong?

Here is a litmus test

This will show you quickly where some problems might be lurking.

We have previously recommended WASP and here we go again - and for good reason.

Those who insist on free software at any cost may also use any Firefox add-ons that display the cookies that are relevant to the page you're on. (Firefox's built-in display of cookies is uncomfortable for monitoring cookies while surfing, but you may be able to use it so: Tools | Options | Privacy | Show Cookies then search for the domain you're working with). I might have told you how but I'm not recommending it. It's is like a cardiologist trying to listen to your heart with a water fountain paper cup. You'd question whether he could diagnose problems and expect him to spend a few bucks on the appropriate tools.

But back to the diagnosis...

Go to your home page and delete your cookies (Tools | Options | Privacy | Show Cookies, search for the domain and delete all the cookies associated with it)

In the following images, we started from an AdWord link which resulted in the cookies shown in WASP AdWord Referral


Figure 1 WASP AdWord Referral

Note the boxed entries and the values, "google" (source), "brand" (campaign name) and "cpc" (medium). These are stored in the __utmz cookie. For as long as the cookie remains unaltered on the visitor's machine, the browser will credit that ad as the source of this visitor's visits.

Note too, the "Domain Hash" (whatever the heck that is!) with the value of 1.

Now lets look at the visitor's 2nd page on the same site in the same visit in WASP AdWord Referral Page 2:


Figure 2 WASP AdWord Referral Page 2

The most important change to note is that the domain hash has changed to 212755029. Don't be put off by what the domain hash is or how geeky or apparently complicated it might be - its just a number.

In a nutshell, GA identifies the cookies to read for tracking your site by its domain hash. It does not matter what the number is, as long as it does not change when it shouldn't—and generally, it won't.

Either way, note from WASP AdWord Referral Page 2 that the source of the visit has been lost. Or at least has not stored in this cookie set's __utmz, which now records the visit as a "direct" visit (as if the visitor entered the URL in the address bar).

Performing the diagnosis on your site

Find an AdWords impression of yours on Google, and click on it. Note the domain hash in the cookies (it will either be 1 or a large number). Then surf around the site and proceed to accomplish one of the Goals set up in GA or complete a transaction, all the while keeping an eye on your cookies using what you learnt from the above images and descriptions.

If that change happens while you move through your site, something has either caused the original cookies to be overwritten, or there are 2 sets of cookies.

If your cookies' domain hash changes between large numbers and 1 its because of the inconsistent use of:

_setAllowHash(false) and/or _setDomainName("none").
Either of these function calls will cause GA to no use an actual domain hash but rather a value of 1

If it changes between 2 large numbers, it is because of the inconsistent use of the following:

_setDomainName("mysitesdomain.com")
_setDomainName(".mysitesdomain.com")
_setDomainName("www.mysitesdomain.com")
and/or no _setDomainName() at all.

In the images we see 2 cookies __utmx and __utmxx, consistently with the 212755029 domain hash. These are Google Web Optimizer Cookies and they are the possible cause of the troublesome change.

For an in-depth look at Google's cookies, see Slicing and Dicing Cookies - Part 2 - Body Parts.

I will be writing a lot more on the practicalities of GA troubleshooting over the next few weeks.

In the meantime, don't be shy to approach with your feedback and questions.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
I just wanted to say thanks as this article helped me debug and solve a problem whereby sources were being reverted to "referral" mid way through a conversion process. Thanks again!
# Posted By John Robinson | 10/9/09 4:00 AM
Vielen Dank für Ihre schnelle Diagnose (Quick Diagnostics)
# Posted By Zo | 11/20/10 5:54 PM
This is really helpful info to me with trying to wade through all the learning that goes with GA.
# Posted By Whims | 12/20/10 7:31 PM
Thanks for sharing.
In GA documentation this function was defined in 4 lines... you have demostrated it's not enought!
# Posted By Bruno Rico | 4/27/11 7:58 AM
Hi Brian.
I see you mentioned here:
http://txptips.com/using-txp-constants-and-subdoma...
That the setting '_setDomainName', if wrongly configured, can "be dangerous".
Please, could you explain a little more aboth what's exactly dangerous (particularly, if they are related to security and/or privacy)?

Also, tangentially related, which would be the better setting to approach setting the cookie for the whole domain (.example.com), and so, disabling the ability of setting a cookieless subdomain?
This one?
['_setDomainName', 'www.example.com'],
or this one?
['_setDomainName', 'none']

Not setting the GA cookie for the whole domain to allow the cookieless subdomain trick seems a Good Thing to me. If not, the only chance is to resort to a second, totally different, domain name, to do the cookieless domain trick.

Thanks.
# Posted By Julián Landerreche | 9/19/11 8:48 PM
.