One day you open your Universal Analytics (GA3) reports and there is a sudden drop in bounce rate. Maybe it’s even 0? This does not mean that overnight your website became much more engaging. This shows that something is broken in your Google Analytics setup.
In this blog post, I will walk you through the most common reasons why this happened and how to fix it.
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.
1 interaction (e.g. page view) = bounce.
2+ interactions = no bounce.
The most common reasons why you saw a sudden drop in bounce rate
I’ve prepared a list of the most popular causes that cause a sudden drop in bounce rate (in no particular order):
Double tagging
Poor migration from hardcoded GA to GA via GTM
Some e-commerce hits fire together with a pageview
Some other events are fired together with a page view
In the single-page application, the virtual pageview is sent right after a regular pageview
Scroll-tracking are tracked as interactions
Each reason will be followed by steps of how to check it and fix it.
#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:
By using the Tag Assistant (legacy) Chrome extension
Checking GA real-time reports
By using the dataLayer Inspector+ Chrome extension
Tag Assistant (legacy). Install the extension, 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, check this guide).
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 it. 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 the 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 the 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 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 in this blog post but if you are interested, I cover it in great detail in my Google Tag Manager course for beginners.
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. Or you can take a look at my Google Tag Manager course for beginners where explain the process in great detail.
#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 explain it in great detail in my Intermediate/Advanced Google Tag Manager course.
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 the 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 product 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 EE data) but the bounce rate will not be affected.
I explain the troubleshooting process here.
#4. Some other events are sent to GA right after the page view
Even if you don’t have the Enhanced E-commerce implemented on a site, it’s still possible that some other events fire right after the initial page view hit. Apply the previously described method of verifying the implementation with Tag Assistant Recordings and check the generated Google Analytics reports.
First, open GA reports (in Google Analytics interface) and go to Behavior > Site Content > All Pages and see which pages (most visited) have the lowest bounce rate. That’s where I would start looking first.
Enable the Tag Assistant Recordings and navigate through those pages to collect data and see which events are firing on every page view. These are your suspects.
To give you more examples of this issue, check the tips #5, #6 of this blog post.
#5. Single-page application: a virtual pageview is sent right after a regular pageview
Single-page applications/websites do not refresh when a visitor navigates through them. As a result, some additional configuration needs to be done in order to start seeing how visitors are interacting with your content. I’ve published a guide that explains how to utilize History Change trigger in such pages.
If URL fragments (that come after a #) are not present in the URL, you could ask a developer to push some page-related info to the Data Layer whenever a visitor navigates from one section/page to another.
The main idea behind these solutions is to fire a Google Analytics pageview tag every time a state of a page has changed (e.g. a visitor navigated from example.com/#pricing to example.com/#contact-us).
Sounds pretty simple but there is one nuance. Single-page applications (SPA) are not coded in the same way, therefore, it’s natural that their state-changes might behave differently.
In some SPAs, the state change is not pushed to the Data Layer when the visitor lands on a page. See the screenshot below:
In such cases, a “change” event is registered only when a visitor actually navigates to another section of SPA. Then the GA Pageview tag should be linked to two triggers:
The state-change trigger (e.g. History Change trigger)
and a regular Page view trigger.
This means that when a page is loaded, the Page view trigger fires the GA Page view tag. And as the visitor continues browsing the SPA, the state-changes (e.g. History Changes) will trigger the subsequent page view hits in GA.
But as I’ve mentioned before, not all SPAs behave in this manner. Sometimes the state-change event is pushed to the Data Layer with the page load as well, like in the screenshot below. I just landed on a page and I already see the regular Page view event that is followed by the gtm.historyChange event.
So if you set your GA Pageview tag to fire on both All Pages trigger and History Change trigger, you’ll have a 0% bounce rate because GA receives two page views even though there should have been only one.
#5.1. Debugging and fixing
Debugging is pretty simple here. Enable GTM Preview and Debug mode, refresh the page that you’re currently working on (but don’t navigate anywhere), and take a closer look at the summary of the P&D console.
How many times was the GA Pageview tag fired? If one, you’re good. If two or more, you need to fix this.
Remove Pageview trigger(s) from that GA tag except and keep only the ones that are related to the state change (it might be History Change or a Custom Event trigger).
#6. Scroll tracking
This trigger was the one that caused the discussion in the GTM community about the bounce rate. A member was not sure why should he configure the Scroll Tracking GA events as non-interaction hits because everyone wants to have a low bounce rate.
Let me explain.
Imagine a situation. A visitor lands on your website, scrolls around 50% of the page height, and leaves after 5 seconds (without doing anything).
Should such a session be counted as a bounce or as a session with interaction (the only interaction that was done here is scrolling)? I think that should be a bounce.
Remember how Avinash Kaushik described a bounce rate: I came, I puked, I left. It has already become a cliché to say this quote every time someone introduces the metric, however, it’s represents the idea really well.
That’s why scrolling should definitely not be treated as an interaction. Unless you modify your tracking:
Combine the scroll and timer triggers
Or track when a visitor reached a particular part of your website (say, scrolled till the very end of a blog post)
In other cases (e.g. scrolled 20%), scrolling should definitely not be treated as an interaction.
This especially causes issues of an artificially low bounce rate in Google Analytics when a page height is quite low. In that case, the scroll trigger (without additional modifications) will activate just after the page view because the visitor has indeed passed the mark of 25% of page height.
#6.1. Debugging and fixing
There’s not much of a debugging here. Just go to your GTM container and open the GA Event Tag that tracks scrolling. Change the non-interaction hit to true and save the tag.
After that change, you need to keep in mind one thing. Non-interaction hits are not displayed in GA real-time reports’ table of active users.
You can only see them in the Events (Last 30 min) section.
Sudden Drop in Bounce Rate: Final Words
A sudden drop in bounce rate within your Google Analytics reports signals that there is an issue with your tracking setup. Maybe you have duplicate tracking codes that fire multiple page views (instead of one), maybe your colleague did some changes in the Google Tag Manager container that is causing this issue. Or maybe even something else.
There are many reasons that cause this and I have listed them in this article.
Hopefully, you found a solution to your problem. If you have any questions, feel free to post a comment.
The post Sudden drop in bounce rate of Google Analytics? Here is how to fix it appeared first on Analytics Mania.
Read MoreAnalytics Mania
