How to Use Event Tracking to Lower Your Bounce Rate

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.

Legacy GA.JS Event Tracking

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:

• The AJAX page elements that allow interactivity without requiring page loads.
• Anything developed in Adobe Flash, including website navigation or a Flash-based movie player.*
• Any special script-based page gadgets or widgets.
• A download of a file directly on the page, like an ebook on a landing page that doesn’t redirect when the opt-in form is filled out.

*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?

• Category is the name for a group of objects you want to track. For example, if you were tracking the play/pause, volume control, time skip, and play next buttons on a video player, the category as a whole would be something like VideoInteractions. This is required.
• Action is the unique identifier for the specific action being used. Each of the video interactions above would have its own Action label, like PlayPause, Volume, Skip, and Next. This is required.
• Opt_label is an optional string that can provide more information about the specific interaction in Google Analytics, giving it additional dimensions you can sort in your reports later.
• Opt_value is another optional value, this time an integer, which can provide numerical data about the event you’re tracking. Google’s example of how this can be used is to track the load time of a video between when the play action takes place and when the video actually begins to play.
• Opt_noninteraction is another optional value, this time a Boolean true/false. Generally this can be ignored or set to False. If it’s set to True, this interaction will not be calculated in bounce rate. An example of when you might want to set an interaction to False is if you have an autoplay video on your landing page. The initial pause interaction is not a sign that the user didn’t bounce; it’s just a sign that they wanted to stop the video from distracting them.

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:

• Category: “Videos”, Action: “Play”, Label: “Episode 1”
• Category: “Videos”, Action: “Play”, Label: “Episode 2”
• Category: “Videos”, Action: “Play”, Label: “Episode 3”

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.

Analytics.JS Event Tracking

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]);

• EventCategory is the category of the object interacted with, like “video” for a video interaction. It’s the same as category in the previous section, and it’s required.
• EventAction is the action taken on the object, just like action above. For example, “play” would be an action in the “video” category. It is also required.
• EventLabel is a label for the action happening. It’s a way to specify types of events in context. Google uses the example “fall campaign” to help you differentiate the same event throughout different time periods.
• EventValue is an integer, a numeric value, associated with an event. Again, the same as above.

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.

• Social interactions. Google Analytics has specific versions of event tracking set up specifically for social interactions. It works the same way, except instead of Send Event, it’s Send Social. You then specify the social network, the action the user is performing, and the target of the social interaction, be it your page or your social account. You can read more about the specific implementation here.
• App and Screen tracking. This is tracking you can do within an app that accesses your site, like Facebook’s app or the Reddit app. If you have a site app, this allows you to track that traffic that would otherwise be much more opaque to you. You can pass along the name of the screen, the name of the app, the app ID, the version, and other salient details. More information is here.

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.