Session-based debugging

[paolodamico]

Is your feature request related to a problem?

There are some apps for which it's more natural to understand user flows in terms of a session rather than a single stream of events. For these apps, understanding user actions in the context of a session is key. See customer context.

Describe the solution you'd like

Provide a way to analyze user behavior in the scope of sessions.

Describe alternatives you've considered

Only detailing the problem, not the solution.

Additional context

Thank you for your feature request – we love each and every one!

[timgl]

Customers who want this/are confused about why we removed it: https://posthogusers.slack.com/archives/C01GLBKHKQT/p1644572200354739 https://posthogusers.slack.com/archives/C01GLBKHKQT/p1644394948424269 https://posthogusers.slack.com/archives/C01GLBKHKQT/p1644919417919979

[timgl]

Since @rcmarron work on session recordings we now set a $session_id. It'd be pretty trivial to add a "Group by unique sessions" option so people can at least do a count of unique sessions.

[rcmarron]

Since @rcmarron work on session recordings we now set a $session_id. It'd be pretty trivial to add a "Group by unique sessions" option so people can at least do a count of unique sessions.

Definitely agreed that it doesn't seem too hard to do something quick here. With that said, fully supporting sessions feels like a project, but the work is pretty well known. Capturing a couple thoughts on what I think it would take:

Data capture:

We want $session_id to be added to all client events, and users to be able to configure what splits a session (have heard users ask for this on recordings + competitors offer it.)

• Add $session_id to the mobile libraries - right now, it's only in posthog-js. If we're going to prioritize this work, we should do this sooner rather than later.
• Make session splitting more configurable. Right now, in posthog-js a user can call resetSession() to generate a new session_id, but we should also make the time gap (currently 30m) configurable.

Sessions in insights:

Since we took this feature away, users have been asking for various session related questions. The big ones seem to be count of sessions + time of sessions.

• Sessions analysis that shows:
  • Avg. time of sessions where user does X over time
  • Number of sessions where user does X over time
• Paths query should be updated to use the $session_id if it exists (right now, it's still doing the 30m gap)
• Funnels should be given a "within a single session" conversion window option
• Question: should sessions be added to the persons modal?

Sessions view:

People are using the recordings page as a sessions page today. They click into a recording list and just scroll through the list of events (I've seen this often watching recordings of people using recordings). Some of these customers have asked to have event properties added there too. I've pointed users doing this to the events tab of the persons page, but that view doesn't allow them to explore "what else happened in a session where X happened" which is what they want to do. Technically, it seems pretty simple to add a sessions view (the query is just a simpler version of the existing recordings query). But I think there are some good product questions here:

• How would a sessions page interact with a recordings page? They're very similar. Maybe they're the same thing?
• How do we handle backend events? Other products have the concept of "out of session events". It's the events that happened by the same distinct_id in the time frame of the session, but without the session_id.
• What would a session view look like?

[paolodamico]

I'm a bit wary of doing this right now, even the low hanging fruit of the group by unique sessions could reintroduce confusion because the way a session is counted is not necessarily the same for every product. Session-based analytics seems very valuable, but we should explore more before diving into this. I can gather context on this so we can decide how to move forward. Thoughts?

[rcmarron]

I'm a bit wary of doing this right now

I think I'm on the same page here - it feels like there are other areas of the product that could use attention first.

With that said, I think adding session_id to all the client libraries now would be a smart way to set us up for success when we want to tackle this down the road. I could easily see us working on this in a couple months.

the way a session is counted is not necessarily the same for every product

I think this would pretty well addressed by the configuration stuff above. I already added the resetSession() function to posthog-js, and adding a configurable "time gap" is straight forward. Are there other ways of splitting a session that you've heard users want?

I can gather context on this so we can decide how to move forward. Thoughts?

This would be amazing.

[timgl]

I'm a bit wary of doing this right now

My first comment has 4 people just last week who are asking about session analytics. Is there a reason we think this isn't important/urgent? (Genuine question!)

[mariusandra]

• Add $session_id to the mobile libraries - right now, it's only in posthog-js. If we're going to prioritize this work, we should do this sooner rather than later.

@marcushyett-ph has been having success getting contributions for plugins. Perhaps we can offer similar bounties to add this to the integrations, plus groups support.

[rcmarron]

@marcushyett-ph has been having success getting contributions for plugins. Perhaps we can offer similar bounties to add this to the integrations, plus groups support.

I think getting someone to do this work with good iOS/Android experience makes a ton of sense (over us ramping up on it). But I think trying to get contributions from the community doesn't make as much sense when we have a clear spec of the work + a timeline we want it in.

I'd lean toward getting a contractor to knock it out - have we used any iOS/Android contractors in the past?

[rcmarron]

My first comment has 4 people just last week who are asking about session analytics. Is there a reason we think this isn't important/urgent? (Genuine question!)

This is a very fair question. I think it's pretty undoubtedly a valuable insight that users want. I think the hesitation to fix it right now is probably coming from a place of "wanting to get it right". And that's not a fix it in a day thing. My vote is to do a few things here in the following order:

1. Solve the immediate need by reverting the PR that removed the old sessions insight.
2. Add the session_id to all of the client libraries to set us up to do session analysis "right"
3. Tackle proper session analysis in the nearish future.

[marcushyett-ph]

Solve the immediate need by reverting the PR that removed the old sessions insight.

The old sessions insight was very rarely used, and from observing recordings - it appeared to confuse most people who ventured into it.

I would advocate for adding the ability to perform ad-hoc session analytics into trends - in the same way some of our competitors do - it feels more natural as part of trends rather than it's own insight (If this is feasible to do quite quickly)

Add the session_id to all of the client libraries to set us up to do session analysis "right"

I think this is worthwhile although if we document it well it doesn't need to be a blocker (other analytics products for example don't include in all of their backend libraries)

Tackle proper session analysis in the nearish future.

We should continue to grab context on this to work out what we need to build to solve the customer problem - feels like we have some good leads from the conversation linked above

[paolodamico]

• Just to clarify, sessions can solve two main problems: a) engagement metrics & b) debugging/troubleshooting (why are users behaving certain way). The original intent of this issue was to outline the problem for (b), but the user context here outlines the problem related to (a).
• I've started an early draft of an RFC to solve (a), https://github.com/PostHog/product-internal/pull/276 but we still need a lot more context from users. In particular, I'm not convinced this is a burning need for our users (more context needed).
• I would hold off on doing any changes until we have more context. Even doing @marcushyett-ph + @rcmarron proposal I'm guessing it'll take at least one sprint and cost of opportunity doesn't seem to justify it.

[marcushyett-ph]

@paolodamico what specific context do we need from our customers to define this as something worth spending a sprint on? The threads @timgl linked to are fairly compelling.

[marandaneto]

Android, iOS, Flutter, and React Native already set the $session_id to all events and rotate the session if the user kills the app or if the app is inactive in the background for more than 30 minutes. If this issue was Mobile only, we could close it as done. https://posthog.com/changelog/2024#session-based-analytics-added-to-ios-sdk