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

Slicing and Dicing Cookies - Part 2 - Body Parts


Look closely - they're choc-full of info

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:

Name Purposes Expires: Updated: Sub-components Notes
"Goes well with…" Best before: Freshly baked: Ingredients: Grandma's secrets
__utma Anonymous token representing the visitor and storing his/her visit history 2 years On each visit · Domain hash;
· Anonymized, arbitrary visitor token;
· 1st visit start time;
· Previous visit start time;
· Current visit start time;
· Visit count
Specific to the combination of the domain, visitor, browser, machine and OS login. Same person on the same PC using another browser is a different visitor.
__utmb Identifies the current visit and stores the attributes of the visit listed in the sub-components column 30 minutes of the last activity that sent a gif request to GA. On each .gif request · Domain hash;
· Gif requests;
· 10;
· current visit's start time
Typing a long blog post that does not trigger GA events is not "activity"
__utmc Indicates the existence of the browser session When the browser is closed At the start of each visit Domain hash GA starts a new visit if either the __utmb or __utmc cookies no longer exist. That will occur on the earlier of the browser closing or 30 mins of inactivity.
__utmv Stores the "User Defined Value" set by _setVar() 6 months On each change to the value. · Domain hash;
· User Defined Value;
The cookie may be changed in the middle of a visit but GA only recognizes the new values that exist at the start of the next visit.
__utmz Traffic Source (Campaign, referrer search engine or direct) 6 months Upon a new traffic source (other than "direct") · Domain hash;
· Traffic Source attributes;
· # of responses to a TS. 1 when cookie stores a direct referral;

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.

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
.