Lies, Damned Lies...

JavaScript advice

There's a good post over on Avinash's blog with 9 tips for getting JavaScript tagging right on your website. There's not much for me to add except to say that you should click the link above and read his advice; but I do have one thing to add about redirects (point 7 in Avinash's post).

If you're using redirects in your site, you have two options:

1. Ignore (don't capture) the redirect
2. Capture the redirect as a 'valid' page impression

When might you want to choose one or other of these options? Well, you would choose no. 1 when you're using redirects internally, for example (as in Avinash's example) if you're using an ad platform to serve internal ads - the ad platform usually demands you redirect the click so that you get measurement within the ad platform (this is what we're doing on microsoft.com). In your main web analytics data stream, you don't want loads of extra 'pages' popping up that are odd URL formats and are going to throw your numbers out. So in this case, use a server-side redirect (e.g. 301) which will automatically re-point the browser without an actual page-load happening on the client.

You want to capture the redirect happening in the instance when you're tracking outbound (off-site) clicks - for example to affiliates. In this case you want to use a redirect which actually serves a real page and then (probably) uses JavaScript to redirect the browser. The advantage with this method is that you capture the click before the user leaves the site and is lost for ever. The only problem with this is that the outbound redirect page looks like a real page impression, which isn't really true. If you were trying to get your numbers audited you'd get spanked.

A refinement of method 2 is to use a web analytics tool which you can redirect the outbound click through - that is, then vendor provides a mechanism where you can direct users to a URL on their domain which then redirects to the URL that you really want (which may or may not be one of yours). This is how the ad-serving companies capture click information. I think Omniture does this, and I know some others (e.g. NedStat's SiteStat product) do too. In this instance the web analytics tool handles (and logs) the redirect; savvy tools can then report this information separately without it polluting the main page impression counts.

The only other thing to add is that the tool that Avinash references that Omniture uses to track tag coverage and deployment is (I believe) Maxamine. The folks at Maxamine are great; if you're running tag-based data collection over a large ad complex site, you should give them a call.

Open Source Web Analytics

News reaches me of the launch of the first open-source web analytics tool - Breadboard BI Web Analytics, from the folks at Breadboard BI.

When I was at WebAbacus, we had some quite lengthy discussions as to whether we should make the WebAbacus platform available as open source software. In fact Dan Drury even wrote a paper for us on it. In the end we decided not to (for the time being, at least). Here are some of the pros and cons we came up with:

Pros

• Access to a much wider developer base than our (very small) in house team, to help drive the technology forward
• Cool stuff that we wouldn't have thought about ourselves may get developed
• We could focus on value-add services & packaging (a la Red Hat) around the core platform rather than spending time developing the core data mart
• It's cool!

Cons

• Which part of the product would be OSS? The whole thing? Our (proprietary) database? The reporting interface?
• Running an OSS project would require more investment in the short term do deliver a longer-term benefit
• We currently enjoy quite nice margins on our core software, and OSS would remove that
• Not sure about the level of interest - would we just be giving away our IP and still having to do all the development ourselves?

One of the arguments employed in favour of OSS'ing WebAbacus was that the web analytics market is now a commodity market, and so the value has passed up the chain to the services on top. I don't agree with this view - I think there's still a lot of innovation to be delivered in the software tools themselves, and the range of interpretations and spins on what exactly web analytics is (compared with the much more well understood notion of what a database is, or what an operating system is) means that the opportunity to differentiate through software functionality will remain for some time to come. So that means that the web analytics vendors will be keeping their IP pretty close to their chests for the foreseeable future.

I'm not sure that, with the availability of Google Analytics for free, that an OSS web analytics tool will be that appealing on the basis of its cost (or lack of it) alone. But if Breadboard BI can create a community around it which creates cool reporting plug-ins (as per my post about Mint), it could gain some traction.

ActiveX miseries

It's just come to my attention (on account of installing the latest security patches for Windows from Microsoft) that a small but profound change has been made to the way Internet Explorer handles ActiveX plugins (such as Flash, PDF, Quicktime and Java).

Owing to a patent dispute with a no-name company called Eolas, who licensed a patent for embedded applications from the University of California in 1994, Microsoft has changed IE so that, by default, users are asked to click on any ActiveX control to activate it before they can interact with it (see Volkswagen's Phaeton site for an example of this in action - at least until they change it). The issue was brought to my attention by my wife, who runs an online boutique that has a Flash element on its home page.

There's much comment on the web about the Redmond Goliath being brought low by a small, doughty (not to mention litigious) David, plus a lot of grumbling about Microsoft bundling the patch with its April round of Windows security updates, but relatively little about how to get around the issue.

It turns out that doing this is pretty easy - rather than referencing the plug-in directly in the HTML, as in the example below:

<EMBED src="hp_anim.swf" menu="false" quality=high bgcolor=#FFFFFF  WIDTH="532" HEIGHT="355" NAME="hp_anim" ALIGN="" TYPE="application/x-shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>

you just have to move the HTML into a separate file and write it out using JavaScript document.write commands:

<script language="JavaScript" type="text/javascript" src="flash.js"></script>

and, in flash.js:

document.write('<EMBED src="hp_anim.swf" menu="false" quality=high bgcolor=#FFFFFF  WIDTH="532" HEIGHT="355" NAME="hp_anim" ALIGN="" TYPE="application/x-shockwave-flash" PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">');
document.write('</EMBED>');

Pretty simple, really, and for me, that's what rankles. If something is so easy to get round, why is it necessary to make everybody implement the workaround? Why not just agree licencing for the patent and let everybody get on with their work?

If you want to read more about the techniques to get round this latest piece of litigious nonsense, there's a good article on the Microsoft website about it.