-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When two tabs are open, the resulting session recording can merge the two tabs. #6522
Comments
After putting more thought in this this issue, I think there's a bit of complexity to this scenario. The simplest approach would be to create a new However, it has a big problem: If we have multiple recordings happening for the same user at the same time (as we often would if recordings are split by tabs), then we would have no way to determine which recording shows X event happening. (the best that we could do is "check these X recordings to see that event") I see two possible solutions of varying levels of work: Option 1I think a full/proper solution involves:
Having data in this form would allow us to definitively state which recording shows which events occurring. And we could build a UX where overlapping recordings makes sense (e.g. a button that says 'view this user's other windows' if there are overlapping recordings.) From what I understand tackling #6005 and adding a session column to the events table is a significant undertaking. And it might be more work than it's worth right now. Option 2 (easier, but has some issues)We don't split sessions on new windows/tabs. Instead, we:
This solution seems less involved, but it doesn't handle a couple of cases:
I'm sure there are other solutions here that I'm not thinking of too. Would love to hear any thoughts you might have @macobo @paolodamico @mariusandra @alexkim205 |
Can we send a The player could then be smart enough to group recordings with a different |
I think the idea of the separate |
Makes sense to me: I'm thinking the work stages out as: V1 (stop the CSS bugs)
V2 (full support of multi-window recordings)
|
My 2c: The original intent for session_id was to be unique per tab, but seems like something misfired. Perhaps there's a way to make that happen still? |
That's a legitimately good complexity reduction 👍 Currently with a session_id + window_id combo we could anyway just capture stuff happening on the same device, not a session that was separately recorded on your phone... so we'd need to search for the user's other overlapping sessions anyway, if we want a good multi-tab playback experience. So splitting session_id and window_id doesn't get us far. |
Sticking with just session_id would definitely simplify things, and I love that. It looks like the change is pretty simple (store the session_id in session storage instead of local storage/cookies) I still think it'd still be a big win to tie events to a session_id, so that we can definitively say 'X event happened in Y session recording'. As we move to using session recordings in diagnosing causes, this will be important. While the problem exists today (when a user is on 2 devices), when we move to recordings being split by tabs/windows, I think it will be exacerbated. If it's as simple as simple as what @paolodamico mentioned above (add the session_id to the event properties and then we can extract that as a materialized column), then I'd say we at least start by tagging events with the info, and that sets us up to do the rest later. I think being backward compatible on the query is going to be a pain, so the more that we can get ahead of that issue the better. @macobo do you have thoughts on the materialized column approach here? I don't know much about that. |
Making This will require us to redefine a "session" as a recorded session, and not "all events by a user not more than 30min apart", like most competitors do, so that also LGTM. |
This is also very cool because then it aligns Paths to session recordings as well: We can get rid of the 30 min apart semantics there and defer to unique |
Nice - @neilkakkar are paths calculated as being within a single session right now? |
Maybe missing something, and maybe this is just a naming thing, but I would advocate not to do the In terms of session-based analytics, if a user is operating on two separate tabs that is still pretty valid as a single session. |
This issue will never end 😅. It's a naming thing. We decided to rename "session" to not mean "any event anywhere for the user", but "events connected to this browsing session". Then in the player and other views we have a clear separation on what's part of the recording, and what are other events the user also performed at this time (other sessions in other tabs or devices, server events), which we'd query for and show with less emphasis. You're worried calling this "browser tab session" a "session" will confuse users doing "session-based analytics" (that's just |
@paolodamico @alexkim205 and I just spent some time chatting about this one - a lot of nuance here! The conclusion that we came to is that we're going to add
A row in the user's "recording list" is based on the Reasons we landed here:
Alternative
@clarkus I'd love to talk about what a playback experience that supports multiple tabs/windows could look like. I'm in favor of starting as simple as possible and moving from there. |
I'll have to think about that a bit. Given that a user can only focus on and trigger events in one tab at a time, it seems like we'd have to communicate tab switches or other context changes as promoted events. The question would be how do we do that in an obvious way. I'll think about it a bit. Happy to chat about it as well. |
Bug description
I think this is happening because we're sharing the session_id across tabs
Expected behavior
We'd have a separate session recording per tab
Thank you for your bug report – we love squashing them!
The text was updated successfully, but these errors were encountered: