Slicing and Dicing Cookies – Part 2 – Body Parts

Last time on “As the cookie crumbles”, we featured the friendly cookie monster rescuing an eCommerce site on steroids.

Having been formerly introduced to the cookie monster, we can now talk about his body parts.

While we deal with all the values stored in the main GA cookies, we will show the Domain hash is the ultimate aid to GA QA and quick debugging.

The GA Cookie Jar

The complete selection:

Cookie Ingredients

The all-important Domain Hash

The first sub-component of every GA and Google Web Optimizer cookie is the domain hash. It’s a number calculated in ga.js or scriptopt.js (GWO) based on the domain name. The calculation is consistent (aka deterministic), always returning the same value for a given domain name. As geeky as this makes you feel, it’s important to pay attention to the number (only real geeks need worry how it’s calculated).

By default, GA uses the full host name as it appears in the URL (e.g. blog.vkistudios.com) to write its cookies and calculate its domain hash (103516550).

However, we use _setDomainName(‘.vkistudios.com’) causing ga.js to ignore the sub-domain “blog”, write cookies for the domain ‘vkistudios.com’ and calculate a hash of 24489125.

JavaScript is limited for security and privacy reasons to seeing only those cookies that are set in the same domain and sub-domain of the current page. Even though Javascript can specify values for all cookie attributes (such as expiry time and domains) when it writes the cookie, it can see only the names and values when reading them.

Therefore, when ga.js reads the cookies of a page, it will see all the __utm* cookies visible to the page’s domain and subdomains but not know to which sub-domains (e.g. “www.vkistudios.com”, “blog.vkis…”) they apply or if they apply to the entire domain (e.g. “vkistudios.com”)

So ga.js looks at the domain hash to distinguish between all the visible sets of __utm* cookies and choose the set that applies: either the current sub-domain or the domain set with _setDomainName().

Domain Hash – the litmus test for a correct implementation

Since _setDomainName(‘.vkistudios.com’) is used consistently throughout the entire site there should only be a single set of GA cookies for the whole site all with the same domain hash of 24489125.

If anyone were to move through all sections of the VKI site and come to have more than one set of VKI GA cookies, it would immediately indicate a bug in our implementation (a missing call to _setDomainName). That could lead to inflated visitor & visit counts, inflated bounce rates and campaigns and referrals that go nowhere. On an eCommerce site, it means revenue would not be attributed to campaigns, ads or other referrals.

It pays to keep an eye on the domain hash.

Raisin hell with the leading “.”

Vital fact #1: ‘vkistudios.com’ = 142977202; ‘.vkistudios.com’ = 24489125

Vital fact #2: Regardless of the leading period, the browser sees them referring to the same domain.

1+2 = 0. If only one call to _setDomainName(‘vkistudios.com’) on the site does not have the period, ga.js will calculate and look for a different domain hash, not find it, think there are no cookies and create a new set. The browser, however, when creating the new set, will overwrite the existing set.

The tell-tale sign is a domain hash of 142977202. We now wish we had only the problems of a missing _setDomainName(). In that case, the set of cookies containing traffic source status still existed and attribution of goals and revenue may still have been possible on pages with the _setDomainName() correctly set.

Now, the first set of cookies is overwritten and gone forever. It may be difficult to find the page with/out the delinquent “.” since, as soon as we move to a page that is correct, the browser deletes the incorrect set, leaving no tell-tale crumbs. Looks like an editor with a serious searching feature is required if, as the analytics implementor, you have access to the source code.

Not to get overly philosophical, but one wonders about the leading period’s raison d’etre!

Sub-component Values

My preferred method of learning and teaching is to kick the subject matter around whenever legal – particularly where it can be done interactively

Not all prefer such methods but I hope you will benefit from the following real-time table in the iframe. It loads VKI’s GA Interactive html script which calls our GA cookies class script gaVKIcookies.js.

In fact it’s more than an explanatory aid – it’s a Crude Little Testing Tool.

Loading the page on its own will be a lot easier.

You may then also add debug=y as a querystring parameter to show the raw cookies and, listed separately, only those that contain the current domain hash

To get the most out of it, you will want to run the page and the script from a domain under your control. We have restricted the use of _setDomainName() to prevent the nasty problems listed above.

Crude Little Testing Tool

Upon loading, it uses default values that appear in the form. Seeing as we can’t have a real one, we are faking a campaign.

The iframe source and the above link to the page contain campaign parameters, resulting in the __utmz referral cookie being populated.

Many different scenarios may be kicked around to see how the cookies ingredients are affected:

1. e-Commerce
   with multiple options, valid (1, 2 or 5 item transactions) and invalid (0 items).
2. Simulate new visits and new visitors.
3. See the
   affect of setAllowHash() options which when false, prevents ga.js from calculating a domain hash and simply using the value 1
4. Play with
   (sub-)domains (limited when using the page on
   our site)
5. Change the Web Property ID to your own UA-number
6. Change the virtual pageview name (great for identifying the results appearing in your reports as being part of
   the tests you run)
7. Set user
   defined values
8. Disable
   sending a pageview to create 0 Pageview
   visits

In the next post, we will look at Cookie Rules. Everything you ever wanted to know about GA and other cookies but were too …. to ask.