How to fix Low Bounce Rate in Google Analytics

Everybody wants to have a low bounce rate in Google Analytics. This phrase was recently said in the Google Tag Manager community by one of our members. The quick discussion was about whether particular events in Google Analytics should be tracked as interactions or not because the choice impacts the bounce metric.

The truth is that bounce rate isn’t that important, after all. I mean, it is (to some extent). But not that much as some of you might be thinking. Unfortunately, many marketers still take the metric way too seriously. I’ve seen some them even using it as a KPI(!!!).

While bounce rate can give you some valuable insights on whether the visitors are engaging with your content/page, it also makes inexperienced people focus on the wrong things. Instead of improving what really matters (content, offer, pricing, UX, etc.) they just blindly try to reduce the bounce rate, often manipulating it.

As a result, bounce rate has become a meme in the analytics community, giving birth to such masterpieces (seriously, this website is awesome).

My main point so far is that the response to Everybody wants to have a low bounce rate is that’s not how people should think. I mean, many marketers want it, but they often make a wrong choice by adjusting the metric and making it too low. Consequently, such actions will mask the real insights that you could draw. If all your pages have ~20% bounce rate, what does it mean? Probably, not much.

On the other hand, not all Google Analytics tracking setups with low bounce rate are the result of greed or blind pursuit of the “KPI”. It also pretty often means that there’s something wrong with the implementation itself. In this guide, I’ll explain the most common (from my experience) cases, where the bounce rate is destroyed (accidentally or intentionally), how to debug them and how to fix things.

Let’s dive in.

Quick basics: what is bounce rate?

Before we continue, I’d like to take a quick step back and remind (mainly for beginners) what a bounce rate is in Google Analytics and how is it calculated. This will help you understand why is it so easy to manipulate the metric in the first place.

In short, a bounce rate is the percentage of single-interaction sessions on your web page.

In other words, a visitor landed on your site, did nothing (i.e. did not interact with the content), and then left.

I will not get into more details about the definition of bounce rate, because that could be another 5000+ word blog post. But you get the idea, right?

  • 1 interaction (e.g. page view) = bounce.
  • 2+ interactions = no bounce.

How is a bounce rate calculated in Google Analytics?

Let’s get back to theory for a moment.

Google Analytics calculates and reports the bounce rate of a web page (1) and bounce rate of a website (2).

  1. A bounce rate of a web page = total number of bounces (when people left) on a page (in a given time period) / total number of entrances on the page (in the same period of time)
    Example: 100 people entered the page A and 80 people left your website on the page A. Bounce rate of a web page will be equal to 80 / 100 *100% = 80%
  2. A bounce rate of a website = total number of bounces across all the pages on the website (in a given time period) / total number of entrances across all the pages on the website (in the same time period)
    Example: Yesterday there were 4000 entrances to the website, and 3000 ended up bouncing. A bounce rate of a website will be equal to  3000 / 4000 *100% = 75%

If a visitor lands on a page, that counts as a page view. If he/she navigates to another page of your website, another page view occurs (which is counted as interaction). Great! Your website’s bounce rate has decreased a bit because there were two interactions.

Let’s imagine another scenario. Your website consists of very long (5000+ words) blog posts. They are super useful and visitors adore them. But once they read it, they close the browser or switch to another tab.

Why? Probably because it was a bit exhausting for them to invest their time and effort to read the entire blog post. Now, they have to do something else (take a break, go drink a coffee, or finish some task, or whatever).

By default, this kind of session would be counted as bounce in Google Analytics. 1 page view –> Exit. But in reality, that visitor thoroughly read your blog post, clicked a few images to zoom, etc. Actually, there were interactions, you just didn’t track them.

That’s why by capturing more events (like clicks, video player interactions, etc.) on your website you can result in a bit more accurate bounce rate.

Another thing that will change in Google Analytics due to event tracking is session duration. In GA, the session duration is calculated as the time difference between the first and the last hit (e.g. a pageview or an event). So if a visitor lands on a page, after 60 seconds completes a certain interaction, e.g. click (that is tracked by GA) and then leaves after another 30 seconds, Google Analytics will report that the session duration was 60 seconds because that’s the time difference between the initial page view and the click.

To sum up, the number of interactions (e.g. page views or events) during a session affect the bounce rate and session duration. So if your Google Analytics implementation isn’t correct or if you’re tracking even unnecessary things on a page as interactions, those metrics will be affected.

The most common reasons why you have a low bounce rate in GA

I’ve prepared a list of the most popular causes that affect the metric. Here they are (in no particular order):

Each reason will be followed by steps of how to check it and fix.

#1. Double tagging

Double tagging means that there are two same Google Analytics tracking codes and each one of them sends a pageview. Remember the definition of a bounce rate? Two pageviews = two interactions (hits) = 0% bounce rate.

#1.1. Debugging and fixing

Although there are many ways to check this, here are several easiest ones (IMHO):

Tag Assistant. Install the extension LINK, click its icon and then the Enable button. Refresh the page that you’re debugging (P.S. if you need to learn more about the extension).

The number in the extension’s icon will change. Click it and if the Google Analytics tag is marked as yellow, click it. 

If you see the Same web property ID is tracked twice alert, then you need to remove one of them. If both GA Pageview tags are controlled via GTM, log in to your Google Tag Manager account and then remove one. In order to check this hypothesis, you should enable the GTM Preview and Debug mode and see which GA Pageview tags have fired on that page.

If one or more GA tracking codes are implemented directly in the website’s source code, you’ll need to ask a developer to remove one. Usually, GA (analytics.js or gtag.js) codes can be seen in View page source mode. In chrome, do the right-click anywhere on website’s background and choose View page source.

Google Analytics real-time reports. For this method, I use my Sandbox view in a GA property that includes only the data from my IP address.

After you have it set up in your GA account, go to the correct property > Real-time > Overview. How many visitors are there? If you’re working alone from that IP, then you’ll be able to properly test this.

If there are more people that are currently browsing the website from your IP (e.g. co-workers), an easy trick would be to add a bogus query parameter to the URL of your website just to identify your data from other visitors’.

If your web site’s URL is https://www.myawesomewebsite.com, change it to https://www.myawesomewebsite.com?param=just_me_testing and hit enter.

Quickly switch back to the real-time reports. Click the destination address that contains your bogus parameter:

How many pages did you see appearing in the real-time report’s chart at the same time (or over the course of 1-2 seconds)? One or more? If one, the GA setup is correct. If more, this means you have double tagging and you need to get rid of one GA tracking code (or GA tag if we’re talking about Google Tag Manager).

P.S. in order not to pollute your original GA view with the bogus parameters, you should definitely exclude your internal traffic from regular/original GA views.

dataLayer Inspector+

One of the awesome features of this plugin is that it automatically detects duplicate hits that were sent over to Google Analytics. All you need to do is install the Chrome extension, enable it by clicking the icon and then ticking the checkbox next to Data Layer.

Then go to the browser’s JavaScript console (of Developer tools) and refresh the page. If the warning (similar to the one below) appears in the console, you need to get rid of the duplicate hit (a developer should remove the hardcoded tracking code from website’s source or you should check for duplicate tags in GTM).

#2. Poor migration to GA + Google Tag Manager

This reason is very much related to the previous tip. In fact, double-tagging is often caused by poor migration. There are still many websites that have implemented Google Analytics the old way, by asking a developer to add its tracking code(s) directly to the website’s source. And when their owners finally decide to start using Google Tag Manager, they need to do a proper migration (which in many cases is not easy at all).

I will not dive deeper into the migration process itself. For reference, you can check this awesome guide by Bounteous LINK.

The main thing that you need to know is that a successful migration involves the hardcoded GA codes being completely removed from all pages and they should be replaced by GA Universal Analytics tags in a Google Tag Manager container.

Yet, not everyone succeeds to reach this result and eventually they end up with double tagging and duplicate data: the hardcoded tracking codes are tracking the very same interactions as the ones that are configured in Google Tag Manager (and then sent to that very same Google Analytics property).

So if you have recently migrated to Google Tag Manager Manager and your bounce rate fell hard to the bottom, I have a hunch that double tagging might be the case.

For a solution, please go back to the previous tip (#1) and follow the listed steps.

#3. Some e-commerce hits fire together with a pageview

This applies to Enhanced E-commerce implemented on a website. Since it enables marketers and analysts to see the entire funnel (from viewing a product to purchasing it) it’s logical that some Enhanced E-commerce steps/events are sent to GA when the page is loaded (for example, when a product-list is viewed).

In such cases two hits are sent to Google Analytics, a regular page view and an event that contains E-commerce data (e.g. product impression).

If you’re not familiar with the implementation of Enhanced E-commerce features (via GTM), I suggest reading Simo Ahava’s guide first.

In a nutshell, in order to send EE data to Google Analytics, you need to attach it to a Universal Analytics event or pageview tag in GTM.

Anyway, when a developer pushes the E-commerce data to the Data Layer, you need to enable Enhanced E-commerce features in each tag that you wish to transfer the E-commerce data with to GA.

Personally, I create dedicated Google Analytics events for EE funnel steps and each one of them transfers a particular data set that is stored in the ecommerce object in the Data Layer.

The list of possible Enhanced Ecommerce steps is:

  • Product impression
  • Product click
  • Product detail views
  • Add to cart/remove from cart
  • Checkout steps + checkout options
  • Purchase
  • Refund
  • Promotion impression
  • Promotion click

The thing here is that not all of the aforementioned steps should be treated as actual interactions that affect the bounce rate. For example, Product impression is not an interaction. A regular pageview tag already fires on a products list page so why would you need to track the product impression as an additional interaction?

The same principle should apply to product detail views, promotion impression, checkout (if navigating through every step reloads the page). Everything that is related to impressions/views of something should not be considered as actual interactions in GA. At least, that’s the rule I follow.

Even though I recommend tracking each EE funnel step with a GA event tag, some of them should not affect the bounce rate. That can be achieved by setting the non-interaction hit option to true.

This means that the event will still be registered in GA (together with an EE data) but the bounce rate will not be affected.

phpInfo

avatar
  Subscribe  
Notify of