Multiple RUM applications on the same domain

[bdox]

We have multiple separate RUM applications on the same domain and have noticed recently that RUM data from apps that are not the initial load has been declining. The application on the base url seems to be unaffected, but subsequent application have seen a drop off in RUM data. I noticed there is a new section in the troubleshooting document which says

There is a one-to-one relation between a RUM session and the RUM application it belongs to. Therefore, the domain set for the _dd_s cookie is fully dedicated to the RUM application it is monitoring and cannot monitor any additional applications.

Is there a workaround for this with how our apps are currently set up? We need the data segregation due to the size of these apps, and currently using subdomains is not possible.

example
www.domaim.com - app 1
www.domain.com/site/2 - app 2 (seeing drop off in RUM sessions)

[amortemousque]

Hello @bdox,
I have few questions to better understand your case:

• When did you see the drop off. Does it relates to an SDK upgrade?
• Also is you application using route change or initial load?
• Are you initializing the SDK for each route change?
• Can you give your SDK init config of your apps?

The main issue with having application by path is that the cookie we persist to track the session is isolated per domain not path. So you'll face some limitations. For instance, assuming:
app 1 : DD_RUM.init({sessionSamplingRate:100})
app 2: DD_RUM.init({sessionSamplingRate:20})
and if a user navigates from app 1 to app 2, only the sampling of the app 1 would apply.

[bdox]

• We've been noticing the missing sessions for a few (maybe 6) months.
• These are SPA apps, and I see views with both initial_load and route_change (edited)
• The SDK is initialized once.

init config (same for both apps), both set to 100% sample rate.

    applicationId: 'xxxx',
    beforeSend: beforeSendCallback,
    clientToken: 'xxxx,
    site: 'datadoghq.com',
    env,
    isCollectingError: false,
    service: 'xxxx',
    trackInteractions: true,
    sessionSampleRate: 100,
    sessionReplaySampleRate: 0,
    trackUserInteractions: true,
    trackResources: true,
    trackLongTasks: true,

We did observe that when navigating from one app to the next, if we manually delete the _dd_s cookie we get a new session, which is what we would expect to happen automatically. We've been using RUM for a few years, and this was not a problem previously.

[thomas-lebeau]

Hi @bdox ,

To mitigate an issue where some ad blockers were deleting the cookie every seconds, thus generating a large number of short sessions that customer were billed for, we are stopping the SDK if we detect something outside of the SDK is altering the cookie.

If you were altering the cookie to work around our one-to-one relationship between the cookie and rum applications, this might not work anymore. This was implemented roughly 6 months ago.

We need the data segregation due to the size of these apps

Maybe you could try to use the service field to achieve this segregation even though it might not work exactly as you wish.