Frequently Asked Questions

Date of slack thread: 6/4/24

Anonymous: We are starting to use session replays and noticed a few issues that we wanted to get more information on.

1. When someone is logged out and then logs in, they are shown as two different session replays. How does the session replay get tied to a user? Can we do something to tie logged out to logged in use case to the same user? We use magic links to login
2. We use modals within our application and it looks like modals aren’t shown in the session replay. Is there something we can do to get it to show?

Anonymous: So as long as I keep the same identifier for logged in and logged out then we should be good, right?

Anonymous: For modals, we are using bootstrap modals and they are not showing?

Matt Garnes (Statsig): Hey <@U06SNDL186A> thanks so much for trying out session replay! Yes, my expectation is that if you call initialize twice, once without a user ID (we generate an ID called a stable ID for that user then) and then again with a new user ID after login, the session should continue. If it isn’t, we can help you debug! <@U01TL1146PJ> knows a bit more about how the SDK handles this.

Matt Garnes (Statsig): As for the modals, unfortunately that’s a little bit harder. We rely on the “rrweb” open source project to do the recording, and it’s a little bit of a black box. I can see open github issues from where others have had similar problems: https://github.com/rrweb-io/rrweb/issues/614. I’m sure it is heavily dependent on your website and the css you use. The open source community for rrweb has a Slack community where I can ask this question on your behalf and I’ll try to see if I can learn something!

Matt Garnes (Statsig): <@U06SNDL186A> I confirmed that sessions should work across logged in and logged out! You should initialize with a user object that does not specify a user ID when the user is logged out, then you can initialize again with a user object (or call updateUser) that specifies the identifier for your logged in user after they log in. But that should keep the session recording.

Anonymous: Matt, thank you for the reply. But what happens if we need to share a session recording when the application is spread across different apps under the same domain, and parts of it can be on different subdomains? Let’s say marketing-site.com -> login.marketing-site.com -> app.marketing-site.com. If we got it right, the property responsible for identifying the user in this case is stableID. stableID can either be auto-generated by Statsig and stored in Local Storage or provided as a custom value. Since the autogenerated one is stored in Local Storage, it cannot be shared across subdomains. For now, we tried creating a custom value, store it in the cookie and then retrieve it and use it in the Statsig initialization. I believe this was the recommended approach in the previous version of the client side JS SDK. With this approach, stableID is the same, but it starts a new session recording. The initialization of the new instance of client-side Statsig is inevitable, since these are different applications. Is it possible to preserve the session and session replay in this case?

Matt Garnes (Statsig): <@U07680H36C9> thanks for explaining! That totally makes sense. You’re right, we don’t support sessions across domains currently because we rely on local storage. We don’t have a way to make this work for you today. The best you could do is try to retrieve the session ID and pass it to your next domain and somehow insert it into local storage for us before our code runs, but I don’t recommend that, it sounds messy. What we can do is look into adding an API for you to pass it to our SDK via a statsig option when you initialize, but we will need to release a new version with this capability. <@U02P9J1F4TH> on our side said he would be able to do that soon, but can’t get to it right away.

Anonymous: Thank you <@U04LUNKG8N4> and <@U02P9J1F4TH> for your hard work. Yes, having more control over session initialization to have a continuous session on different domains/subdomains would be absolutely stunning. I think it would be great to have an opportunity to do something like (hope you don’t mind some pseudocode): example.com

  sdkKey,
   {
    customIDs: {
      stableID: "persistedCustomStableID"
    }
   }
  ...
)
// Retrieve session id from the client instance 
const statsigSessionId = client.getSessionId();
// Set sessionId in the cookies for all the subdomains 
cookies.set('statsigSessionId', statsigSessionId, {domain: ".example.com"});```
`app.example.com`
```const client = new StatsigClient(
  sdkKey,
  {
    userID: "someUserIdAvailableAfterLogin",
    customIDs: {
      stableID: "persistedCustomStableID"
    }
    // Set sessionId if available in cookies 
    ...(cookies.get('statsigSessionId') 
  ? {
    sessionId: cookies.get('statsigSessionId'),
   } : {})
  }
);```

**Matt Garnes (Statsig):** That sounds good! It would be something very similar to this! I'll let Daniel take a look from here.

**Anonymous:** Thank you Matt! Will be looking forward to updates. Please let us know if any further clarification needed. I think it could be a really great feature for everyone to have.

**Matt Garnes (Statsig):** Sounds good we can let you know!