Analysts have relied on the metric “Bounce Rate” to understand how well users are engaging with a website for a decade, but it does not appear in the new version of Google Analytics (App + Web). This post will explain why Google chose to remove Bounce Rate, and give you the information you need to transition to the new engagement metrics that have replaced it.
What is Bounce Rate?
Let’s start at the beginning: a “bounce” occurs when a user views one page on your site before exiting (I’m aware that you can manipulate this with “interactive”events, this is the general idea). You can take the number of bounces that occurred in a time period and divide it by the total number of sessions to get the metric Bounce Rate, and it’s common to compare the Bounce Rates of various campaigns or traffic channels.
The business question that we are trying to answer with this metric is: “Are customers really engaged with my site, or am I just getting a lot of sessions that do not add value to my business?”
Why Did Google Need to Retire Bounce Rate?
You may remember from your first day as an Analyst that Bounce Rate is not a very useful metric. On most websites, a user might have a successful visit and still bounce (think about how you interact with news articles for example). Additionally, it’s even more rare for this metric to make sense in a mobile or single page application, where users don’t always generate multiple page views during a session.
App + Web properties are built to be flexible. They join data from both websites and mobile apps in a simple interface, and provide you with reports that are useful for measuring a wide variety of user experiences. With that in mind, it’s no surprise that Bounce Rate had to go.
What Alternatives to we have to Bounce Rate?
Analysts have never had a healthy relationship with Bounce Rate, but most of us have been afraid to put ourselves out there and find someone new. Well I’m here to tell you that there are other fish in the sea, so let’s talk about alternatives.
The new version of Google Analytics has replaced the concept of a “Bounce” with something called an “Engaged Session”. For a session to qualify as Engaged, the user must be do at least one of the following during their session:
- Actively engaged with your website or app in the foreground for at least 10 seconds
- Fire a conversion event
- Fire 2 or more screen or page views
You’ll notice several new metrics in your App + Web property that are built on top of this concept:
- Engagement Rate = (engaged sessions) / (sessions)
- Engaged Sessions per User = (engaged sessions) / (users)
- Engagement Time = sum(engagement time)
The new metric you’ll want to use instead of Bounce Rate is Engagement Rate.
How Does Engagement Rate Compare to Bounce Rate?
Just like Bounce Rate, the Engagement Rate is useful for answering the question: “Are customers really engaged with my site?”. But Engagement Rate can also be applied in places where Bounce Rate cannot, such as: mobile apps, single page apps, and content sites such as blogs and news outlets.
Your Engagement Rate will always be greater than the inverse of your Bounce Rate. This is because a session with at least 2 page views (not a bounce) qualifies as an engaged session, but so do other sessions that would otherwise be considered a bounce.
So, if your Bounce Rate was 65% last month, your engagement rate will be at least 35%. If your visitors are converting or actually reading your content, then the area shown in yellow below will be larger, which will drive up your Engagement Rate.
Can I get These Metrics Without Upgrading to App + Web?
Not unless you’re ready to write a lot of custom code. The new App + Web properties automatically run logic on the client to calculate the amount of time that the browser or mobile app is active in the foreground. Then, at various points in time, this data is automatically set to a parameter called “engagement_time_msec”. When you view the metric “Engagement Time” in a report, you are summing up the values of the “engagement_time_msec” parameters across all your events.
To be clear, “Engagement Time” is different from “Average Session Duration”.
Session Duration = (the timestamp on the last hit of your session) – (the timestamp on the first hit of your session)
This is a bit of a blunt instrument because we know that users keep browsers and apps open in the background from time to time, and we really don’t want to include that in our calculation. Additionally, this approach requires you to manually set at least 2 hits during a session to be calculated.
Engagement Time = SUM(all instances of the “engagement_time_msec” parameters across all your events)
This metric is more descriptive of actual behavior, and the fact that it is handled automatically makes it more accurate and a better comparison across properties.
Some Tips for Migrating away from Bounce Rate to the New Metrics
There will inevitably be a period of time after you upgrade to an App + Web property that marketers and other stakeholders continue to ask you to provide Bounce Rates. When this happens, I encourage you not to calculate Bounce Rate to appease them. Instead, use this as an opportunity to share the benefits of Engagement Rate, and push them out of the dark ages.
These new metrics solve a lot of the problems, but marketers are resistant to change. Bounce rate is comfortable and easy to understand, despite its shortfalls. Analysts are going to need to do a lot of work to get our stakeholders comfortable using better metrics and asking better questions than they did in the past.
To help with this, I’ve created a one-pager that you can share internally:
Also, I recommend that you start setting a target Engagement Rate for each channel or campaign that you’re tracking. If you’re not sure where to start, just take the inverse of your normal bounce rate (so if a good Bounce Rate was 65%, set your Engagement Rate target to 35%). If this target is too high or too low you can always move it later, and simply having a target will spawn the conversations that will help familiarize your team with the new metrics.
How can I test that App + Web is properly calculating Engaged Sessions?
The complexity of this approach is a problem in my opinion. There are several actions that prompt Google to collect engagement time, including:
- When the app is sent to the background
- When the user switched screens or navigated away from the current page
- When the app crashes
- When the user has kept your app in the foreground for a long period of time
In the times when one of these actions already triggers an event (like “app_exception” or “screen_view”), the “engagement_time_msec” parameter will simply be added to those events. However, in cases where no other event exists, a new event called “user_engagement” will be triggered. These events are removed from the User Explorer report, but you can find them in BigQuery.
On the web, the engagement time is passed in milliseconds with the parameter “_et”, as shown below. You can verify that the timer wasn’t running while the page was minimized by opening a page, minimizing it for 30 seconds or so, and then maximizing it again and quickly clicking to another page. In this scenario you should see that the timer was not running while minimized.
To calculate engagement time in BigQuery, you can simply sum the value set by any event that contains the parameter “engagement_time_msec” as shown below:
SELECT user_pseudo_id, SUM(engagement_time) AS total_user_engagement FROM ( SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = "engagement_time_msec") AS engagement_time FROM `firebase-public-project.analytics_153293282.events_20181003`) WHERE engagement_time > 0 GROUP BY user_pseudo_id
And that’s it. Hopefully you will find that Engagement Rate improves your ability to understand how users engage with your site or app.
If you have trouble with this metric or find instances where it causes problems, please add a comment or send me a message so that I can update this post.