One of the problems we’ve written about before is that the bounce rate for a site is not inherently accurate in Google analytics. The problem is that it requires two interactions with a page to record a site visit as anything other than a bounce. A user who visits your site, reads your content, is satisfied, and leaves does not make a second interaction, and is thus left as a bounce rather than a satisfied user.
This, generally, means that your bounce rate is higher than it actually is. If you find a way to record other interactions with the page besides just loading a new page, you can record session information about users who click around on your blog post but don’t move on to another page.
Google has a way you can record other interactions with your page, so long as they’re specific interactions. It’s called event tracking. There are different implementations of event tracking depending on whether you’re using the modern analytics.js, or the old deprecated ga.js version of Google Analytics. I’ll go over them both, but I’m starting with the old version. If you’ve updated – and you should – feel free to skip this first section and move on to the second.
Event tracking works by assigning a trackable piece of code to various pieces of media on your site that normally do not count as interactions and are thus not tracked by Google. Some examples include:
*I highly recommend moving away from Flash. Flash is a highly exploited plugin and opens up most web browsers to security holes. It’s one of the most common vectors of malware distribution via ads. It’s prone to crashing, necessitating restarting the browser. It doesn’t work on certain mobile devices. Chrome and Firefox have started blocking it by default, requiring a user interaction to play Flash media, which can be killer for Flash-based navigation. Video players are much better done with HTML5. And, if that all wasn’t enough, Adobe is planning to stop supporting Flash at all by the end of 2020.
You can, essentially, track anything you want as long as you can attach a specific tracking code to the specific event action you want to track. You do, however, need to make sure it’s an event that is only tracked when it’s used. It does you no good to track something on page load other than what Google is already tracking; it doesn’t add any data.
One tip directly from Google is to think heavily about your site and implement a good reporting structure before you even start to implement event tracking. You don’t want to add an event to track and find that it doesn’t mesh well with the rest of your data. Having an overall sense of the kinds of actions you might want to track in the future can be good.
Additionally, make sure that when you track an event, you name that event something clear. You don’t want to find yourself wondering what exactly the difference is between EventA1 and EventB1, and how they related to EventAB or Event1. It’s much better to have events like NavButtonHome and VideoPause.
The first thing you need to do in order to set up event tracking is to set up general tracking on your site. You already have this if you’ve used Google Analytics so far. If you haven’t, you’ll need to do the whole paste-code-verify-ownership rigmarole you need to set up Google Analytics.
Assuming you have GA set up, you will then need to modify the code of anything you want to track as an event. You will need to add the _trackEvent() method as a call in the code. If you don’t know what that means, tell your developer to do it.
The _trackEvent() method has a specific format, or signature. It looks like this: _trackEvent(category, action, opt_label, opt_value, opt_noninteraction).
What does this all mean?
It should be noted that actions can be named the same in different categories. You could have two different Play actions in two different categories. However, when you’re viewing Google Analytics later, and you want to see individual action metrics, those will be counted as the same action unless you’re also separating by category. It’s worthwhile to give every category and every action a unique name.
Labels are useful for differentiating the same action in the same category on different objects. For example, let’s say you have a page that has three videos on it, each one as a trailer for a Star Wars film. All of them would have the category Video, and all of them would have the action Play for pressing the play button. How then do you tell the difference between each video? That’s where the label goes. So you would have three entries:
Word of caution. There is a limit of 10 event hits sent to Analytics right away. Once those 10 are up, Analytics will only accept up to one event hit per second. If you were to, say, have a video send a new event for each second that is played, that would use up your quota and would override other actions you might want to have tracked. If you’re tracking multiple simultaneous actions, try to make sure there aren’t a lot of other actions being tracked before it.
Migration. Google has already transferred all Analytics properties to their new Universal Analytics. I know some people haven’t bothered to fully update their sites, or are resisting because some feature they liked is no longer available. I highly recommend updating regardless. As time goes on, you’ll have more and more issues with legacy code. To take full advantage of event tracking, migrate to Analytics.JS and implement tracking in the following way.
If you read everything above despite it not applying to you, I apologize in advance for anything I cover a second time, like the warning about why Flash is bad.
Event tracking with the modern analytics code works the same way as with the older code; it attaches a piece of trackable code that runs when a user triggers the associated event, which then adds that event to Google Analytics as an interaction. The examples above still apply; the AJAX elements, the Flash elements, the scripts, the widgets, the downloads.
It’s worth reiterating here that Flash should be removed from your site if at all possible. It’s poorly indexed if it’s indexed at all, it’s a performance hit and a load time hit, and again, Adobe is going to be abandoning it themselves in just a couple years.
Analytics.JS events work in a different way. They rely on the new Google Analytics way of parsing events as hit types. You can read about what hit types are here. Essentially, different hit types record as different events in Analytics. Modern Analytics supports a few different hit types on its own, like pageviews and various informational types.
Like the GA.JS version, you have a specific format of event command to call. This one is formatted:
ga(‘send’, ‘event’, [eventCategory], [eventAction], [eventLabel], [eventValue], [fieldsObject]);
One useful way to use events is to set an event to monitor clicks outside of your website. When a user clicks an external link from your site to another page, normally that doesn’t count as an interaction and thus doesn’t continue the user’s session. It records as a bounce, even if it wasn’t a bounce at all. You can use the event tracking to monitor outbound clicks. Just don’t do this for internal links, because you’ll double up the outbound click and the internal pageview.
If you want to exclude an event from counting towards your non-bouncing users, you still have a non-interaction attribute you can add to the event flag. In this case, you just need to add the “nonInteraction: true” line to the place where I have “fieldsObject” up above. This will flag the event as a non-interactive event to keep from inappropriately recording it as a user interaction.
I haven’t really covered it here, but the new analytics also has other ways to track user interactions, so you don’t necessarily need to put specific event tracking code when there are pre-made solutions.
Between all three of these, you should have a pretty easy time reducing your bounce rate. Though, of course, your actual bounce rate is not dropping at all. You’re just getting more accurate data about the people you thought bounced, but who really didn’t.