Set participant Connect ID in DataDog sessions for error tracking (PWA)

[JoeArmani]

I wanted to put this idea up for discussion after a quick DevOps chat last week @brotzmanmj @Davinkjohnson @anthonypetersen @we-ai.

Issue:
As the study grows and the PWA has more users, it becomes increasingly difficult to investigate individual technical issues in ConnectApp without a searchable identifier.

Current Process:
Currently, we drill down into issues based on times, expected user locations, and error types. This is reasonably effective for set geographic locations such as our lab and shipping locations (Biospecimen and SMDB). It is less effective in the PWA since participants are on the move and using mobile devices. As traffic increases, this will become increasingly challenging.

Possible Solution:
We can use DataDog's userID property to associate a participant's Connect ID with their DataDog's session. This would allow us to search for a session using the participant’s Connect ID instead of the lengthy drill-down process described above. We could take the same action with the user’s SSO email address in Biospecimen and SMDB (this is less important but would still help locate bugs and issues).

Legal:
We would need consent from participants based on GDPR and CCPA laws.

Implementation:
The technical implementation is straightforward. Associate the logged-in participant with the DataDog session after authentication.

// Code sample from DataDog below. We only need to set 'id' -> 'Connect_ID'

// set user
datadogRum.setUser({
    id: '1234',
    name: 'John Doe',
    email: '[email protected]',
})

// in our context this would get set after confirming authentication:
window.DD_RUM && window.DD_RUM.setUser({id: participant[‘Connect_ID’})

//clear user (important for public/shared computers)
datadogRum.clearUser()
``

[brotzmanmj]

@Davinkjohnson This sounds like a good topic to discuss with Martin?

[Davinkjohnson]

Hi Michelle, we didn't have time for it this week, and I wanted to circle back with the others before taking it to him. I have it on my list for next week.

[we-ai]

Thank you @JoeArmani for the information.
I'm not sure whether it's possible to make it easier to find related sessions:

• My impression is that currently we have many small issues logged in DataDog. If most of these small issues are fixed, will it be easier to find sessions to check?
• Because of legal issues, putting Connect ID into DataDog may take a while if we decide to do so. For the time being, can we use timestamps (UTC or ET timezone) as user IDs, so that we can narrow down sessions when doing searches?

[anthonypetersen]

Are timestamps not already included in these sessions? Also the time ranges we get back from participants in tickets aren't always the most accurate.

[JoeArmani]

Thanks, I appreciate both of your feedback.

Yes, timestamps are included in the session. Those are auto-recorded and filterable, so we have all the data we need there.

ServiceNow cases are the primary issue where session-finding can be very difficult:
• Cases reported in ServiceNow have fuzzy timing because of the reporting process - the participant experiences an error and then reaches out to support. From what I've seen, only a small percentage of participants take the time to reach out.
•Another aspect that adds to the complexity of ServiceNow cases is that many reported problems are not captured errors. We encounter a wide variety of browser-specific issues, ranging from actual errors (relatively easier to locate) to performance issues and browser-specific nuances (much harder to locate). This diversity of issues further complicates the session-finding process.
• I agree on the 'fixing errors' part, but I believe the errors are a small part of a larger issue to tackle since we have to handle a wide range of browsers, versions, & device types in ConnectApp (based on what I'm seeing in incoming ServiceNow cases).

I understand the legal aspect may make this challenging (and slow or not possible to implement), but I wanted to open this discussion so it's a known issue. Attaching Connect ID would make pinpointing (and recreating) the many nuanced issues much less of a guessing game.

[JoeArmani]

I liked @Davinkjohnson's suggestion in today's meeting about saving DataDog's session ID to the Firestore profile instead of saving Connect_ID to the DataDog session, so here's a quick exploration of that method:

•One difficulty with saving Session ID is locating participants with common names (this is a minor issue, just mentioning it). Email, Connect_ID, phone, less common first/last names, and full names make it easy to bridge this gap, so this depends on the information provided in the ServiceNow case. The important part is being able to:
(1) Look at a ServiceNow case.
(2) Find the participant.
(3) Get the session ID.
(4) Search that session ID in DataDog (this is built-in DataDog functionality).

•Another Session ID nuance: Initial testing shows this ID persists across tabs in a browser session, so we may have isolated cases where Session ID crosses over:
(1) on public computers where two participants are using the same computer & browser.
(2) on shares devices (e.g. family members sharing a tablet).
This is a very minor issue, IMO, just another thing to note.

Implementation:
DataDog generates a session ID for each user session.
Session ID is unique to the user's session, is not PII, and is filterable in DataDog.

    // This exposes DataDog's session ID.
    const context = window.DD_RUM && window.DD_RUM.getInternalContext();
    console.log('getInternalContext() -> session_id', context.session_id);
    // Example: 807f121b-de6d-4e22-be6a-399a31b08ec1
    // Write this to the user profile *just after authenticating*.
    // Save the previous 3? 5? 10? (we don't need to limit this quantity, but we could) to an array.

[anthonypetersen]

Do you feel there is an advantage to be gained by doing this over attaching Connect IDs to RUM Sessions in Data Dog?

[JoeArmani]

I don't have a strong preference here. I see attaching Connect IDs to RUM Sessions as a more direct approach. I think storing session IDs in Firestore is more in line with least privilege.

I think the differences are minor since Connect IDs are great for something like this. I mostly looked into this session ID method because of Martin's suggestion and Davin's mention in the meeting...I wanted to make sure there was a straightforward way to access that session ID.

How about you -- Do you have a preference?

[anthonypetersen]

Attaching the Connect ID feels like the more straight-forward approach and also feels like how Data Dog was "meant" to be used. Davin said he would discuss with Mia & Martin today. If they still have strong feelings against it I think your approach with Session ID would work fine.

[we-ai]

Regarding user information mapping, I see using session ID and Connect ID are almost the same. Both map back to users.

[JoeArmani]

Great. Sounds like we're all on the same page. Thanks for the input!

[Davinkjohnson]

Just so we have the documents shared by our Datadog reps.
https://docs.datadoghq.com/real_user_monitoring/browser/tracking_user_actions/
https://docs.datadoghq.com/real_user_monitoring/browser/advanced_configuration/?tab=npm#identify-user-session

[Davinkjohnson]

After discussing the options with Michelle and Martin, both were supportive of using the Datadog recommendation to pass Connect_ID to Datadog. @anthonypetersen @we-ai @JoeArmani I leave it up to the three of you to decide who will do this work, and when you think you'd like to try and fit it in.