Javascript Voodoo: Tracking Downloads, Part 2
This is part 2 of a three part series: [ Part 1 | Part 3 ]
For a few weeks we chugged along happily with Google Analytics (still supplemented with pphlogger because Analytics only updates every 24 hours). When we started working with a search engine optimization company (to help our search engine results & ad effectiveness) they asked we use yet another stats tracking package. This is where things began to get complicated.
Unlike Google Analytics, their tracker has no affordance for recording clicks that do not go to web pages (i.e., clicks to actually begin the download). However, the most important statistic we want to track is how many (and which) site visitors download the application.
A common approach to this problem is to have the “download” link land on a web page that automatically kicks off the download when the page loads. This is less reliable than linking directly to the file, but it gives the javascript bugs a chance to run and register the click to download.
I decided to copy the relatively simple approach used by sites like SourceForge. They use an invisible HTML form, the “action” of which is the URL of the file to download. A bit of javascript waits N seconds and then “submits” the form for you (using setTimeout() and submit()), causing the browser to fetch the actual file for download. A link to the download is displayed in case the javascript fails to start the download. For users without javascript, there is alternative “noscript” text with a link. A simplified version of the SourceForge approach looks like:
<form method="post" action="/filename.exe" name="dlform">
<script>
<!--
document.write('Your download should begin shortly. If it does not, try <a href="http://example.com/file.exe" onclick="javascript:document.dlform.submit();return false">http://example.com/file.exe</a> ');
window.setTimeout('document.dlform.submit()', 5000);
// -->
</script>
<noscript>
<input type="submit" value="Click Here To Start Your Download"><br />or download from http://example.com/file.exe
</noscript>
</form>
This worked well enough, but we discovered two significant drawbacks: one with the download delay and the other with recent versions of Internet Explorer.
We took the opportunity of a download “landing page” to instruct the user on how to install Pando. This involved screenshots which, on slow connections, take a few seconds to download. To give the screenshots adequate time to load, we set our download delay to eight seconds. This is a painfully long time to wait for a download to begin; and it still didn’t ensure the images would fully load before the download started, resulting in half-loaded images displayed on the page. This was the first problem.
The second, harder problem: certain versions of IE6 and IE7 block the javascript-initiated download and instead display a yellow bar at the top of the page explaining that the download was blocked. Users could still download the file by either explicitly “allowing” the download to start or by just clicking the link. This was pretty clunky and confusing for many users.
I’ll explain how I solved both of these problems in part 3.
