Firstly my apologies – this article contains more ‘geek speak’ than normal.

The subject of all this fuss is Google Analytics and the cookies it places on your website visitors’ computers. In these few words I’m going to explain the types of cookies placed and how they are updated and why, if you don’t understand the basics of this system, your Google Analytics set-up could be flawed and your reports full of false data.

OK – let’s get started with a brief introduction to cookies. They are electronic text files that are placed on your visitors’ computers by websites that need to identify these users during their website session to make the site function properly. Each cookie text file provides a specific set of information to make each website that sets them work.

Unless you have cleared or removed the cookies on your computer you may well have dozens that have been set on your machine by various websites as you have browsed your trail across the Internet. Shopping carts are a big user of cookies. Google Analytics needs them so it can see that you are a returning visitor to the website and how long you have stayed browsing. That’s the extent of the quick summary you are getting – if you need to know more, then visit Wikipedia and search under ‘HTTP Cookies’ to learn more (at http://en.wikipedia.org/wiki/HTTP_cookie).

Cookies can be set as either first-party or third-party cookies. This status relates to the match between the domain name of the web page that the website visitor was at when the cookie was set and the domain name of the cookie. First-party cookies are set to act only on the website domain shown in the address bar of the visitor. For instance, you visit www.permission.co.nz and Google Analytics sets a series of cookies that relate to it working on www.permission.co.nz.

All OK so far? Here’s where it gets a bit devious. Third-party cookies are set by domains other than those in the address bar. For instance, you visit www.sneakysite.com and a cookie is set for www.sneakyothersite.com. This sounds (and is) quite devious and, fortunately, is not something that Google Analytics does. Google Analytics only uses first-party cookies, which can cause issues when your site spans multiple domains – but more on that later.

So now let’s get stuck into what cookies are set when and why. Once you have properly installed the JavaScript code for your version of Google Analytics on each of your webpages then, when a visitor comes a-calling, they will have set on their computer four first-party cookies.

Here’s a screenshot of them being set on my computer when visiting the Air New Zealand site, which has Google Analytics running on it.

The first cookie is called the true geek name of ’_utma’ – this is called a persistent cookie because technically it never expires. The ones I have seen are dated – in the year 2010. Repeat visits and visits to purchase are just two visitor reports that are derived from the use of this cookie.

The ‘_utmb’ and ‘_utmc’ cookies work as a pair to determine the time your visitor remains on site. The first, ‘_utmb’ is set with the exact time the visitor arrives on your site and then expires at the end of the session. Its partner, ‘_utmc’ is a session cookie that waits for 30 minutes of visitor inactivity before it fades away. The time difference between the two, less the 30 minutes, is used to work out visitor time on site.

The ‘_utmz’ cookie keeps track of where the visitor came from. For instance, if they come via a keyword search, it shows what keyword they used and on what search engine. Unless you alter the way this cookie is set, this attribution is set to expire in 6 months. So, if a prospect arrives via a keyword search on day 1 and comes back in month 3 and makes a purchase, the keyword they searched on will be credited with the sale.

The final cookie Google Analytics can set is ‘_utmv’ (not shown in the Air New Zealand example). This one is only set if the owner of the Google account that manages the website wants it to be. Like its cousin ‘_utma’, this one is a persistent cookie and can be quite handy to set if you want to segment your visitor reports into two separate groups. For instance, you may want to set this cookie after a visitor has logged into a members only area or after they have purchased from your site. This allows you to run reports to see how ‘members’ or ‘customers’ browse your website compared with others. Google has some rules over the type of data you can use when setting this cookie, mainly around the use of identifiable information in the way it is set.

OK – so what happens if the visitor decides to delete these cookies? Well, there’s nothing you can do about this. And when they come back to your website, your version of Google Analytics will treat them as a new user. Best you be aware of this fault in the system and treat your reports as providing you with a strong guide to what’s happening, rather than a totally accurate representation.

Now, back to the earlier discussion on how Google Analytics uses first-party cookies and how, when your site spans multiple domains, this cookie status can cause reporting problems. The key point here is to remember that Google Analytics can only use cookies that are set from domains (and sub-domains) that are shown in the address bar of the web page your visitor is on. So, for instance, if your website visitor lands on your main domain www.shopsiteexample.com, where they find the product they want and then decide to purchase it through your shopping cart, all is well if this cart has an address like www.shopsiteexample.com/cart. Things become more complicated when this cart is hosted on a sub-domain of shoppingcart.example.com or, even worse, a hosted cart environment at Yahoo or PayPal, which may have an address of www.hostedcart.com/shopsiteexample.

To make both of the last two environments work, you will need to modify the ‘out of the box’ Google Analytics JavaScript tag. Just doing this will solve the first issue of visitors moving between sub-domains. When they move to completely new domains, you also need to add extra JavaScript code that will pass the person’s cookie details from the first domain to the other one. For instance, your website visitor may go from www.shopsiteexample.com to www.paymentengine.com and then receive their order confirmation on this same domain. To make this all work you need to be able to install your now altered tracking code onto the domain www.paymentengine.com. (I’m sorry to say that if you can’t do this then the tracking will not work.)

Then you can add some extra JavaScript to alter the URL that links the shopping site to the payment engine to now include the cookie details of the person. The example URL below shows some of the cookie information added.

http://p6.co.nz/boston/callmeNew.php?__utma=220047114.103641444.1203475444.121384247
2.1214427694.22&__utmb=220047114…….

Now, once all is working well, your Google Analytics account will follow visitors as they move from your main domain to sub-domains and even across to the externally hosted shopping cart pages where, with luck, they will complete the purchase.

Has this confused you rather than clarified things? If so, then just look at the domains your website works on – if a visitor remains on the same one for all their browsing experience, then all is fine. If they move from domain to domain, then give us a call and we can talk you through your options to make your Google Analytics set-up work.