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:
|"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||
· 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||
· Gif requests;
· 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.||
· 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")||
· Traffic Source attributes;
· # of responses to a TS. 1 when cookie stores a direct referral;
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.
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!
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:
- e-Commerce with multiple options, valid (1, 2 or 5 item transactions) and invalid (0 items).
- Simulate new visits and new visitors.
- See the affect of setAllowHash() options which when false, prevents ga.js from calculating a domain hash and simply using the value 1
- Play with (sub-)domains (limited when using the page on our site)
- Change the Web Property ID to your own UA-number
- Change the virtual pageview name (great for identifying the results appearing in your reports as being part of the tests you run)
- Set user defined values
- 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.