Measuring Success

[This article is part of a series entitled: GA Implementation ABCs]

In Part I of this series, I discussed the importance of simply getting the data in. Part II concerned keeping the data clean by using filters. In this third install I discuss defining goals - the building blocks for your Key Performance Indicators (KPIs). Remember this is all before tackling the much wider (and also more complex) issues of mapping your stakeholders, building your KPIs or assessing your business needs from your web site.

The importance of Goals in web analytics

After collecting and cleansing your initial visitor data from your GA reports (Parts I and II of this series), you then establish your benchmarks. Assuming there are no horror stories from viewing your initial traffic volume, consider your web site goals. A goal is quite simply the purpose of your web site, which in theory should be easy for you to define. For example, what do you wish a visitor to achieve once on your web site? An eCommerce transaction is an obvious goal, but that is also very black and white. If a visitor does not convert - can you measure how close they came?

Often for non-eCommerce web sites, I find owners and managers struggle to define the purpose of their web site. “We built a site because our competitors have one” is a common response, as well as “because IT wanted one”, “because my nephew wanted to build one”, “because our creative agency gave us one”. However, non-eCommerce sites can and should have compelling goals. If not, then just putting irrelevant content that becomes stale and out of date when your nephew/creative agency/IT department move on, will actually damage your brand.

Whether you are eCommerce enabled or not, any engagement with your visitors i.e. the building of a relationship, can be considered as a goal. Example goals include:

• adding an item to the shopping cart
• subscription sign-up
• a brochure request
• a completed enquiry form
• reading a blog article
• adding/editing/deleting a forum or blog post
• viewing a particular page e.g. Special Offers
• viewing particular page path e.g. pages A-E-F-D
• clicking on an ad/external link
• reading more than X pages
• spending more than Y minutes on your site
• clicking a mailto: link

To learn about configuring goals in Google Analytics, visit the GA Help Center.

With goals in place you can start to benchmark yourself that sets the foundations for discussing KPIs with your stakeholders. Bear in mind that a goal doesn’t always have to increase for it to be a good thing. Sometimes, negative goals indicate an improved visitor experience - for example less support tickets submitted, less complaints logged etc. would be considered an improvement.

A question I would like to get feedback on - how often have you redefined goals? Once setup do they get set in concrete or are they constantly evolving and which sectors are more proactive at this? Please share you feedback by posting a comment.

Recently, the perception of ABCE’s role for the web analytics industry appears to have become blurred. Hence I wanted to post some comments here - these were also posted on the Web Analytics Association’s forum last month.

ABC ELECTRONIC is the trading name of Electronic Media Audits Ltd. To briefly summarise from their web site:

ABC ELECTRONIC is the industry owned, not-for-profit organisation that works with and for media owners, advertisers and media buyers to help them gain confidence in the data they use. The UK company performs many services but essentially conducts independent audits of client’s digital data to ensure it complies with agreed industry standards - as defined by JICWEBS (The Joint Industry Committee for Web Standards in the UK and Ireland).

To clarify, an ABCE web audit is NOT an accuracy report - it is a verification report for web site owners. Simplified that means ABCE auditors verify the pageview and visitor numbers reported in a client’s analytics tool as matching (to within error bars) their manual counts of the data. ABCE’s methodology is to seed the data with ‘known’ visitor activity, count/verify these in the raw logs of the analytics provider, multiply up to obtain the total count, then compare with that reported by the vendor. The final report is private and delivered to the client.

That process is entirely different to ascertaining web analytics accuracy - something that is very difficult to determine by the nature of current data collection methods (cookies). For example, if you mis-configured your web analytics tool - say you forgot to track pdf downloads, your CMS system screwed up and started over-writing tags, or a large proportion of your web site is missing tags, an ABCE audit would not identify this - it simply verifies that what is in the raw logfile matches what is reported in your tool.

So an ABCE audit is important for publishers - web sites that sell advertising space need to verify their numbers to have credibility with their advertisers (trust in their rate card), but beyond that an ABCE audit is less significant to web site owners.

However, would having a setup/configuration audit for web analytics tools be of benefit? For example, such an audit could verify if your particular tool is configured correctly and capturing the complete picture. Please leave your thoughts via a comment - I always respond!

My standard word of caution - This is a tech tip and requires you to have a knowledge of html and javascript to implement and use it…

[Update 03-Nov-2008: This hack is for the legacy urchin.js tracking code.
Always refer to the Scripts & Downloads section for the latest version.]

Following on from my previous post Tracking banners and other outgoing links automatically, this GA hack allows you to track downloads automatically. As you may know, tracking download files such as PDF, EXE, DOC and XLS can be achieved quite easily with the modification of the link to include an urchinTracker call to log a virtual pageview. However, as for tracking outgoing links, manually modifying each download link becomes inefficient when there are large numbers of ever changing files to track. You can overcome this by applying the JavaScript code below:

<script type="text/JavaScript">
// Only links written to the page (already in the DOM) will be tagged
// Script can be called multiple times

function addExtDocEvents() {
var as = document.getElementsByTagName("a");
var extDoc = [".doc",".xls",".exe",".zip",".pdf",".js"];
// add further document types as required

for(var i=0; i<as.length; i++) {
	var tmp = as[i].getAttribute("onclick");

// Tracking electronic documents - doc, xls, pdf, exe, zip
if (tmp != null &#038;&#038; tmp.indexOf('urchinTracker') > -1) continue;
for (var j=0; j<extDoc.length; j++) {
if (as[i].href.indexOf(extTrack[0]) != -1 &#038;&#038;
as[i].href.indexOf(extDoc[j]) != -1) {
		var splitResult = as[i].href.split(extTrack[0]);
		as[i].setAttribute("onclick",((tmp != null) ? tmp : "") +
			"urchinTracker('/downloads" +splitResult[1]+ "');");
		break;
	}
}
}
}
addExtDocEvents()
</script>

The script works by looking for links within the browser’s Document Object Model (DOM) that match the file extension given in the variable array extDoc. If so it is modified to include the urchinTracker call. By this method, all file downloads will be reported as:

/downloads/the-url-that-is-clicked-on

Where the-url-that-is-on clicked on is minus ‘http://’. You can modify the JavaScript to adjust the path as required,

IMPORTANT: As for the Tracking of banners and other outgoing links, the position of this code within your page is important. This must placed after your call to the GATC. Alternatively you can place the addExtDocEvents() call in an onLoad event handler and host the JavaScript in a separate file. As an example I show this below, assuming the javascript is hosted in a file called trackExternal.js, as follows:

<script src="http://www.google-analytics.com/urchin.js" type="text/JavaScript">
</script>
<script src="/trackExternal.js" type="text/JavaScript"></script>
<script type="text/JavaScript">
	_uacct = "UA-XXXXX-Y";
	urchinTracker();
</script>

<body onLoad=”addExtDocEvents()”>
	...your remaining web page content...
</body>

A note on performance: Each time your page loads, this script will go through all links referenced on the page to see if it is for a download. Clearly the more links on your page, the harder the script must work. As long as the number of links on each page number in the hundreds and not thousands, performance should not be a problem. Also, pages with a large number of links, it is possible that visitors will click on a download link before the script has modified it. The result is that click through will not be tracked by Google Analytics.

***Update***
I have now combined this hack for downloads with the Tracking of banners and other outgoing links - automatically into a single file that is available in the Scripts & Downloads section.

Did you find this tip useful? All tips are being grouped under the category GA Hacks. Please provide your feedback with a comment.

[This article is part of a series entitled: GA Implementation ABCs]

During my first post of this series What is the 1st thing to do when considering a web analytics implementation?, I discussed how important simply getting initial data in was - before tackling the much wider (and also more complex) issues of mapping your stakeholders, building your KPIs or assessing your business needs from your web site. Essentially, my view is: get an initial feel for the project - get the data in and that means tag all your site pages (including the tracking of non-standard pages such as PDFs, EXE, ZIP etc).

With data coming in, the 2nd thing to consider is adding filters. Filters in Google Analytics have many purposes such as segmentation and report augmentation. In this post I focus on their role in data cleansing. Keeping the data ‘clean’ means removing visits that are not wanted or are not valid visits. Essentially considering these as improving the signal-to-noise ratio of your data. Having clear signals means you don’t waste time analysing what could be random events (noise) on your web site.

Example cleansing filters include:

1. Your own access to your web site
   - this can be a significant volume of non-converting traffic if your employees set their browser opening page to be the company web site. Such visits will over inflate your visitor and pageview counts and decrease your conversion rates.
2. Your web developers/designers updating content
   - these can be significant in volume but more importantly, web developers are likely to update conversion pages, triggering goals and over inflating your conversion rate metrics.
3. Data contamination
   - other web sites copying your GATC either deliberately of accidentally which results in meaningless data being mixed with your web site visit data.

All 3 of these should be removed by adding 3 filters to your GA configuration as follows:

Filter 1: removing yourself from the reports

Excluding known visitors is very straight forward. If visitors connect to the Internet via a fixed IP address, you simply select the predefined filter ‘Exclude All Traffic from an IP Address’ from the Filter Manager as shown:

Excluding visits from employees, your search marking agency or any known third party, such as your web developers, is an important step when first creating your profiles. These visitors generate a relatively high number of pageviews in areas that will greatly impact key metrics - such as your conversion rates. For example, employees with their browser home page set to the company web site will show in your reports as retuning visitor every time they open their browser - and most likely a one-page visitor. Remember the GATC deliberately breaks through any caching so it’s important to exclude employees from visits from potential customers.

Similarly web developers heavily test checkout systems for troubleshooting purposes. These will also trigger GATC page requests and most likely these will be for your goal conversion pages. You should therefore remove all such visits from your reports.

Filter 2: removing your designers/developers from the reports

This simply an extension of Filter 1, using the ip address of your agency in place of your own office. But what if ip addresses change each time they log in? I will discuss this scenario in a later post. However, for the vast majority of business broadband lines, fixed ip addresses are used, so you should be ok.

Filter 3: removing any contaminated data
This filter is to ensure that your data, and only your data, is collected into your Google Analytics profile. For example, it is possible for another web site owner to copy your GATC onto their own pages - therefore contaminating your data with their own web site traffic. The simple include filter shown below applied to your Google Analytics profile will ensure only traffic to the mysite.com domain is reported on.

Of course it may be desirable to collect data from multiple web sites into one profile. In that case, add the multiple domains in the Filter Pattern separated with a | character, for example:

Filter Patern: mysite\\.com|yoursite\\.com

Important tip:
It is important to note that when a filter is created within Google Analytics, it’s immediately applied to new data coming into your account. New filters will not affect historical data, and it is not possible to reprocess your old data through the new filter. Therefore, always keep “raw” data intact - that is, keep your original web site profile and apply new filters to a duplicate profile in your account.

How have you approached the signal-to-noise ratio problem? The vast majority of Google Analytics installations I come across have no filters applied, why is this? Please add your thoughts with a comment.

My standard word of caution - This is a tech tip and requires you to have a knowledge of html and javascript to implement and use it…

[Update 03-Nov-2008: This hack is for the legacy urchin.js tracking code.
For the ga.js version read: Customising the list of search engines in Google Analytics.]

Google Analytics shows which search engine your visitors/customers have used in the Traffic Sources > Search Engines report. To view the list of all the search engines that Google Analytics currently identifies by default, simply load into your browser http://www.google-analytics.com/urchin.js. In this file you will see the section commented as:

//-- Auto/Organic Sources and Keywords

This section is where the organic search engines are defined that once captured by the Google Analytics Tracking Code (GATC) will be reported in the reports interface. By looking at this section, you will notice that the current number of organic search engines detected by default is 28 i.e. _uOsr[0] to _uOsr[27].

Of course Google recognises that there are a great deal more search engines in the world – language and regional specific as well as niche search engines such as price comparison and vertical portals. It is therefore possible to modify and append the array of recognised search engines and there are two methods.

1. The standard method of adding additional search engines to GA
Add the following code to your page GATC:

_uOsr[28]="search_engine_name";
_uOkw[28]="query_variable"; 

The value for _uOsr is the domain name (sub-domain or part of the domain to match) of the search engine and the value for _uOkw is the query variable which stores the keyword (replace search_engine_name and query_variable in the example above).

The number in square brackets should start at 28, or one more than what ever the last number is if the number has been updated, and increase in increments of 1 for each additional search engine added (29, 30, 31, etc).

For example, if someone searched for “motorcycle” and the search result URL is:
http://search.bbc.co.uk/cgi-bin/search/results.pl?q=motorcycle

you would add the following line to your tracking code on your pages:

<script src="http://www.google-analytics.com/urchin.js" type="text/JavaScript"></script>
<script type="text/JavaScript">
     _uacct = "UA-xxxx-x";
     _uOsr[28]="BBC"; _uOkw[28]="q";
     urchinTracker();
</script> 

Another example where this technique is useful is to add price comparison engines as a regular search engine:

<script type="text/JavaScript">
     _uacct = "UA-xxxx-x";
     _uOsr[29]="Kelkoo"; _uOkw[29]="siteSearchQuery";
     urchinTracker();
</script> 

By this method, Kelkoo would be listed in the Search Engine Marketing report along side other search engines. That is useful in itself, but what provides more insight is the corresponding Kelkoo search terms used by visitors will also be listed in the Keywords report. Without this little hack, Kelkoo would simply be listed as a standard referrer and no search terms would be logged.

Apart from adding additional search engines to the existing list provided by Google Analytics, you could also use this method to create more regional ones of the main players. For example, if you are based in the UK, being able to differentiate google.co.uk from google.com may be of importance. In which case you would add the following to your GATC of each page:

<script type="text/JavaScript">
     _uacct = "UA-xxxx-x";
     _uOsr[0]="google.co.uk"; _uOkw[0]="q";
     urchinTracker();
</script>

Note: When adding regional variations to the search engine list, the order or the _uOsr and _uOkw arrays become important. So google.co.uk must be listed before the “catch-all” match of google. That of course requires the re-numbering of the search engine list array.

2. A more robust method…
An example of a more complete and robust method of adding additional search engines to the list is shown at: www.advanced-web-metrics.com/scripts/custom_se.js. In this case, the list of custom/localised search engines is kept in a separate JavaScript file and referenced in each page within the GATC as follows:

<script src="http://www.google-analytics.com/urchin.js" type="text/JavaScript"></script>
<script src="http://www.mysite.com/custom_se.js" type="text/JavaScript"></script>
// custom_se.js must be called after urchin.js

<script type="text/JavaScript">
	_uacct = "UA-xxxx-x";
	urchinTracker();
</script>

This script overwrites the default search engine array of Google Analytics and uses the array length (_uOsr.length) to increment its index so that re-numbering is not required when adding new entries. A sample of the code is provided below:

var _uOsr=new Array();
var _uOkw=new Array();

// Google EMEA Domains
_uOsr[_uOsr.length]="google.co.uk";	_uOkw[_uOsr.length]="q";
_uOsr[_uOsr.length]="google.es";	_uOkw[_uOsr.length]="q";
_uOsr[_uOsr.length]="google.pt";	_uOkw[_uOsr.length]="q";
_uOsr[_uOsr.length]="google.it";	_uOkw[_uOsr.length]="q";

… etc.

So by this method, you simply maintain a separate file for your list of search engines and you don’t need to worry about renumbering each time you update/append. Feel free to copy and use the one listed: http://www.advanced-web-metrics.com/scripts/custom_se.js.

Many thanks for the guys at GA-Experts.co.uk for the help with building and testing the custom_se.js file.

Did you find this tip useful? All tips are being grouped under the category GA Hacks. Please provide your feedback with a comment.