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.