Google Analytics is a great tool for tracking users on your site, and it's incredibly easy to set up the basic features. You just bung a bit of JavaScript on every page in your site which, if your site is sensibly designed, should only mean editing one file. You then get access to a plethora of amazing data about what your users are doing.
The more advanced features, particularly tracking ecommerce transactions, are a lot harder to implement and test other than on the live site. The help is somewhat minimal and hidden on a different page, without being stated quite explicitly, is the fact that it will drop any transactions coming from a domain other than the one the account lives in.
If it's not a subdomain of the main domain, you have to do some JavaScript link shenanigans to get GA to recognise it. This wouldn't be an uncommon problem for people using third-party shopping carts, and the solution there is quite well described.
What's less well described is how the hell you can test this thing. For example, our test server sites inside the domain of our parent company, which bears no resemblance to our live domain. Fortunately, we'd already configured our test web servers to respond to the live domain when we were testing for going live.
So what you do is edit the
c:\WINDOWS\system32\drivers\etc\hosts file in Windows XP, or
/etc/hosts in Unix-like systems. Put in a line like this:
192.168.1.1 www.mycompany.com.au
This overrides the name server lookup for "www.mycompany.com.au" to "192.168.1.1" and, providing the web server at that IP address has been configured to serve for that domain, you'll see your test site as if it's live and, crucially, that's what the cookie management and JavaScript in your browser will think too.
You might be behind a firewall that requires use of a proxy. Hopefully you can get to your test web server directly, otherwise you're kinda screwed. You can just turn off proxy use for the domains you're testing, leaving it in place for everything else. This is crucial since you still need to be able to get to the Google Analytics server to send the data.
Another wrinkle might be if you're using the GA IP filtering to filter out users from your own network. We do this to reduce the false data from our own staff on the site, but that means it's hard to test things. For this purpose I use a FoxyProxy rule to push hits to the analytics system via an ssh tunnel that pushes the data through my own proxy server sitting in the US. That way the data comes from a different IP range than the ones that are filtered out.
As you can see, there's quite a bit to think about when trying to test this stuff. It's all exacerbated by the fact that processing of the data occurs overnight, rather than anything close to real time. It means every time you make a change, you have to wait until the next day to see if it worked. Then when it didn't, you've got no feedback as to why, so you try again and wait another day.
Over the Xmas break, if I get the time and energy, I'm thinking of making a dropin test replacement to the Google Analytics JavaScript code. This would give you a real-time view of the data hitting the analytics server, with helpful hints on diagnosing why it's not working. We'll see if I get the time.
The other Firefox extension that I've found invaluable for testing has been Live HTTP Headers, for watching what's going to the remote servers. This handy tool is useful and quick for doing the URL decoding so it's more readable.