designcourse
designcourse copied to clipboard
leeper
Request for destroy/stop method
There is a scenario where I've come across where based on user cookie preferences, it would be ideal if datadogRum could be toggled on/off in a browser session. There looks like there is no API for something like stop, destroy, or uninitialized.
This would facilitate a good user experience without an interrupting full page refresh especially in SPAs.
Hi, I am having the same issue. We now have to do a page reload an only initialize datadog when consent has been given. Also in the service that uses datadog to send custum events it would be usefull to be able to check if datadog was initialized. What happens if you call datadogRum.addError without it having been initialized?
@remkoboschker I'm not sure to see how a way to stop the SDK from collecting data would help in your use-case. It looks like you rather need a way to start collecting data when consent has been given? In this case, I suggest to initialize RUM if/when consent is given. All method calls (like datadogRum.addError) are buffered and will be transmitted only once datadogRum.init is called. How does it sound?
Thanks, good to know all calls are buffered until init is called. People can revoke or change there consent from within the application. After a consent change there is no way to stop sending other than reloading.
Would buffering all session data impact performance (memory on an older phone) when init is never called?
Thank you for your reply
On 17 Jan 2022, at 17:02, Benoît @.***> wrote:
@remkoboschker I'm not sure to see how a way to stop the SDK from collecting data would help in your use-case. It looks like you rather need a way to start collecting data when consent has been given? In this case, I suggest to initialize RUM if/when consent is given. All method calls (like datadogRum.addError) are buffered and will be transmitted only once datadogRum.init is called. How does it sound?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
People can revoke or change there consent from within the application. After a consent change there is no way to stop sending other than reloading.
Ah, I get it now, it seems like a good use-case for a stop() method. We don't have any plan yet, but we definitely want to implement this API. We'll keep you posted!
Would buffering all session data impact performance (memory on an older phone) when init is never called?
The buffer is bound so it will not leak to much memory. Only the most recent 500 calls are taken into account during init.
+1 for the stop() method
Also on the same topic (cookie preferences management) but different solution:
if the datadogRum had a privacyMode which didn't set or read cookies, it could still be run in most cases where cookie consent is not given. Some SDK offer methods to set consent so that they can change the behaviour depending on it - it would be great to have something like this.
Just to be clear: you can already implement a "consent" strategy by initializing the SDK only if the user did opt-in:
if (userConsent) {
DD_RUM.init(...)
}
A stop method would stop data collection, but any data that was collected before calling it would still be sent to Datadog, so it wouldn't be that useful for privacy purposes.
@BenoitZugmeyer the use case is for when the user withdraws consent (via consent management pop up) after previously having consented. It's valid that data before them withdrawing consent should be sent to datadog - but we want to stop any additional data being sent while they are still on that page (particularly pertinent for SPA where you don't get full page refreshes very often) A workaround could be to force a page refresh if a user edits their consent settings but this adds friction
@BenoitZugmeyer My use case is a little different, yet similar. Let's say I have a problematic user, that has more issues than others. I would love to trace back all the user actions. Thus I would love to increase programmatically the sampling rate for specific users. However, since that is not prossible, once the client was initiated, I was thinking of restarting the client with a slightly modified config. To me start-stop would be an universal solution that would allow maximum flexibility in configuration
Hi there! We've been using browser logging and RUM SDKs and are really excited about how they have helped us build a better product by understanding our users experiences.
I wanted to add a strong +1 on needing better support for GDPR/tracking consent.
@BenoitZugmeyer is there a reason the browser SDK does not support setTrackingConsent like the other RUM sdks? eg https://docs.datadoghq.com/real_user_monitoring/flutter/setup/#set-tracking-consent
This seems to explicitly solve the problem that every single user of the browser SDK needs to solve, and by making it explicit, makes it much easier to discover how to handle consent. It seems like the current intended solution to rely on the event buffering in init. However, that doesn't seem to be documented in either the browser rum or logging SDK docs.
is there a reason the browser SDK does not support setTrackingConsent like the other RUM sdks? eg https://docs.datadoghq.com/real_user_monitoring/flutter/setup/#set-tracking-consent
Most of customers needs for now were to delay the init after user consent, which can be achieved by the workaround mentionned by Benoît. We definitely want to provide a more complete way to handle consent at some point but it had not been prioritised yet. I opened https://github.com/DataDog/browser-sdk/issues/2013 if you want to follow the progress on this topic.
Implementing a stop() method would be a great workaround to get DD_RUM working for micro-frontends where only a single sub-app is active at a time (somewhat related: https://github.com/DataDog/browser-sdk/issues/1225)
We greatly appreciate this option being made available in the browser-sdk
+1 This is something we're actively needing now, it boggles the mind how it's not been prioritised given GDPR / Consent management being a core pillar of web compliancy these days.
We have a different use case where clients install our widget on their website and we want to start recording a session once opened and stop once closed.
If we init on open, and stopSession on close, a new session will start again automatically when the user interacts with the webpage further, even if they never open our widget again. We really need a way to start/stop sessions manually so the surrounding website isn't polluting our data with irrelevant interactions and errors.
@scottalguire indeed your use case seems a bit different, let's discuss it here: https://github.com/DataDog/browser-sdk/issues/2490
