🙏 Force session/replay session after RUM was initialised

[neomaxzero]

What are you trying to achieve, and what is your issue?
Imagine I have sample-rate configured at 0.0001%. I want to force datadog-RUM to send all collected data in a specific scenario.

Can this be done in the middle of a session after the SDK is initialized?

In my specific use case, I want to see many more details and traces from users going on a user journey.

[amortemousque]

Hello @neomaxzero,
There is currently no way to change the sample rate after the initialisation of the SDK, but it's an interesting suggestion we may consider in the future.

[neomaxzero]

Do you have any workaround for this at the moment?

[amortemousque]

Sorry for my previous comment, on second thought, since the sample rate determines whether a session is tracked or not, changing the sample rate in a middle of a session, would not really make sense. Can you explicit a bit more your need?

[samsaggace]

Hello,

I think I have the same need as @neomaxzero so I'll try to explain mine (and sorry if I'm wrong and thus hijacking the issue 😅 )

Let's take an example to explain the usecase :

• I use datadog RUM with 100% sessionSampleRate and 10% sessionReplaySampleRate (to reduce the costs)
• I've just released a new page, for example the settings page. On that specific page, I'm super interested to get 100% replay to monitor closely if everything goes well.
• From what I have experienced, calling datadogRum.startSessionReplayRecording(); is not enough to switch from a basic to a premium session: I will still be charged based on the sessionReplaySampleRate and not get any recording if not "sampled".

So in my use case, having a datadogRum.forceSessionReplay() that I can call, anytime after initialisation, when the user visits that settings page (or any other usecase) would be super useful.

Thanks

[GuillaumeNury]

Hello,
I have a similar need : I would like to use 10% sessionSampleRate. But whenever an error occurs, I would like to be sure to have this error in Datadog.
The SDK could collect everything and wait for a datadogRum.forceSessionReplay() to send the session to Datadog.

[amortemousque]

Hello @samsaggace and @GuillaumeNury, thanks for you feedback.
These use cases are currently not supported but are being discussed on our end. I'll let you know if there is any progress.

[neomaxzero]

@samsaggace @GuillaumeNury explained much better what I need. Thanks!

[Giroteti]

Hello everyone,
Any update on that?
Is forcing the replay to be recorded after datadog.init contemplated?
Thanks!

[samsaggace]

Hello,
@amortemousque do you have any update on this ?
we have tried initializing datadogRum later in our flow to choose if we want it recorded or not but have lost "resource" monitoring doing so...
So please, we really need to have something smarter that a sample rate to pick which session need to be recorded. 🙏

Thanks

[ischell]

We also have this need, though for us it would be enough if we could force the upgrade to a session replay RUM session at an arbitrary point in an existing Browser RUM session. We wouldn't necessarily need session replay to be retroactive, if it started from the forced upgrade point, that would be good enough.

[BenoitZugmeyer]

@ischell this will be possible with the next major version of the Browser SDK. Sessions will be "upgraded" to replay only when some replay has been recorded. We are still working on it, but it's coming.

[samsaggace]

Hello @BenoitZugmeyer,
That seems like a very good fix to my problem !
Any update on it ?
Do you have a rough idea on when it might be available ?

Thanks

[BenoitZugmeyer]

We are planning to release it in the coming weeks. This change was non-trivial and took more time than we expected. Thank you for your patience!

[samsaggace]

Hi @BenoitZugmeyer,
I've seen some v5 PR merged, do you have some visibility on the release date ?
Thanks

[bcaudan]

Hi,

[email protected] has been released, see the corresponding upgrade guide.

Only pay for Session Replay when the session captures a recording
In previous SDK versions, sessions are determined to be Session Replay sessions through the sampling mechanism. In v5, sessions are only counted as Session Replay sessions if a recording is captured during the session. This makes it easier to track your Session Replay usage.

Let us know if you have any feedback.

[samsaggace]

Hi @bcaudan, sorry I still have a question on how it will work.

Can you please tell me if I understood it correctly with this example:

If I set a sessionReplaySampleRate = 0 and for some new feature I want to test I do a datadogRum.startSessionReplayRecording();
It will start a replay session at that point and record it, right ?

[bcaudan]

With the v5, If you want to decide when to start the recording, you should set the new startSessionReplayRecordingManually option to true and call startSessionReplayRecording() when needed.
sessionReplaySampleRate controls which percentage of sessions could be recorded.

So with:

 init({
   sessionReplaySampleRate: 0
 }) 

No sessions can be recorded, regardless of the use of startSessionReplayRecording()

With:

 init({
   startSessionReplayRecordingManually: true,
   sessionReplaySampleRate: 100
 })

Only the session for which you call startSessionReplayRecording() will be recorded (and considered as Replay sessions on a billing perspective).

[ischell]

For us, I don't think this quite gets us where we need to be. It sounds like our only option for forcing session replay is to set session replay sampling to 100%, but to also set startSessionReplayRecordingManually to true, and only call startSessionReplayRecording if we hit some trigger condition.

What we were ideally looking for was to keep the existing partial sampling rate in place for sessionReplaySampleRate, but also have the ability to force the start of a session replay "upgrade" at some arbitrary point, and have assurance that doing so would get us 100% retention of session replays for the RUM sessions where such a forced ugprade took place.

[samsaggace]

To be honest, I was also expecting something similar to what @ischell explains, cf my previous question.
But at least we now have the possibility to develop what we want, so I think we will recreate a sampling algorithm to randomly start X% of recording.

[bcaudan]

Oh ok, so I may have closed this one too quickly then.
We did not have this specific behaviour in mind but we can look into it.

We'll let you know here if we make progress on this topic.

[mgpGit]

Hi @bcaudan -
Any update on adding this type of functionality that @ischell mentions? We would be very interested in this type of feature as well.

Thanks!

[robbiedhickey]

@bcaudan I'm trying to clarify the behavior of this feature following version 5 based on the discussions in this thread. Could someone verify if my understanding is correct?

1. To initiate manual recording of a session, the flag startSessionReplayRecordingManually: true must be included when calling the init() method.
2. When startSessionReplayRecordingManually: true is specified in the init() method, session replays will only be recorded if startSessionReplayRecording() is explicitly called.
3. Consequently, is it accurate to say that it’s not possible to both set a sampling rate for automatic session replay recording on a portion of sessions (for example, 10%) and simultaneously enable manual session recording to coexist?

Our use case is to enable 100% session replays for specific users when support issues arise, while still having a smaller percentage of all sessions recorded.

[bcaudan]

Hi @robbiedhickey,

The sessionReplaySampleRate define the percentage of tracked sessions that can be recorded for session replay.
At init, when a session can be recorded:

• by default, the recording starts automatically
• with startSessionReplayRecordingManually: true, the recording starts only after a call to startSessionReplayRecording()

So for now, the automatic or manual start of the recording does not have any influence on if a session can be recorded, it is fully controlled by the sessionReplaySampleRate.

For you use case, @ischell's suggestion should probably work, let us know otherwise.

For the suggested ability to start the recording regardless of the preset sessionReplaySampleRate, it is something that we plan to make progress on next quarter, we'll keep you posted here.

[Ky6uk]

Sentry has a cool feature that records the session in case of an error automatically. It's so useful for debugging but seems unsupported in the Datadog. According to this thread, I see it's even impossible to force session recording manually somehow.

[BenoitZugmeyer]

Sentry has a cool feature that records the session in case of an error automatically.

We are aware of this and we are exploring ways of doing something similar.

I see it's even impossible to force session recording manually somehow.

This is about to be released: #2777

[amortemousque]

Hello,
You can now force the Session Replay recording even on sampled-out sessions, using the DD_RUM.startSessionReplay({force: true}). It's available since v5.21.0.