View recording(s) relevant to selected person that dropped off at/completed funnel step

[Twixes]

Is your feature request related to a problem?

Thanks to the persons modal, I'm able to see what people dropped off at/completed funnel step. I have the identity this way, but I don't actually know why they did what they did and in what circumstances.

Relevant issues:

• Interconnect more analytics features #3765
• Where did they go when they dropped off the funnel #5342
• Paths - Diagnosing Causes #5545
• Quantitative analysis - Diagnosing Causes #5543

Describe the solution you'd like

We have this button "View details" currently, but it works very poorly (#5326) – let's rename to it to "View sessions" and make it work. It should take you to the Sessions page and show sessions in which the funnel was entered and progressed through (possibly multiple since funnels can easily cross session boundaries). Sessions with recordings should have play buttons.

The core issue seems to be that the Sessions page is day-by-day, and many funnels are set up for longer periods, so this limit will have to be lifted. I believe it was put in place to avoid performance problems, but it should be just fine for a single person.

One worry of mine is that the Sessions page experience is a bit weird due to conflating 2 really different pieces of data: calculated sessions and session recordings (see #4884) – hence a session can have multiple play buttons. That's for a different issue though.

Issues to watch out for implementation-wise here:

• Sessions filter by user distinct ID doesn't work #5447 – bug that may or may not cause issues with filtering by person, will see
• Filter for people with session recordings on persons modal #5173 – feature that would be great to get in too, as sessions with recordings are particularly relevant for figuring out the why

Here's a relevant design posted by @clarkus in #5326:

It's really interesting, but I think we'll have to go for something slightly different, as:

1. We've dropped the persons count in Hide "person count" in person modal #5559 to avoid small glaring inconsistencies.
2. A single "Watch" button is not tenable in practice due to problems laid out above and in What is sessions page? #4884. I think eventually it will be possible, but for now I'd rather enable this via properly working "View sessions".

Additional context

Part of "Diagnosing Causes".

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

[clarkus]

Here's a quick update that visualizes the proposed changes to the persons modal.

[macobo]

Another ticket: #5173

We have this button "View details" currently, but it works very poorly (#5326) – let's rename to it to "View sessions" and make it work. It should take you to the Sessions page and show sessions in which the funnel was entered and progressed through (possibly multiple since funnels can easily cross session boundaries). Sessions with recordings should have play buttons.

Pushback: I think this is the wrong approach.

If the goal is for the user to view the recording why do we need a intermediary page? We're adding extra steps for the user to follow.

The sessions page is also kind of awful and doesn't solve real problems (currently), see #4884.

Instead, having a single "play" button which opens the relevant session recording in a new tab would solve the need much more directly.

Original design from @clarkus on the modal included this: #5173 (comment)

Implementation-wise this might be easier than including a "funnel step" filter in sessions - since if you have person_id and timestamp tuples in the paginated modal you just join them with session_recording_events to get the session id :)

[Twixes]

I agree on the one hand: the Sessions page being weird and an intermediary not being ideal.
On the other hand, the problem with a play button is that for each person there can be anywhere between zero and a few session recordings relevant to the funnel. The intermediary – the Sessions page – already handles this in a way (though as noted, it's not a great way) plus also shows computed session data, which may come in useful especially if there's no recording.

However, alright, let's limit this to just session recordings from the persons modal for now. So maybe:

• no button when there's no relevant recording
• a plain "Watch" button when there's a single relevant recording
• a "Watch" button that expands to show "Recording 1", "Recording 2" etc. on hover if there's more than one relevant recording

WDYT?
CC @clarkus

[Twixes]

After a chat with @mariusandra where we considered various possibilities and scenarios, we got back to my original idea from up top:
No play button, just "View sessions". The rationale is that for long-running funnels (e.g. a marketplace purchase flow spanning a few days), play buttons would be messy to display AND somewhat costly to compute.
We can however make it so that "View sessions" redirects to the person's Sessions page showing sessions that:

• started after or were ongoing when the person entered the funnel
• ended before or were ongoing when the funnel conversion window ended

[macobo]

(Was hoping to bring this to a sync chat with someone from product today but ditto)

From our users perspective:

• The end goal is to see what user was doing when they dropped off/finished that step/their journey through the funnel.
• They might watch 1 or 2 sessions or they might end up watching a whole bunch. ASSUMPTION: It's more geared towards the former, watch 1-2 sessions.
• They want to avoid rewatching sessions they've already seen

For these usecases, loading a separate page that loads separately and slowly is worse than just being able to see the session. Simpler flows lead to better "conversions".

From technical perspective:

• Performance isn't the blocker here. For paths we'll be operating the same way (person_id, timestamp) pairs and can make it work there, joining with recordings from person/timestamp pairs is simpler than what the sessions page is doing.
• More on performance: Sessions page would need to load all users (vs just 100) of those dropping off from the funnel and display them in order of time. That's again slow.
• Sessions page can only currently show sessions from a single date. Linking there is just increasing complexity for us since we need to then redo the sessions page first. I'd like to do that properly and not hack on features, see What is sessions page? #4884
• Sessions event list doesn't serve any real usecases - it's worth disregarding it.

I'm sure we can figure something out design-wise here to fit both of the buttons. Given that the main flow is sessions, maybe make the details link an icon and kill the person page link/hide it after expanding?

If we really really wanted to make "show all sessions" a thing IMO the right approach would not be to use the person modal - but instead open a dropbox with options "persons" vs "sessions" when user clicks on the datapoint. I don't see a reason for this though.

cc @mariusandra you might have other input here though.

[paolodamico]

Thanks for pinging me here. Some thoughts below (purely from a UX perspective, can't comment on feasibility/performance), happy to chat about it sync on Monday.

As it is today (even if we fixed the days filter), the sessions page provides little to no value to answer why. Value comes from watching session recordings. Therefore the only function of this page is showing session recordings in an organized way, but as @macobo points out, is this really necessary? Based on @Twixes suggestion too I think we could have something like shown below, let's take the user to the relevant part immediately. Users can still click on the person name to get taken to the person page to view more details there. Note this is a conceptual mockup, if we think it's in the right direction we should get @clarkus's input

[mariusandra]

Hey all, my chat with @Twixes focused on the question of what can we implement immediately that solves most of the pain points this modal/page has: I want to see what the users did while in the funnel, and when dropping off.

This pain is very clear: to see a recording of the user, I have to click "view person", which opens the sessions page, and then I must click "previous date" a dozen times before any recording shows up. I can't be sure if it's the relevant recording before watching it and might have to click "previous date" a few more times to find what I need.

Why is this daily pagination needed for person sessions? I understand how this view without pagination is heavy for "all sessions", but it should work just fine for one person? Thus the easiest fix is to remove the by-date pagination (for person/sessions only!) and just show the last X sessions.

Few considerations that push me towards this approach:

• I used to operate a marketplace where a "funnel" is a multi-day event. Booking submitted by A -> sent to B -> confirmed by B -> confirmation sent to A -> confirmed by A -> confirmation sent to B -> profit! This can include a large number of session recordings over various days. This means multiple session recordings are the norm, not the exception.
• Dropoff is like antimatter. What do we show if the user dropped off? If the last event (in a multi day funnel) happened a week ago, so should we just show the last recording with the last tracked event? All recordings after the last event? The answer is we can't be sure, and it's much easier to push this selection to the user by showing all recordings for this person.

Hence, to keep things simple, and not run into scope creep nor "hm, what about this case?" exceptions, I'd KISS and work to remove the daily pagination for sessions on persons. This will solve 90+% of requirements (you can even use filters to deep dive on the list) and unblock engineering resources we desperately need for other things. We'd then revisit this in the context of #4884

[macobo]

@mariusandra Thanks for sharing the context. Does the rest of the thread clear up the other proposal though?

The idea would be to link to recording directly from modal which:

1. For the user would avoid needing to wait Xs for sessions page to load as an additional step to get to recordings
2. We would not need to change sessions page. The "just get rid of date filter" is a tricky optimization problem as well which requires several days of work, not KISS at all. Also different ticket: Multi-day date filter in sessions #3471
3. Does not interfere with work for What is sessions page? #4884 (basically all work on sessions page will need to get rewritten)
4. Uses same technical context as paths linking we're already working on

The one additional thing that needs to be added:

1. Search for session recordings by (person_id, timestamp) pairs

This was distinctly different from what you mentioned using person details as an intermediary page.

[mariusandra]

The above makes it seem like the best way forward is to drop the day limitation and implement a frontend system that fetches today's, yesterday's, the day before's, etc session recordings and appends them to one big list. Then we'd have a "load more" button that searches further back when asked :). Probably 2h of work and problem solved :D.

[Twixes]

That would be the simplest thing, I agree @mariusandra
Thinking about this a bit more, one problem that I can see with both a plain list of recordings under a "Watch" button AND the sessions page as is, is that it's pretty hard to correlate these recordings with relevant funnel step events. That's because we keep it opaque when the funnel step events happened. So another option, possibly the best UX-wise (but definitely requiring more effort), would be designing new "View journey"-type UI that would show (for a specific person) session recordings interspersed with funnel step events.

[mariusandra]

To be clear, I don't think what I wrote above is the best way, but I think it's the "least bad" compromise that unblocks us here without requiring days of unguided engineering effort. (Unguided = we should probably be doing something else)

I like the "view journey" idea. One of the things the "session recordings" page as it is now is missing is a clear list of pages visited within the session, on the list page. I mean, when I open the session, I can see all the urls of the pages inside the session, but I'd like to already see this in the list to know which session to click, as it's so with one competitor I've used in the past:

(screenshot from their demo)

If we integrate such a list of urls into the list, we could add to this all the events that are also in the funnel, e.g. 1) view / 2) view /course/123, 3) view /book/123, 4) booking submitted event (was in the funnel!), 5) url /confirm/123, ...

[clarkus]

@paolodamico I am a 👍 on those proposed changes. Here's a quick redraw that aligns it with other recent work. We might be able to drop the word "session" from each item in the list. It's somewhat redundant.

https://www.figma.com/file/9yWtngNb1AIuf6KmXaEPJA/App-doodles?node-id=1085%3A137286

[paolodamico]

Love it! I think this is pretty aligned with what we talked about today. We'll have to get a ton of user feedback to make sure the recordings we expose, particularly when users drop off. Also worth clarifying, should we show the dropdown if we only have one recording? Thinking you're better off jumping directly into the recording?

[clarkus]

Love it! I think this is pretty aligned with what we talked about today. We'll have to get a ton of user feedback to make sure the recordings we expose, particularly when users drop off. Also worth clarifying, should we show the dropdown if we only have one recording? Thinking you're better off jumping directly into the recording?

Yes thanks for asking. When one recording exists, we would change the component to a button with the label "watch recording".

[mariusandra]

👍 for above.

One implementation request though: these links should be clickable <a href='something'> links, not buttons that dispatch actions. I imagine CMD/CTRL-clicking a bunch of sessions to open in a new tab to be a very common use-case.

[benjackwhite]

Closing as outdated