Event tracking is a beautiful thing.

With it we can track visitor actions that don’t load the Google Analytics Tracking Code (GATC) such as PDF downloads, image clicks, uses of a tool. In simple terms, it’s widely used to track pretty much anything that doesn’t load another web page on your site.

Tracking these sorts of events is relatively simple; you just add a piece of code that sends a signal to Google Analytics saying “Hey! Please record me, I’m an Event!”

A lot of the times we want to record Events when a visitor clicks on a particular button on our site.

For example, if you wanted to track a PDF download, you’d want to record how many visitors clicked on the button that links to the document. That would give you a rough idea of how many times the PDF was downloaded.

So far it seems pretty straight forward… but not so fast. How you define “click” (which is the moment when you want to send this signal) makes a huge difference.

Should I track OnClick or OnMouseDown?

We have a lot of flexibility when it comes to setting up the code that is going to track these events.

The Event tracking example on Google’s site, which is where most people get help and examples to implement these, shows something like this:

<a href=”#” onClick=”_gaq.push([‘_trackEvent’, ‘Videos’, ‘Play’, ‘Baby’s First Birthday’]);”>Play</a>

See the “onClick” part? That means the signal is going to be sent to Google Analytics when a click happens. It turns out that there are two very similar ways to track a click, either “onClick” or “onMouseDown” – let’s see the difference.

  • “onClick” means that the signal will be sent when the “click” has occured, in other words, pressing and releasing the mouse button.
  • “onMouseDown” means that the signal will be sent when the finger goes down and the mouse button is pressed.

Seems like such an insignificant detail… but it’s not.  For example, a growing concern with “onClick” is that things online are so fast today that sometimes the visitor has navigated away from the page before the “onClick” signal is sent, so that particular Event is not recorded.

onClick vs onMouseDown seems like such a trivial question, let’s put it to the test.

The Experiment

After having a philosophical ‘onClick’ vs ‘onMouseDown’ discussion with the team, particularly with Eduardo Cereto who decided to use “onMouseDown” with Google Analytics on Steroids (GAS) (a fantastic customization of GA, by the way), I decided to do a casual experiment to get an idea about the difference between “onClick” and “onMouseDown”.

The results… wow.

I added two events on an intro page for one site. The only links for this page are the “ENTER” and image and the small credit link at the bottom.

A pretty simple page that with the following layout.

The “ENTER” link (image or text) on this page looked like this:

<a href=”/default.asp” onmousedown=”_gaq.push([‘_trackEvent’, ‘onMouseDown’, ‘Click’]);” onclick=”_gaq.push([‘_trackEvent’, ‘onClick’, ‘Click’]);”>ENTER</a>

Here are the traffic numbers for a week:

This landing page received 235 visits and had a bounce rate of 9.36%. This means that of those 235 visits, 213 didn’t bounce. I’m going to assume the small link at the bottom, which goes to the developer’s site, accounts for a minimal percentage of visits (truth is I’m just realizing that it was there).

Accordingly, it would make sense for me to see near 213 Events. That’s the most logical and probable way a user can go from this page.

Here’s what I’m seeing:



I’m still a little taken aback by the spread in numbers. In fact, I’d be skeptical if I didn’t run the experiment myself… so many hypotheses, so many hopes, dream collapse.

These results suggest onMouseDown is more accurate than onClick when it comes to scenarios like the one presented.

Having said that, there is no right or wrong way of measuring things. There is just measurement. It’s up to us to interpret the numbers.

I’m going to keep testing this, but wanted to share these preliminary findings and start changing minds and setting things right in the onClick vs onMouseDown debate.

  • Quite a shock, “In fact, I’d be skeptical if I didn’t run the experiment myself…”. Exactly, I will do the same measurement and see what I get.

    • Great – do share your findings when you get them 🙂

  • Jerry

    Definitely interested in any followups

    • Hi Jerry – I’ll keep you updated. I’m already receiving questions that could prompt the follow up. Some are skeptical about the results, some are rising questions like, does browser matter?

      These are interesting, for example, this is what I see for the browser report. I didn’t know what to expect here but you can see that Firefox and Chrome have a much wider gap than IE. 

      • I also did a small test last year of the “OnClick” function and about half were captured on Chrome, while 95% on IE.

      • WOW! It’s unbelievable! I wouldn’t believe if i not see this gap. Tnx for sharing!

  • Nice.

  • What a good experiment Jose, it’s definitely interesting to see how the different methods change the event count. 

  • Thanks Casper – Interesting to say the least. I’m looking forward to follow up tests of my own and also what others are seeing.  Better understanding the numbers we see on GA is generally a good thing 😉

  • Charles Farina

    Did you use the non interaction event, if not onMouseDown would incorrectly affect the bounce rate even if the user didn’t navigate to a second page?

    • Charles – The code I used is on the post. The onMouseDown would have affected bounce rate, but I wouldn’t say it affected it incorrectly… it just means that if the event made it, the visit will not be counted as bounce. 

      • Charles Farina

        Thanks for the clarification.  It would be very interesting to see this test run again with the non interaction events.  We were talking about this here and a couple people think that clicking on a link and then changing your mind and dragging your mouse off before letting go is a common behavior.  

  • Great experiment.

    We’ve done tons of comparisons between onClick and onMouseDown in our Analytics Engine platform.  What we’ve consistently found is that onMouseDown produces more data in GA for one simple reason: timing.

    onClick will initiate tracking when the “click” completes, i.e. mouse down and mouse up.  This can initiate a race between the browser and the GA tracking script.  On faster browser this can mean that the onClick won’t get fully tracked because the browser unloads the page before the hit is either received or a response returned by the GA collection front-end.

    With onMouseDown, the tracking script begins running one the mouse “down” occurs, which provides a slight bit more time to get the tracking executed before the page unloads and moves on.

    Hope this provides some clarity to the cause!

    -Caleb Whitmore

    •  Hey @analyticspros:disqus  – Thanks for the perspective.

      Agreed that timing is the main thing here. Which also means that technology plays a part – i.e. browser speed (take a look a the screen shot I added to my reply to  Jerry).

      And yes, I was expecting a gap between the two, but not as big – almost half. It makes sense for this gap to widen with time as browsers get faster, users install more plugins, add-ons, and the environment gets more complex.

      I’ll definitely follow up with further thoughts. Cheers!

  • André Mafei Bezerra

    Would be interesting to compare also the official way: 

    •  @google-3b5d6ee27e8fc8bf355a803e922d6046:disqus – Google uses onClick for their examples. I’m guessing the vast majority of people out there use onClick. Not that is wrong, but we should be aware of what the number means 🙂


  • Prinzhorn

    I never used this kind of tracking, but this may be solved by using:

    <a href=”/” onclick=”_gaq.push([‘_trackEvent’, ‘onClick’,
    ‘Click’]);_gag.push[function() {location=this.href}];return false;”>ENTER</a>

    Edit: Maybe add a fallback as well to redirect after like 500ms.

    • disqus_ryan

      Thanks, Prinzhorn — I extended your example a little bit and now do not miss events from regular onclick events that result in navigation-away:

      <a href=”target.html” onclick=”var _href = this.href; _gaq.push([‘_trackEvent’,’clicked ‘ + _href]); _gaq.push( function(){ window.location = _href } ); return false;”>go to target</a>

      0) store the URL into a temporary var
      1) push the event
      2) push [ the thing the onclick should result in ]
      3) return false

      Sadly we have to remain noscript friendly, so the natural function of the link will still occur this way.

      Note that the scope for “this” object changes when it executes from the queue, so pre-storing it is a little .. uh .. reach-around.

  • The only issue I see with this is that a mousedown doesn’t equal a click. I can click, hold and drag—that’ll never take me to the link, but would count as a “visit” in this model.

    That seems like a seldom-occuring event, but it’s the type of thing I’d be conscious of as you experiment more. There’s a reason a “click” is a wholly different event than a “mousedown” … it’s just a matter of figuring out if those reasons apply to this scenario.

    Another little wrinkle in your test might something I’ve experimented with, which is to add a 500ms delay to the click. Using jQuery:

    $(“a”).click( function(e) {
         /*do some fancy scripting stuffs*/
         setTimeout(“window.location(‘” + this.href + “‘);”, 500);

    …basically prevent the link from working and then “fake” click it a half-second later. Users don’t notice the tiny delay, but it gives the tracking GIF that much longer to fire.

    Actually, I wonder if you combined this with mousedown, if that might even make it smoother….very interesting! I’ll be interested to read what you find out!

    • Sébastien Brodeur

      .click is mapped to the onclick event. onclick DOM event is NOT fire when using middle or right button.

  • We got 14 % more onMouseDowns than onClicks in our test. Will continue it… 

  • Vesko Aleksandrov

    it gets even more interesting when you segment your test results by browser. hint: check chrome 🙂

    •  Yep, interesting indeed – Check out the image I posted in reply to Jeff (one of the first comments)…

      • Vesko Aleksandrov

        excellent article Jose, thanks for sharing! 

  • Won’t the event cause the visit to the counted as non-bounce? (See https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide#non-interaction) Therefore the bouce rate doesn’t tell you for sure that the mouse-down people actually clicked – they would be counted as non-bounce simply due to the event firing, even if some unknown number of them mouse-downed and draged off. 
    If this were the case then OnClick might possibly still be the more accurate count. You could compare numbers in the navigation report for the target page?

  • Very interesting. I’ll try it myself using the 500ms snippet Nathan Ziarek posted.

  • Sébastien Brodeur

    Why onmousedown? Better to use onmouseup no?

    onclick DOM event is NOT fire when using middle or right button. onclick is mapped to the left button click. So people using the middle button to open the link in a new tab, or people using the right click button to use Save As… (or Open New Windows/Tab) are NOT recorded by the onclick.

    The discrepancy in data may be due to those click using other button and not by a race condition.

  • Timur

    This is weird because in all of my campaigns (and I’ve done a lot), I’ve always had more recorded clicks than visits. I thought this was normal since sometimes double clicks are recorded. I’ve never had less clicks than visits

  • Hi Jose,

    Any update to this now we’re a year down the line?


  • Antithexist

    I’ve seen this before. The reason we found was that the browser location had changed before the google analytics call was complete and so the call failed (aborted). We solved it by putting the GA call in an anonymous function from within a setTimeout() call of 20ms (or so), which then puts the GA call outside the document context and into the window context, a context that isn’t destroyed by a window.location change.

    • Steve Kalkofen

      I know this is a bit old, but can you post some sample code of your suggested solution? I am having problems envisioning the solution as I am not a heavy-duty Javascript developer

  • lulalala_it

    I think now Google recommends doing a delay so there is time for onclick to run. https://support.google.com/analytics/answer/1136920?hl=en

  • Hey, nice comparison! Great result! Thanks!
    Do you have any experiences with jQuery click events? What ist happening with those events if the browser is leaving the site? Are those still in a browser queue and ‘ll be processed?

  • The reason why this is happening is because you’re triggering two things at once: the Google Analytics tracking event, and the browser’s native click action. When the browser acknowledges that a click action has occurred, there is a slight delay (typically <400 milliseconds) as the browser figures out what to do, and if the user is going to go to another link, start performing a DNS lookup on the URL.

    The onMouseDown event triggers when a mouse button is pressed down. When the mouse button is released, the onMouseUp event is triggered, along with the onClick event. Since the action of pressing down a button and then releasing it could take some more time, this adds more time for the Google Analytics tracking event to fire.

    Firing the Google Analytics tracking event takes a considerable amount of time as well. In my tests, it took around 200 milliseconds to fire. If you compare that to the time it takes from firing the onClick event to loading the next page, you can tell that in some cases the Google Analytics tracking event doesn't "win" the race versus the browser's native click action, therefore you end up losing some events that could have been captured. This problem is known as a "race condition."

    What's the solution? Prevent the browser's default action for the onClick event, wait for the Google Analytics tracking event to fire, and then follow through with the original action that the user intended to do—which in this case was to load another page. In jQuery, you can accomplish this very easily:

    $("#myLink").on("click", function(e) {
    var url = $(this).attr("href");

    // Track the event with GA
    hitType: "event",
    eventCategory: "onClick",
    hitCallback: function () {
    // The code in this function is fired after GA successfully triggers the event.
    // We want to redirect the user to the URL that the link was originally going to.
    window.location = url;


    This link will always navigate to the page it’s linking to after the tracking event has successfully fired, resulting in a 100% capture rate on clicks.

    I hope this helps someone out there!

  • Abdul

    If I already have onclick function in the link so how can I add the GA function to track the downloads. Can I use onMouseDown and onclick in the same link.