RUM SDK Advanced Configuration

Overview

FlashDuty Real User Monitoring (RUM) provides various advanced configuration options that allow you to modify the collected data and context according to your needs, supporting the following scenarios:

Protect sensitive data: Mask sensitive data such as personally identifiable information.

Associate user sessions: Link user sessions with internal user identifiers for support and troubleshooting.

Reduce data volume: Reduce RUM data collection through sampling to optimize costs.

Enhance context: Add richer context information to data beyond default attributes.

The following sections detail how to implement these features.

Override Default RUM View Names

The FlashDuty RUM browser SDK automatically generates view events when users visit new pages or when URLs change in single-page applications (SPAs). View names are calculated from the current page URL by default and automatically remove variable IDs (path segments containing numbers). For example, /dashboard/1234 and /dashboard/9a are normalized to /dashboard/?.

You can manually track view events by setting the trackViewsManually option and specify custom names for views as well as associated services and versions.

Configure Manual View Tracking

When initializing the FlashDuty RUM SDK, set trackViewsManually to true:

After enabling manual tracking, you need to call the startView method for each new page or route change (for single-page applications) to start a view. RUM data will begin collecting when the view starts. You can add context to the view and its child events.

Parameter Description

name (string): View name, defaults to the page URL path.

service (string): Service name, defaults to the service specified when creating the RUM application.

version (string): Application version, defaults to the version specified when creating the RUM application.

context (object): Additional context for the view, applied to the view and its child events.

Example: Manually Track Checkout Page View

The following example manually tracks a checkout page view in a RUM application, using checkout as the view name and associating it with the purchase service, version 1.2.3:

React Router Integration

For applications using React Router v6, you can override default view names to match route names defined in your React application with these steps:

Set trackViewsManually to true during initialization (as above).

Start views when routes change using the useLocation and matchRoutes APIs from react-router-dom.

Here's an example:

Set View Name

Use the setViewName method to update the current view's name without starting a new view. The changed view name affects the view and its child events (from the moment of the call onwards).

Enrich and Control RUM Data

The FlashDuty RUM browser SDK automatically captures RUM events and populates their main properties. With the beforeSend callback function, you can intercept and modify events before they are sent to FlashDuty, supporting the following operations:

Enrich events: Add additional context properties.

Modify events: Change event content or mask sensitive information.

Discard events: Selectively discard specific RUM events.

The beforeSend callback accepts two parameters:

event: The event generated by the RUM browser SDK.

context: The context that triggered the event creation.

Context Types

Different event types correspond to different contexts:

View: Location object.

Action: The triggering Event and handling stack.

Resource (XHR): XMLHttpRequest, PerformanceResourceTiming, and handling stack.

Resource (Fetch): Request, Response, PerformanceResourceTiming, and handling stack.

Resource (Other): PerformanceResourceTiming.

Error: Error object.

Long Task: PerformanceLongTaskTiming.

Enrich RUM Events

You can add context properties to events through the beforeSend callback. For example, add data from response headers to resource events:

You can also add properties to events through the global context API. Note: Only properties in event.context will be recognized by the RUM SDK.

Modify RUM Event Content

You can modify event content through beforeSend, for example, masking email addresses from view URLs:

Modifiable Properties

The following properties can be modified through beforeSend:

view.url (string): Current page URL.

view.referrer (string): Previous page URL.

view.name (string): Current view name.

view.performance.lcp.resource_url (string): Resource URL for Largest Contentful Paint (LCP).

service (string): Service name of the application.

version (string): Application version.

action.target.name (string): Element involved in user interaction (only for automatically collected actions).

error.message (string): Error message.

error.stack (string): Error stack or supplementary information.

error.resource.url (string): Resource URL that triggered the error.

resource.url (string): Resource URL.

long_task.scripts.source_url (string): Script resource URL for long tasks.

long_task.scripts.invoker (string): Name of the invoking script.

context (object): Properties added through global context API, view context API, or manually generated events (such as addError, addAction).

Modifications to other properties will be ignored.

Discard RUM Events

By returning false in beforeSend, you can discard specific RUM events (except view events):

User Sessions

By adding user information to RUM sessions, you can:

Track specific users' browsing paths.

Understand which users are most affected by errors.

Monitor performance for key users.

User Attributes

The following are optional user attributes, but it is recommended to provide at least one:

usr.id (string): Unique user identifier.

usr.name (string): User-friendly name, displayed by default in the RUM UI.

usr.email (string): User email, displayed if no name is provided.

You can also add additional attributes, such as user plan or user group information, to enhance filtering capabilities.

User Session API

Set User Session

Get User Session

Add/Override User Properties

Remove User Properties

Clear User Session

Note:

After user session information is changed, subsequent RUM events will include the updated information.

After logout (calling clearUser), the last view will still retain user information, but subsequent views and session-level data will not.

Sampling

By default, FlashDuty RUM collects data for all sessions. You can use the sessionSampleRate parameter to set a sampling rate (percentage) to reduce the number of sessions collected. For example, to collect 90% of sessions:

Sampled-out sessions will not collect any page views or their related telemetry data.

To comply with privacy regulations such as GDPR and CCPA, FlashDuty RUM allows setting user tracking consent status (trackingConsent) during initialization. Available values:

"granted": Begin collecting data and sending it to FlashDuty.

"not-granted": Do not collect any data.

You can change the consent status after initialization using the setTrackingConsent API:

Changing from "granted" to "not-granted": Stops the RUM session, and data is no longer sent.

Changing from "not-granted" to "granted": If there is no active session, a new session is created and data collection resumes.

Note: Consent status is not synchronized between tabs or persisted; you need to provide the user's decision during initialization or through setTrackingConsent.

View Context

View event context can be modified. You can add or modify context for the current view and its child events (such as actions, errors, timings) through the following APIs:

startView: Specify context when starting a view.

setViewContextProperty: Add or modify a context property for the current view.

setViewContext: Replace the context for the current view.

Example: Add View Context

Example: Replace View Context

Error Context

When capturing errors, you can attach local context to error objects through the dd_context property, and the RUM SDK will automatically merge it into the final error event context.

Global Context

Global context is attached to all RUM events and supports the following operations:

Add Global Context Property:

Remove Global Context Property:

Replace Global Context:

Clear Global Context:

Read Global Context:

Context Lifecycle

By default, global context and user context are stored in the current page's memory, meaning:

They are not retained after a full page refresh.

They are not shared between different tabs or windows.

Enabling the storeContextsAcrossPages option stores context in localStorage, supporting:

Context retention after page refresh.

Context synchronization between tabs under the same domain.

Example:

Limitations:

It is not recommended to store personally identifiable information in context, as localStorage data exceeds the user session lifecycle.

Not compatible with the trackSessionAcrossSubdomains option, as localStorage is only shared within the same domain.

localStorage capacity is limited to 5 MiB, so ensure that the total of application data, FlashDuty context, and other third-party data is within this range.

Micro-frontend Support

FlashDuty RUM supports micro-frontend architecture by identifying event sources through the stacktrace mechanism. You need to extract service and version properties from application file paths and filenames.

Usage

Override service and version properties in beforeSend based on stack information:

In the RUM browser, you can filter events using the service property.

Limitations

The following events cannot be attributed to specific sources and therefore do not contain handling stacks:

Automatically collected action events.

Resource events other than XHR and Fetch.

View events (can be resolved by overriding view names).

CORS and CSP violation events.

Connect RUM and Traces

The APM integration with Real User Monitoring allows you to link requests from your web and mobile applications to their corresponding backend traces. This combination enables you to see your full frontend and backend data through one lens.

Use frontend data from RUM, as well as backend, infrastructure, and log information from trace ID injection to pinpoint issues anywhere in your stack and understand what your users are experiencing.

Usage

Initialize the RUM SDK. Configure the allowedTracingUrls initialization parameter with the list of internal, first-party origins called by your browser application.

allowedTracingUrls matches the full URL (<scheme>://<host>[:<port>]/<path>[?<query>][#<fragment>]). It accepts the following types:

String: matches any URL that starts with the value, so https://api.example.com matches https://api.example.com/v1/resource.

RegExp: executes a test with the provided RegExp and the URL.

Function: evaluates with the URL as parameter. Returning a boolean set to true indicates a match.

Considerations

Ensure correct configuration of applicationId and clientToken to avoid data upload failures.

Adjust sampling rate and privacy settings according to application requirements, balancing data volume with compliance.

For micro-frontends or complex frontend frameworks, it is recommended to implement startView logic at the framework routing level.

More Information

For more detailed information about FlashDuty RUM, visit FlashDuty SDK.

Advanced Configuration

Overview#

Override Default RUM View Names#

Configure Manual View Tracking#

Parameter Description#

Example: Manually Track Checkout Page View#

React Router Integration#

Set View Name#

Enrich and Control RUM Data#

Context Types#

Enrich RUM Events#

Modify RUM Event Content#

Modifiable Properties#

Discard RUM Events#

User Sessions#

User Attributes#

User Session API#

Set User Session#

Get User Session#

Add/Override User Properties#

Remove User Properties#

Clear User Session#

Sampling#

User Tracking Consent#

Example: Handling User Consent#

View Context#

Example: Add View Context#

Example: Replace View Context#

Error Context#

Global Context#

Context Lifecycle#

Example:#

Limitations:#

Micro-frontend Support#

Usage#

Limitations#

Connect RUM and Traces#

Usage#

Considerations#

More Information#

Overview

Override Default RUM View Names

Configure Manual View Tracking

Parameter Description

Example: Manually Track Checkout Page View

React Router Integration

Set View Name

Enrich and Control RUM Data

Context Types

Enrich RUM Events

Modify RUM Event Content

Modifiable Properties

Discard RUM Events

User Sessions

User Attributes

User Session API

Set User Session

Get User Session

Add/Override User Properties

Remove User Properties

Clear User Session

Sampling

User Tracking Consent

Example: Handling User Consent

View Context

Example: Add View Context

Example: Replace View Context

Error Context

Global Context

Context Lifecycle

Example:

Limitations:

Micro-frontend Support

Usage

Limitations

Connect RUM and Traces

Usage

Considerations

More Information