Hey there, I am looking to implement a user retent...
# ask-questions
m
Hey there, I am looking to implement a user retention metric after viewing an experiment. I'm using:
Metric: Retention
Fact table: Events, Row filter: event_name = 'page_view'
However the lowest time I am able to set is: Event must be at least
1 Minutes
after experiment exposure Which effectively is
timestamp >= (exposure_timestamp + '1 minutes')
However, I wish I could use:
timestamp > (exposure_timestamp)
Note: not equal Is this possible with a fact metric?
h
Hi there! This is a great question... I don't think there is!
It's somewhat annoying, but you could create a separate fact table for this metric with a tiny permutation to the timestamp column
m
For some clarity, we are looking to have a metric that approximates "bounce rate" after being exposed
h
It's imperfect, but we could consider an option in the Retention metric setting.
And >= isn't good enough?
m
In this case, >= is close, but imperfect. We are looking at adding a modal to a certain page. We intend to track close events, but we want to know if someone closed the page (not the modal) without further action. Hence, us looking into a bounce rate metric.
h
I see. So you need to rule out any concurrent events.
m
I'd even be happy with
>=
current_timestamp. The real problem is the 1 minute fidelity is not quite low enough for us to feel like the metric is an effective approximation of bounce rate
h
Ok you can do that just with a proportion metric.
That's just a retention metric with no window.
You could even choose to filter out some events that may be concurrent that you want to ignore
m
i.e. a metric like:
Copy code
SELECT
  `user_id` AS user,
  1 AS value
FROM
  `Events`
WHERE
  (event_name = 'page_view') AND
  -- Only after seeing the experiment
  timestamp >= exposure_timestamp
GROUP BY user
HAVING
  COUNT(*) > 1
Correct?
h
Yep I don't think you need the user filter, since if they have 0 rows they'll be a 0
So the COUNT(*) isn't needed
m
Ah, I see. I wasn't sure the page_view event in GA would fire before the experiment, but I know it will in our system. Thanks for the help! One last question which is really me rubber ducking to you: Our GA4 session lifetime is 30 minutes (sliding with each page_view). I assume it may make sense to limit to the conversion window? i.e.
Copy code
-- Only after seeing the experiment
  timestamp >= exposure_timestamp AND
  -- Conversion Metric Window
  timestamp < (exposure_timestamp + '30 minutes')
If a user comes back days later we they would be outside the concept of a "bounce".
h
Can you explain what you mean by "session lifetime is 30 minutes"
Bounce is kind of the inverse of this metric, right?
👍 1
m
Yes you are right, this is the inverse of a bounce. "session lifetime is 30 minutes" is meaning that our GA setup will only consider a user the same person for 30 minutes. if they leave and come back an hour later GA should treat them as a new session, not returning
h
Got it.
I actually think you can do the following
Screenshot 2025-11-21 at 12.44.25 PM.png
Instead of Activity rate and then implicitly taking 100% - that number, you can instead just ask the question "What percent of users had 0 events (or 0 of a certain kind of event like a page view)" after the exposure event?
💙 1
I think your 30 minute window could make sense, but if they come back with a different ID then it won't matter. If they come back with the same ID and you want to consider bouncing not doing anything in the next 30 minutes, then yes you need that conversion window.
👍 1
m
Thanks this helps clarify a lot. I would recommend thinking about how something like this could be made easier with the retention metric UI. Obviously this is all hyper configurable, but my first gut check was to try the retention metric
h
I would recommend thinking about how something like this could be made easier with the retention metric UI.
Yep, reasonable.
We keep adding stuff here and are considering a different UX to help people do the job at hand rather than such a literal representation of how things work under the hood.
m
As someone who is capable to write the sql, I appreciate not having to think too hard and focus on the code changes rather than writing metrics. I appreciate all the work you all have put in!
h
Yep, thanks for your feedback.