Hi @flaky-noon-11399, Do we already have a method in place to track the bounce rate of a page in GrowthBook? cc: @square-state-87588

Hi @thankful-television-69452 good morning 👋 Yes, GrowthBook supports bounce rate, but it needs to be created as a custom metric rather than being available out of the box. For a true bounce rate, use a Ratio metric of bounced sessions ÷ total sessions and set the goal to Decrease; if using GA4, a bounce is a session that was not engaged.

Thanks for the response, @flaky-noon-11399! Just one question, how will we get the bounced session data in GrowthBook Managed Warehouse? Is it something we need to track separately?

My pleasure to assist and yes this will need to be tracked as a custom event tracked either via the SDK or ingestion API

@flaky-noon-11399, I’ve currently tracked this metric so that if a user stays on the session for more than 10 seconds, they’re counted as non_bounce. I’ve been using the non-bounce rate rather than the bounce rate. Since the experiment is already halfway complete and the client needs bounce rate, which is the inverse of non-bounce rate, is there a way to invert the existing metric/data in GrowthBook without changing the tracking and affecting the experiment data?

Hi @flaky-noon-11399 let us know if there is a way to flip this metric.

There isn’t a direct toggle to flip the existing metric. The quickest option is to report Bounce Rate as 100% − Non-bounce Rate, leaving the current experiment and tracking unchanged. If you want Bounce Rate displayed in GrowthBook, and Managed Warehouse has a

session_id

for every session, create a new metric using (total sessions − sessions with a

non_bounce

event) ÷ total sessions, set its goal to Decrease, then add it to the running experiment and refresh. GrowthBook can use the historical raw data, although its time-series view will only begin from when the new metric is added.

@flaky-noon-11399, I can’t find the option for subtraction. "total sessions − sessions with a non_bounce event"

You’re right—there’s no subtraction option in the metric builder; my previous wording was conceptual. To create this in GrowthBook, you’d need a custom session-level Fact Table in SQL with an

is_bounce

column, then create a Ratio metric: • Numerator: sessions where

is_bounce = 1

• Denominator: all sessions Without custom SQL, the alternative is to keep the existing metric and calculate

100% − non-bounce rate

externally.

@flaky-noon-11399 Could you please guide me through the full steps to set this up in GrowthBook? I tried creating the session-level Fact Table, but I’m running into an issue with the table configuration. A step-by-step guide would be really helpful.

Of course. First, please confirm that every session sends a

Page View

event and that both

Page View

and

non_bounce

contain the same

session_id

. Without an event representing every session, historical bounced sessions cannot be identified. Next you'll need to create the session-level Fact Table and metric From that Fact Table, click Add Metric and select Ratio: • Numerator: Count of Rows, filtered to

is_bounce = 1

• Denominator: Count of Rows, with no bounce filter • Goal: Decrease the metric value We have an AI bot injected into our docs that could give you granular details such as code examples of the SQL to use

Hi @flaky-noon-11399, thanks for the guidance. I’ve started setting up the session-level Fact Table, but I’m stuck on the

session_id

part. In our GrowthBook

events

table, the

session_id

column exists, but when I query it, the values appear to be empty (

LENGTH(session_id) = 0

). I can see

non_bounce

events and other events such as

checkout_page_view

, but I’m not seeing a usable session ID attached to the events. Could you please clarify: 1. Does GrowthBook automatically generate/populate

session_id

for every event/session, or do we need to explicitly send

session_id

with every event from our tracking implementation? 2. If we need to send it ourselves, could you share the recommended GrowthBook implementation for generating/persisting the same

session_id

across all events in a session? 3. What should the

Page View

event look like in the

events

table for this Fact Table setup? 4. Is there any existing GrowthBook session identifier that we should use instead of creating our own? Once I have the correct session ID implementation, I can proceed with the session-level Fact Table and the

is_bounce

Ratio metric. Thanks!

Hi @flaky-noon-11399 your guidance here will be super helpful

Hi @thankful-television-69452 @square-state-87588 Apologies for the delay I was OOO on Tuesday, please see the following responses: 1. Does GrowthBook auto-generate/populate

session_id

? I just double checked and

session_id

isn't set by the auto-attributes plugin. You'll need to generate and send it on your end on every event. 2. Recommended implementation for generating/persisting

session_id

Generate a random ID client-side, store it in a cookie or

sessionStorage

(so it survives across page views but resets per browser session), and pass it explicitly as an attribute/property on every tracked event. There's no built-in helper for this specific to sessions — you'll wire it up in your own tracking code. 3. What the Page View event should look like It just needs

event_name: "Page View"

plus your

session_id

as an attribute, same as your

non_bounce

events — that's what lets the Fact Table join them on

session_id

. *4. Is there an existing GrowthBook session identifier to reuse instead of creating a new one? T*here isn't a built-in one. The closest thing is the

id

attribute from the auto-attributes plugin, but that's a longer-lived user identifier (persisted in a cookie), not a per-session one, so it won't give you what you need for session-level bounce rate. You'll need to create your own

session_id

.

Hi @flaky-noon-11399, Thanks for the detailed clarification. Since the A/B test is already around halfway through, is there any way we can calculate the bounce rate using the data collected so far? Before we introduce a new

session_id

implementation, I’d like to confirm whether there’s any existing identifier or event data in GrowthBook that we can use to reconstruct sessions for the historical data. We can implement the new

session_id

going forward, but I’d ideally like to avoid losing the first half of the test data if there’s a way to recover it. Could you please confirm what options we have for the historical data? Thanks!

Hi @thankful-television-69452 the historical data may still be recoverable if every

Page View

and

non_bounce

event contains a stable

user_id

,

device_id

,

anonymous_id

, or SDK

id

, together with reliable timestamps. If so, you can create a custom SQL Fact Table that groups events by that identifier, infers a new session after a chosen inactivity period such as 30 minutes, and marks the session as bounced when it contains a

Page View

but no

non_bounce

event. This will include custom SQL that exceeds the scope of support but the AI bot injected in our docs can give a code example of what the custom Fact table will look like for you then to progress to create the ratio metric

Hi @flaky-noon-11399 I checked the historical data. We have reliable timestamps and

device_id

, and

non_bounce

events are present. However,

session_id

and

user_id

are empty in the data I checked, and I haven't found a clear

Page View

event yet. So we can potentially reconstruct sessions using

device_id

and a 30-minute inactivity window, but we need to confirm which event should be treated as the

Page View

before we can accurately calculate the historical bounce rate.

Hi @thankful-television-69452 👋 The next step is to identify an event that fired for every eligible visit to the experiment page from the beginning of the test. Please can you confirm whether

checkout_page_view

fires immediately on every visit to the tested page, or only after someone progresses to checkout? Also, can you check whether the corresponding records in

experiment_views

contain

device_id

and timestamps for each visit. If either source gives us one record per eligible session, it can be used as the starting point for the Fact Table. However, if no event captured those visits historically, the exact session-level bounce rate cannot be reconstructed because the immediate bounces left no record; in that case,

100% − non-bounce rate

would only be an approximation for the existing data.