Monday 26 October 2009

Easier Website Optimiser tagging

In my previous posts I introduced the idea of externalised javascript libraries to abstract over Google Analytics page tracking and ecommerce transaction tracking.

This idea also transfers nicely into Google Website Optimiser where you can experience some interesting scripts on your first visit!

These articles assume you are at least familiar with the concept of multivariate testing, javascript, Google Analytics tracking and the Live HTTP Headers plugin in FireFox.

As with the last posts - use these scripts at your own risk. Don't link to the script libraries directly, copy and tune to your own needs!

A Simple MV Test made simpler

A normal website optimiser multivariate (mv) test requires a control script, tracking script and goal script to be placed on your pages. The control script decides which experiment variation to show. The tracking script records which test variation was shown and the goal script records the experiment conversion.

Two cookies are also used in combination with the standard GA cookies.

Standard cookies
etc (there are quite a few!)

Website Optimiser cookies

The nature of the standard cookies is not the subject of this article. In summary, the utmx and utmxx cookies are used to remember which test variation a users sees.

If you inspect the cookies you have in your browser right now you probably won't have any utmx cookies for the domain. If you go to the example page for this article and recheck your cookies, you should now see a utmx and utmxx cookie for the domain.

You've just been tested!

You will have equal chances of seeing a very simple page with one of three different pieces of text and two links:

Original page
Test 1
Test 2

(and two links to goal and purchase)

Delete the utmx and utmxx cookies and reload the page to see different variations. This is standard Website Optimiser type development/testing/debugging.

You should also inspect the HTTP Headers output. Notice the request for siteopt.js? Notice the utmx and utmxx values? If you don't see these - it's broken. Simple. Check for javascript errors.

The source of the html page will reveal the how the test is rendered. As with the page tracking example we are including Moneyspyder javascript libraries:

<script src="/javascripts/ms_ga.js" type="text/javascript"></script>
<script src="/javascripts/ms_wo.js" type="text/javascript"></script>

ms_wo.js gives us three methods to use:


All three methods take the experiment id as a parameter 'k'. You can get this value from the supplied script snippets when you set up your test.

The control script normally sits at the top of your content - ms_wo_ctrl replaces this script and so, sits in the same place. Feed it the test id to setup the test. Directly beneath the ms_wo_ctrl script, call the ms_wo_tracking method. Feed it the test id and Website Optimiser ua account value to track the test view.

Now, normal test scripting applies for a moment. Wrap the content you are testing with your utmx section and noscript tags as normal. At Moneyspyder, we are considering implementing later versions of this script library with the ability to 'document.write' the utmx sections based on matching dom elements by id or class. We'd be interested to hear your thoughts on this. Less code is better, right?

So, assuming your test is set up you should now have a page that mirrors the format of

Viewing this page and inspecting the HTTP Headers output will reveal the following requests:

ga.js (Google analytics script library from Google)
siteopt.js (Website Optimiser script library from Google)
utm.gif requests

The request to siteopt.js will pass in values of your utmx and utmxx cookies if you have them so that you can see the same test variation you saw last time or, if you don't have the cookies, your test variation and utmx values will be set.

Having displayed the test variation content, your page will track the test view with a utm.gif request to the Website Optimiser UA account and the utmp value of the test id follwed by the string 'test':


The goal page follows a very similar format but just calls ms_wo_goal in the same way as ms_wo_tracking with the UA and k values:


And so the page is tracked as you will see by inspecting the HTTP Headers output for the utmp and utmac values.

Wrap up
So, we have seen how the javascript supplied by Google for page tracking, transaction tracking and website optimiser testing is totally 100% fit for purpose and great to use. But with a little thought we can afford ourselves a little more power, maintainability and ease of use. We have cleaner pages and can handle change a little better.

If these articles help you implement good quality Google product integrations then we have a success. If you want to take this work further for your own sites, great but remember it's good to share! If you want to challenge this work, feel free to leave comments or drop us a line at - we'd be happy to exchange ideas!

Google analytics: easier transaction tracking

In my previous posts I introduced the idea of externalised javascript libraries to abstract over Google Analytics page tracking.

This idea also transfers nicely into Google Analytics transaction tracking where, it seems, most people seem to come unstuck.

We'll try and get you stuck back together!

These articles assume you are at least familiar with the concept of javascript, Google Analytics tracking and the Live HTTP Headers plugin in FireFox.

As with the last posts - use these scripts at your own risk. Don't link to the script libraries directly, copy and tune to your own needs!

Simple transaction tracking made simpler

Take a peek at the transaction tracking example

Thanks for buying stuff! No, seriously, even though the page looks as unspectacular as the Page Tracking Example you have actually registered a (fake) transaction with Google Analytics for a t-shirt and an indoor frisbee.

Take a look at the page source. We're using ms_ga.js again. The method we are interested here is ms_ga_trans.

Notice the source does not track a page view! That'll be taken care of for us by the method.

ms_ga_trans takes three parameters: an array of UA accounts, a URL and a data structure representing the transaction.

The array of UA accounts enables us to track the transaction in any number of Google Analytics accounts. The URL is nullable so we can track the transaction page as a specific URI or just use the default. The transaction data structure mirrors the structure set out in the Google Analytics Transaction tracking documentation.

A transaction requires:

an order id
an affiliation
a shipping value
a tax value
a total value
a country, city and state

Clearly an order also requires one or more order items. Each item consists of:

the order id
a sku code
a name
optionally, a category (very useful)
a unit price (how much for one?!)
a quantity

Now, I'll stress this point about numerical values here. Do not include currency symbols. It is really important that when specifying a price or tax value or shipping value that you specify the value as a number to two decimal places. That is all. Not:






or similar.

Just go for the simplest option which is (for example),


and stick it in quotes - everything is a string. Simple. No fuss. No complexity. If something is free, list it as 0. Don't miss out fields. You'll miss the wrong field and the script will fall over. With abstracted/externalised scripts and method calls you can build in more error handling and checking - handy!

So, inside the guts os ms_ga_trans we see a similar format to ms_ga_pagetrack where we iterate through the array of UA account values to track against:

{"order_id": "666666", "shipping": "5.95", "web": "", "tax": "1.79", "total": "21.74", "country": "UK", "items": [
{"price": "6.00", "category": null, "name": "t-shirt", "sku": "t-1", "quantity": 1},
{"price": "8.00", "category": "home", "name": "indoor frisbee", "sku": "f-1", "quantity": 1}

We see that the page view is tracked here to - hence, we do not track the page separately. It is important to track the page view before recording the transaction.

The transaction is then added using the ga.js addTrans method. Each item in the transaction is then added and finally the transaction is tracked.

So, there isn't that much that is simplified here other than the order in which the steps happen and the opportunity to build in more error checking and handling. If you've got these basics right - well done. You want to know the transaction has registered though, right? Real time? Right, thought so.

Reload the page with our new best friend Live HTTP Headers looking over our shoulder so we can review what happened under the hood.

First of all, no surprises, ga.js loaded.

Then we track the pageview with utm.gif

Take note of the third section in the HTTP Headers output - there is a new utm value called utmtid and it has our transaction id, '666666'. Cool - transaction being tracked with expected values! Okay, so we can see the total in utmtto, the tax in utmtx, shipping in utmtsp etc.

Each follwing section details each order item. utmut=item, utmipn for the item name, utmiqt for the quantity. Real self explanatroy stuff when you know where to look and what to look for.

Never have a transaction fail to track ever again!

Thats should do for this article - next time we Optimiser our website with Google Website Optimiser - but simpler. ;-)

Google Analytics: easier page tracking

Google Analytics is great. It's free and super powerful but... there is always a but!

Sometimes the tracking tags can be tough to understand. They can be tricky to implement if your CMS doesn't directly support them. Debugging can be 'gnarly'. Mix in Google Website Optimiser tests and you might end up biting of more than you can chew.

Moneyspyder has written two small skeletal javascript libraries that you can copy and use to make Google Analytics page tracking, transaction tracking and Website Optimiser implementation a bit easier.

We're trying to lower the bar to entry. We're not saying YOU MUST DO IT THIS WAY but we think this is one good way to start doing simple tracking and testing and we want to share some techniques with you. We're not saying the existing Google code is wrong or bad but if you want slightly cleaner pages and to get some extra value by abstracting out javascript code then this might be useful and it might even make managing your site easier.

The next few articles will cover smarter:

Page Tracking
Transaction Tracking
Website Optimiser tagging
All three together

Feel free to take a copy of the scripts used in this article. Don't link to them - they will change over time and your tracking might break. Moneyspyder accepts no responsibility for harm to or loss of data if these scripts are used 'as is' or linked directly from the Moneyspyder server. You have been warned - so now let's inspire!

Simple smarter page tracking

Take a look at our first page - Page tracking example

Spectacular it is least at face value. View the source to see the interesting bits.

1. In the
section you will notice a javascript include

<script src="/javascripts/ms_ga.js" type="text/javascript"></script>

Take a look at the ms_ga.js source. The section that we are interested in is:



2. In the html, notice we are making two calls to ms_ga_pagetrack
The parameters that are expected are:

  • An array of one or more strings - 'UA-XXXXXXX-X'

  • An optional string to use as the page URI

The first parameter as an array enables you to track pageviews in multiple accounts without having to repeat the tracking code. The Google tracking method
can take a parameter to replace the tracked page url.


Additionally, if the Google ga.js javascript (notice the first two lines in ms_ga.js?) changes, you only change the ms_ga.js file and all your site pages remain untouched. This extra 'abstraction' layer has been helpful to Moneyspyder in the past.

Debugging Google Analytics page tracking can be a lengthy and frustrating process:

  • Try a tracking script

  • Hit a page (along with everyone else who uses your site

  • See if the page view appears in the GA reports

  • Fail? Sigh...Rinse and repeat

We prefer to do this in real time. Yup, results while you wait. Go and get the Live HTTP Headers Firefox plugin. Start it up (Tools menu in FireFox). Go to the 'Config' tab and click the 'filter URLs with regexp' checkbox. Then put this string in the corresponding text box:

So now the only values you will see in the HTTP headers output will be related to Google Analytics.

Reload The HTTP Headers output will contain 4 sections of similar format. The first section is the page including ga.js from Google:

GET /ga.js HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20090824 Firefox/3.5.3 GTB5 (.NET CLR 3.5.30729)
Accept: */*
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Tue, 13 Oct 2009 18:39:01 GMT
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Last-Modified: Tue, 13 Oct 2009 18:39:01 GMT
Date: Mon, 26 Oct 2009 12:14:29 GMT
Vary: Accept-Encoding
Cache-Control: max-age=604800, public
Server: Golfe
X-XSS-Protection: 0

This output tells me first of all, the nature of the request being made - we're asking for ga.js from Google. There is some http header info about the browser I am using, an HTTP response code and not a lot else of anything of interest.
The next section gets more interesting:

This request won't appear in the HTML source of the page. This is the output from _trackPageview. The data appended to this gif request is how Google Analytics gets the data into Google Analytics. Some interesting values here:


utmp is the page path - remember we set this using the url parameter in our own method call? This is where you see the page path that is being sent to GA. utmac is the GA account being used for reporting. We set two accounts to be used - 'ua-1' and 'UA-7862117-1'.

So, the first request we saw in the HTTP Headers output was the request for ga.js:

Second, we reported the pageview using /skeleton/tracking and ua-1:

Third, we reported the pageview using /skeleton/tracking and UA-7862117-1:

Fourth, we reported the pageview using /ms_page_tracking and ua-1:

There are quite a few name value pairs appended to the utm.gif. More than should be discussed right now. We'll use this same debugging technique for transactions and website optimiser tracking and tagging.

Next, we'll do some testing!

Tuesday 20 October 2009

new, enterprise class Google Analytics Features

We're really excited at Moneyspyder about the release today of the new features on Google Analytics.

In summary:

  • More goals

  • Intelligence (!)

  • Custom Alerts

  • Table filtering

  • Unique visitor metrics

  • Sharing custom segments and reports between profiles

  • Multiple custom variables

If this seems like Greek - we have to talk. Call us and we'll make sure you get value from Google Analytics.

More here from the Google Analytics blog:

Friday 16 October 2009

Moneyspyder at the Google Global GAAC Summit 2009

Doug Hall, Moneyspyder's CTO is currently 'recovering' from three fantastic, intense, entertaining and revealing days at the 2009 Google GAAC, WOAC Global Summit at Google's Crittenden Lane campus in San Francisco, California.

'Recovering', yes but not in a negative sense. The breadth and depth of subjects covered was breath taking. A summary of the highlights:

Day 1 - WOAC Day

  • Dan Siroker described how his team on Braka Obama's election campaign used data to help win the election

  • Website Optimiser - The current and future of WO and Google's complimentary products. (NDA prevents disclosure at this time)

  • Tim Ash presented his conversion Ninja;s toolbox

  • Cocktails and dinner @ Google

Day 2 - GAAC Day 1

  • The highlight of the day, keynote address by Avinash Kaushik. Blunt, insightful, worrying but overall, truly inspiring

  • The current state of the art of Google Analytics closely followed by what the (very exciting) future holds for GA

  • Fellow GAACs presented case studies for tools and techniques that they have pioneered and enabled them to deliver value to their clients. Moneyspyder will be presenting next year!

Day 3 - GAAC Day 2

  • Google's Chief Economist, Hal Varian described how Google's fantastic body of data can be married to statistical modelling techniques to provide forecasting mechanisms - utterly mind blowing. The equations were just sublime ;-)

  • Google's Partner Program team described the incredible growth of the GAAC and WOAC program. Moneyspyder has long been pat of these programs and can attest to the value that Google bring to their partners. A truly awesome effort and a well deserved 'honorary GAAC' award for Alan Wrafter!

  • The GA API subject is a crucial one. A presentation and a breakout session yielded magnificent value. The open forum breakout session was a refreshing change to the powerpoint/QA format and a lively discussion ensued.

Now, this summary is deliberately light on detail. In a short while we will be discussing more about the 2009 GAAC summit content on this blog - NDA prevents further detail but the wait will be worth it - F.A.C.T.

Watch this space!