Web Analytics and Optimization Blog

Google Analytics Installation Guide

August 18, 2007 – 12:03 pm

Why am I writing a Google Analytics installation guide when Google already provides such excellent resources on the subject? Good question! The problem I find with their resources and the installation process in general is that there is no “wizard” guiding users through the correct path towards making the right calls while installing.

For example, most users find out only after the fact that a site serving multiple subdomains really should be setup with the appropriate filter as well as the appropriate cookie setting (_udn). Another example is users wondering why their profiles are reporting http://www.theirsite.com/ and http://www.theirsite.com/index.htm as two different pages. Of course Google has the answer to this question, but this kind of thing isn’t known to the first time user and usually provides a nice “doh!” moment when looking at 3 months worth of stats.

So here’s my first attempt (I’m certain there will be updates) to at least try to guide a first-time user on how to properly install Google Analytics.

Note: I’m only going to be considering non-ecommerce sites for this post originally but I’ll likely add to it later on.

Table of Contents:

• Step 1: Do a little homework
• Step 2: Create a new account
• Step 3: Configure that (those) profile(s)
• Step 4: Tag those pages
• Step 5: Now tag ALL your pages
• Step 6: Validate your data
• Step 7: Celebrate good times, come on

Step 1: Do a little homework (Top | Table of Contents)

Don’t worry, nothing too intense but there are a few things that you should have written down somewhere before pursuing a Google Analytics installation. Work with your IT team to get answers to the following questions up front:

• Does our site have multiple domains? (i.e. www.domain1.com and www.domain2.com) - the importance behind this question will be shown below but the idea here is to ask “Are you planning to track a user experience from www.domain1.com to www.domain2.com as though it were a single homogeneous site?”
• Does our site have multiple subdomains? (i.e. www.domain.com and my.domain.com) - notice the difference between a domain and a subdomain
• Do we want to report on all of our subdomains rolled up into one report and have them broken out separately? - ask yourself if it’s important to know only the activity around only my.domain.com as opposed to having that traffic lumped in together with www.domain.com
• What is the “default document” used for our site? - usually something like index.htm or defualt.htm, this is the document that’s served by default when someone types in http://www.yoursite.com/ and doesn’t specify a specific page name. Some websites have more than one default document. Unfortunately at the time of this post, Google Analytics only supports one default document for your site (although I’m looking into a way to accomplish similar behaviour with an advanced filter)
• Do we want to exclude internal traffic from showing up in our analytics reports?- this one requires more than a quick two second decision and should be considered carefully with your IT team
• What are our four most important web pages (actions / events) that we consider to signal a “successful” visit?

That wasn’t so bad was it?

Step 2: Create a New Account (Top | Table of Contents)
Notice that does say a new account and not a new profile. A colleague of mine recently pointed out that Google’s AdWords accounts are able to be linked up to Analytics accounts but only on an account-to-account basis. Meaning if you created a single account say for “All Company Websites” this may not work out well for you as you won’t be able to hook up your AdWords data to each of the sites in this account.

This is personally a thorn in my side because one of the biggest benefits about keeping all of your site profiles in one location means you can easily apply things like user rights administration and filters, but c’est la vie.

If you already have a Google Analytics account, then creating / adding a new account is as easy as logging into the interface and selecting Create New Account… from the drop-down menu at the top-right of the page.

If you don’t have an account set up just yet then you’ll have to create one first by heading to the Google Analytics site and clicking the Sign Up Now link.

Once the account is created and Google provides you with that nice code snippet to use on your site, hold off before actually installing and keep reading.

Step 3: Configure that (those) profile(s) (Top | Table of Contents)

Although your account is now set up, absolutely nothing is configured for it (this screams the need for Google to create more of a deeper “wizard” driven sign-up process).

Step 3.1: Configure your default document

If you did your homework from step 1, you’ll know the default document that your website uses. Google covers how to change your default document for your profile pretty well so I’ll just provide their answer.

Step 3.2: Create your filters

Multiple Subdomain Filter

If you answered yes to “Does our site have multiple subdomains?” then you’ll need to create a filter that essentially ensures that Google knows not to confuse http://www.example.com/ and http://my.example.com/ as the same page (which it will by the way without this filter).

Create an advanced filter with the following information:

Filter Type: Custom filter > Advanced
Field A: Hostname
Extract A: (.*)
Field B: Request URI
Extract B: (.*)
Output To: Request URI
Constructor: $A1$B1

If you’re at all curious what this is saying in plain English it’s essentially, “instead of just giving me /mypage.html?query=1 (the Request URI) in my content reports, take everything that I see as the domain of the site (also known as the hostname) then take everything I see for the URI (Uniform Resource Identifier) then slap them together”.

The result is transforming what once looked like:
/mypage.html?query=1
into
www.mysite.com/mypage.html?query=1

Exclude external traffic

If you answered yes to “Do we want to exclude internal traffic from showing up in our analytics reports?” from step 1 then you’ll need this step. I’ll write a bit of a cautionary note on this one as you may want to reconsider removing internal traffic before you do so. Simply because traffic came from within your organization doesn’t mean that it isn’t completely valid traffic. If I have a content site like www.canadianbusiness.com and I work for that publication, perhaps I actually do use it at home and at work to read relevant material.

What’d I’d recommend here is instead of applying your external traffic filter to all your profiles, create one additional profile with this filter applied so you can at least get a sense of how much internal traffic is contributing to your key metrics.

Follow Google’s steps to create a new profile and call it the same name as your original profile except add ” - Internal Traffic Excluded” or something similar. Before using this profile however, ensure that you have applied the exact same filters you applied to your first profile as well as configuring the default document as you did earlier in step 3.1. You need these profiles to be absolutely identical except for the fact that your new profile will have internal traffic excluded.

Before creating the filter itself, work with your IT team and ask them for the range(s) of addresses that your company uses for their IP addresses. For example, a company may own all IP addresses from 63.212.172.0 to 63.212.172.100. If your company is large it will likely have more than one range of IP addresses; don’t sweat this, just grab all the ranges you have.

As for how to actually create the exclude filter, create a filter of type “Exclude all traffic from an IP address” and use Google’s wonderful tool to help you with the IP address to fill in (this tool also has instructions for how to combine multiple ranges). Google utilizes regular expressions for all filtering operations. While this is an extremely powerful feature, for those who understand regular expressions (regexs for short), it becomes rather difficult to understand for others with no previous experience.

Step 3.3: Create your goals

I bet I know what you’re thinking, “Why is he talking about tracking goals now? I just want to start seeing my stats”. I hear you, the problem with that thinking is that Google doesn’t support any retrospective look at your stats. So when you’re a few months into tracking things with Google Analytics and your boss asks you “Can you tell me where people are dropping off in our registration process?” or “What’s been the return on investment of your AdWords buys?”, you’ll have to tell him to hang on for another week or month. A little forethought goes an awful long way in the world of web analytics.

That being said, try to think about a few goals on your site by considering what constitutes a successful visit to your business (not necessarily to your visitor although that’s arguably more important). For example a successful visitor comes to my site and registers for the newsletter and / or e-mails an article page to a friend.

Because this isn’t a post on advanced tracking I’ll just leave it as try to associate your goals with actual pages that exist on the site (i.e. a successful sign-up is http://www.example.com/thankyou.html). Once you’ve got that down, Google has a pretty comprehensive guide to show you how to create and configure your goals.

Step 4: Tag your pages (Top | Table of Contents)

If your site is a simple single domain powerhouse (i.e. www.example.com), then you don’t need to read any further. Simply copy the code provided by Google and work with your IT staff to place it immediately after the <body> tag of every page on your site.

Important: Take note that I’m recommending placing your code at the beginning of the <body> tag and not just before the </body> tag (as Google initially recommends). The main reason for this is that I guarantee after you get your feet wet with web analytics, you’ll want to track a few more advanced features and that requires the tracking code to be up at the top of your page, not down at the bottom.

If you’re one of the unlucky ones that has a slightly more complex site that spans multiple domains and / or subdomains then the Google Analytics tracking code won’t do the trick if you’re looking to do cross-domain tracking or planning to add anything fancy later. Again, Google explains all of this, but as an afterthought to the install process which can provide one of those aforementioned “doh!” moments. So here are two best practice methods depending on the result of your homework from step 1.

If your site spans multiple subdomains (i.e. my.example.com and www.example.com):

Modify your original Google tag to read:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
<script type="text/javascript">
_uacct = "UA-XXXXXX-X";
_udn = "example.com";
urchinTracker();
</script>

Then place this tag immediately after the <body> tag on every single page of your site.

If your site spans multiple domains (i.e. www.example.com and www.domain.com):

Modify your original Google tag to be:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
<script type="text/javascript">
_uacct="UA-xxxx-x";
_udn="none";
_ulink=1;
urchinTracker();
</script>

Then place this tag immediately after the <body> tag on every single page of your site (on both sites with both domains).

This now brings me to one of Google Analytics’ most frustrating parts of an install. According to Google, the only way to correctly track cross -domain traffic like this is to modify every link on your site that links between the two domains in order to add their tracking code (as well as modify any forms that you have that are submitting their data cross-domain). Not only is this really hard to accomplish for a large site the first time through, but with large organizations with complex CMS setup it becomes next to impossible to maintain.

I am currently working on a script for accomplishing this kind of tracking automatically rather than manually having to enforce policies, but it’ll require a bit more testing until I’m done. In the meanwhile you can attempt to follow Google’s proposed solution, or just settle on tracking these two domains individually.

Step 5: Now tag ALL of your pages (Top | Table of Contents)

Although you wouldn’t think it, a lot of organizations suffer from a similar problem of not actually tracking all their pages. Making sure that literally every page on your entire site is being tracked is a bit trickier than running Google’s “Check Status” link and getting a green checkmark.

First things first, all that Google will do to confirm the tracking code is on your site is check whatever page is housed at the web address you provided during setup. So for example, if your web address is http://www.mysite.com, then Google will only retrieve your home page and check it for the tracking code then provide you with a thumbs up. But last time I checked, most sites extend beyond a single home page!

Where the problem usually lies is with organizations employing complex content management systems (CMSs). A CMS will allow you to apply the Google Analytics tag relatively painlessly as the idea behind any CMS is a standard template that’s simply instantiated for separate instances of pages. So you add your tag to your template and then you’re off to the races right? Well, sort of.

More often than not, organizations maintain a small subset of pages outside of their CMS that were usually created to accomplish very “one off” kind of objectives (i.e. a popup page for a quick user satisfaction form or external pages created by a third-party vendor). These pages need the Google Analytics tags too and you may find yourself in trouble when you try to setup goals against some of these pages and realize they aren’t being tracked.

Therefore, the best practice here is once you’ve installed your tracking code and you feel pretty confident that you’ve nabbed all pages, ask your IT staff to design a simple script that opens every physical web page produced on the server (not checking against CMS, looking at what’s out there on physical web servers) and looks for your tracking code. Get the script to produce a report of all the pages it didn’t find the code on and then use that information to grab those pesky outliers. My bet is that you’ll be surprised how many pages you may have missed.

Step 6: Validate your data (Top | Table of Contents)

Although by now I’m sure you’re ready to tell me to buzz off so you can start digging into your data, you should really take the time to run your profiles for a time period and get comfortable with what you see. Make sure there aren’t any unexplained questions in your mind and if there are then get answers to them. If you don’t buy the data you’re seeing then it’s doubtful you’re going to sell it to anyone else in your organization.

Step 7: Celebrate good times, come on (Top | Table of Contents)

You’re done! Sure it’s been a lot of hard work but isn’t it worth it? Now you can live with the satisfaction that your analytics requirements are met…at least until next month.