Good post... bravo for increasing awareness about GA's lesser-known features.
Why does this require asynchronous GA and jQuery in the head?
Asynchronous GA seems like a best practice, but how would that affect the amount of event data you collect?
jQuery in the head would net you a negligible increase in data, and only for particularly heavy sites. No?
I use event tracking across a few sites in varying configurations (sync/head, async/footer, etc.) and would think anyone using GA and jQuery can benefit from this advice without changing their existing structure.
Why does this require asynchronous GA and jQuery in the head?
When a browser hits a script tag it waits (blocks) while it downloads the script and evaluates it. As such, including a bigger library like jQuery in the <head> will slow your perceived page load time significantly, so moving such includes to just before </body> is often a best practice. This way the browser can go ahead and render the page, and add the Javascript once its done.
However, this introduces the possibility that the user will see and click a link before the Javascript (on which the event tracking depends) has loaded. In this case Google Analytics will not track the event.
So by adding the Javascript includes to <head> he's forcing the browser to have Google Analytics running before the page is rendered, ensuring that this can't happen (at the expense of page load time).
I would not recommend taking this advice. As Travis pointed out, the event binding can easily be written without jQuery, giving the best of both worlds.
However, its a good article and this has little to do with the central point.
If you put code in the code, it will capture user actions (such as clicks) prior to loading all resources. If it's at the bottom of the </body> and the user clicks a link, you may not capture that click. Thus, giving you inaccurate analytics.
For this I find tools like lloogg.com invaluable (disclaimer: I'm the author of LLOOGG, but I'm currently not really running it as a business, at least for now, so I mean, LLOOGG or any other good real-time stat stuff).
There is nothing as good as identifying patterns as the human brain, and a few minutes every day of actually seeing what users are doing on your site is very good.
We do this to the tune of a million events a day (not pageviews, actual UI interactions) and it works well, especially given the $0 price tag. What's lacking is event correlation of the kind that KissMetrics and others support: how many users who performed event X went on to perform event Y.
Great post. I've been relying on heatmapping tools like Crazy Egg to answer some of those questions about where users are clicking. There are some definite limitations though; it seems like GA might fill those gaps nicely - for free.
Why does this require asynchronous GA and jQuery in the head?
Asynchronous GA seems like a best practice, but how would that affect the amount of event data you collect?
jQuery in the head would net you a negligible increase in data, and only for particularly heavy sites. No?
I use event tracking across a few sites in varying configurations (sync/head, async/footer, etc.) and would think anyone using GA and jQuery can benefit from this advice without changing their existing structure.