Conclusion: We should rewrite or create a new sessions page. Changes include removing "sessions" and replacing them with one recording = one row, no list of events feature under the table.

More details under #4884 (comment)

I think it is worthwhile to revisit the concept of the sessions page from the ground up to support session recording and our users better.

Problem statement

Our sessions page is currently driving a 2 very different use-cases:

1. Users can see dynamically constructed sessions on this page and see what actions a user took on the page
2. Users can search and view interesting session recordings there (if enabled)

I'm not very confident in usecase (1) since I haven't heard users have great success with it.

In the current implementation, the two are often at odds with each other.

1. "Sessions" are constructed dynamically from events in the backend, while session recordings are tab-based.
   1. This may cause 0 or 2 or 5 different "session recordings" to show up under one "session". Or one session recording to show up under multiple sessions.
   2. Session durations may not match session recording lengths since the duration calculation (at least used to be) made based on the difference between first and last event.
   3. This can lead to a general feeling of "session recordings are missing"
   4. If autocapture is off users may end up with "invisible" session recordings if no normal events were captured.
2. Performance - "sessions" are expensive to calculate, while "session recordings" are relatively inexpensive
   1. Due to this, we currently only show sessions per day on the page. This in turn hurts session recording bad - if you're searching for a rare event you need to look through many pages.
3. "Sessions" discriminate based on distinct_id (and not person_id)
   1. So if a user logs in and their distinct_id changes as a result, events prior to login would be counted as a separate session
   2. It's currently unclear where the session recording would end up - under one of the sessions?
4. "Sessions" include backend-event only sessions which would not include any session recordings.
   1. If the backend uses a different distinct_id from clients javascript setup, the sessions are

What can we do about it?

I don't have a good answer. Some thoughts:

I think the trouble begins with the definition of "session" and "session recording" being different. One groups all events (including backend/mobile/others) into one, other uses an internal tab-specific id generated on the javascript client. We can't really use the tab-specific id for sessions without losing support for events outside posthog-js to be displayed.

Some sort of a "sessions" <-> "session recording" mapping is really useful, since it allows to search for recordings where some specific event happened and look up the specific time and we don't have that context from the recording itself.

Perhaps the solution lies in flipping the script - a separate page for session recordings which is inversely linked to sessions?

However more context for usecase (1) would be needed here.

Additional context

@paolodamico @marcushyett-ph @kpthatsme Food for thought product-wise.

This is a follow-up to https://github.com/PostHog/product-internal/issues/86.