Where did Bounce Rate go in Google Analytics 4?

Analysts have relied on the metric “Bounce Rate” to understand how well users are engaging with a website for over a decade, but Google Analytics (GA4) includes a new and improved metric for measuring user engagement called "engagement rate". This post will explain why Google chose not to include Bounce Rate when GA4 was first released, and give you the information you need to transition to the new engagement metrics that have replaced it.

• Update: July 11, 2022

  After 2 years without it, Google has added the Bounce Rate metric into GA4. I’ve updated this post as a result.

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, but 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 calculate 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 Try to Retire Bounce Rate when GA4 was Released?

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.

Google Analytics 4 is built to be flexible. It joins data from both websites and mobile apps in a simple interface, and provides 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.

Google Analytics 4 has launched a new metric called an "Engaged Session" that can be used to replace the concept of a “Bounce”. 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 GA4 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 can 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.

Bounce vs. Engagement Rates

Can I get Engagement Rate in another Analytics tool?

As I write this, I am not aware of any other Analytics tool that provides tracking like this, so you will likely only find this in GA4 unless you’re ready to write a lot of custom code. The new GA4 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 teach your stakeholders about Engagement Rate where they will continue to ask you to provide Bounce Rates. When this happens, I encourage you not to defer to 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.

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 Google Analytics 4 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:

1. When the app is sent to the background
2. When the user switched screens or navigated away from the current page
3. When the app crashes
4. 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.

_et parameter in the network

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.