Application Management

Overview

A RUM application is a container for frontend performance monitoring data, used to collect, store, and analyze real user experience data from frontend applications. An application represents a monitored frontend project, which can be a website, mobile app, or single-page application.

We recommend creating RUM applications based on business systems or applications, such as: official website, e-commerce store, admin dashboard, etc.

Each application has its own unique applicationId and clientToken, used to identify data sources and ensure data security. After the application is created, you need to integrate the SDK into your frontend code to start data collection and monitoring.

Application Permissions

To meet the data security requirements of different business scenarios, RUM applications provide flexible access level settings:

Access Level	Visibility	Applicable Scenarios
Public	Visible to all users in the account, can view data and handle Issues	General business applications
Private	Only visible to creator, account administrator, and owner account	Sensitive business data

In private applications, if other members need to view content, they can be temporarily authorized to access it by sharing the incident link.

Create Application

You can quickly create an application through the RUM product guide page:

Select Application Type

Select the frontend technology type corresponding to the application, currently supporting JavaScript (JS), Android, iOS, HarmonyOS, Flutter, WeChat Mini Program, Electron, and React Native.

Set Management Team

Specify the management team for this application.

Team members have full operational permissions for this application, non-team members only have read-only access to the configuration of this application.

Configure Geo-information

By default, automatic collection of user geo-location data is enabled. To disable automatic collection of client IP or geo-location data, turn off the geo-information collection switch.See Data Collection.

Configure Alerts

By default, alert notifications are automatically enabled to facilitate timely handling of errors.See Issue Alerts.

SDK Configuration

You can modify parameters and preview the initialization code in real-time in Application Configuration > SDK Configuration to quickly integrate the SDK. The console provides detailed integration guides for each platform:

JavaScript (Web): After configuring parameters like service name, preview the flashcatRum.init() initialization code in real-time
Android: Shows complete integration steps including adding Gradle dependencies (cloud.flashcat:dd-sdk-android-core and cloud.flashcat:dd-sdk-android-rum), initializing the SDK in Application.onCreate() with RUM enabled, and optional WebView tracking integration
iOS: Shows complete integration steps including adding Swift Package Manager dependency (fc-sdk-ios, from version 0.6.0), initializing the SDK in AppDelegate.didFinishLaunchingWithOptions with RUM enabled, and optional WebView tracking integration
Flutter: The Flutter SDK wraps the Android/iOS native SDKs, so one integration monitors both platforms. See Flutter SDK Integration
WeChat Mini Program: Fill in env, service, version, and sessionSampleRate in the form, and the flashcatRum.init() snippet built on @flashcatcloud/miniprogram-rum is generated and previewed in real time (see “WeChat Mini Program SDK Configuration Assistant” below)
Electron: Provides a step-by-step integration guide — install @flashcatcloud/electron-sdk in the main process and complete initialization inside app.whenReady() (this must finish before any window is created; with the wrong ordering the SDK reports no error but collects no data). To capture page views, user actions, network requests, and JS errors inside your windows, optionally integrate @flashcatcloud/browser-rum in the renderer process, whose data is handed to the main process over an IPC bridge for unified reporting. When bundling the main process with Vite / webpack / esbuild, you can also add the corresponding plugin to keep the SDK’s runtime dependencies. See Electron SDK Integration
React Native: Provides a four-step integration guide — install @flashcatcloud/mobile-react-native plus the view-tracking package matching your navigation library (@flashcatcloud/mobile-react-navigation or @flashcatcloud/mobile-react-native-navigation) and run pod install; wrap the Metro config with withDatadogMetroConfig so release bundles and their sourcemaps carry a Debug ID; initialize the SDK as early as possible at the app entry (serviceName is required, otherwise Android and iOS split into two services); start automatic view tracking once the navigation container is ready. See React Native SDK Integration

Each platform’s SDK configuration page automatically fills in the current application’s applicationId and clientToken, so you can copy the code directly into your project.

Modifying SDK configuration in application management will not take effect in real-time on integrated clients. All configuration changes need to be updated in your frontend code and redeployed to take effect.

Service Definition

A service is an independent, deployable code repository that maps to a set of pages.

Monolithic Application
Micro-frontend/Multi-page Application

If your application is built as a whole, your RUM application only needs one service name.

flashcatRum.init({
  applicationId: 'YOUR_APP_ID',
  clientToken: 'YOUR_CLIENT_TOKEN',
  service: 'my-web-app'  // Single service name
});

If your browser application is built from multiple independent repositories, set different service names for different modules.

// Main application
flashcatRum.init({
  service: 'main-app'
});

// Sub-application A
flashcatRum.init({
  service: 'module-a'
});

WeChat Mini Program SDK Configuration Assistant

When the application type is WeChat Mini Program, Application Configuration > SDK Configuration displays a dedicated Mini Program integration wizard: fill in the form on the left and a ready-to-copy initialization snippet is generated on the right in real time.

Form Fields

Field	Description	Validation	Default
`env`	Environment variable, e.g. `prod`, `dev`	Letters, digits, underscore only; up to 24 chars	—
`service`	Service name; all events default to this tag	Letters, digits, underscore only; up to 24 chars	—
`version`	Version number, useful for filtering during analysis	Letters, digits, `.` only; up to 24 chars	`1.0.0`
`sessionSampleRate`	Session sample rate (percentage)	Integer in range `0–100`	`10`

No save action is needed — the preview snippet updates as you type. applicationId and clientToken are filled in automatically by the system; you do not need to set them by hand.

Two-Step Integration

Add Dependency

Install the SDK in your Mini Program project and run the npm build through WeChat DevTools:

npm install @flashcatcloud/miniprogram-rum

Copy the Initialization Snippet

Use the copy button at the top-right of the right-hand code block, then paste the generated snippet into your Mini Program’s app.js:

import { flashcatRum } from '@flashcatcloud/miniprogram-rum';

flashcatRum.init({
  applicationId: "<APPLICATION_ID>",
  clientToken: "<CLIENT_TOKEN>",
  service: "<SERVICE_NAME>",
  env: "<ENV_NAME>",
  version: "1.0.0",
  sessionSampleRate: 10
});

For the full SDK capabilities, collection toggles, and event reporting model, see WeChat Mini Program SDK Integration.

Link Integration

Link Integration lets you associate RUM events with external systems, such as distributed tracing platforms, log search, object storage that stores crash log packages, or internal troubleshooting systems. After you configure links, RUM generates jump links from the event type and event context and shows them as Related Links in event details. Link Integration is available from the Link Integration tab on the application details page and applies to every application type. Members with the RUM Application Update permission can add, edit, enable, disable, or delete link configurations.

Built-in Tracing

The built-in Tracing card is the default Link Integration entry. It links the trace_id on resource events to your backend tracing system.

Enter the jump link

In the Link Integration tab, find the Tracing card and enter the jump link for your tracing system. You can use the ${trace_id} variable in the link. RUM replaces it with the actual Trace ID from the resource event when it displays the link.For example: https://your-tracing-system.com/trace/${trace_id}

Enable Tracing

After you save the jump link, turn on the Tracing switch. The switch cannot be enabled until a jump link is configured.

Built-in Tracing only matches resource events, and it appears only when the event contains trace_id. The jump link must start with http:// or https://.

Add External Links

Besides built-in Tracing, you can add custom external links for different event types.

Add a link

In the Link Integration tab, select Add external link, then enter the link name and the jump link.

Choose applicable event types

Choose the event types where this link should appear. The supported types are Crash, Error, View, Action, Resource, and Session.A crash is an error event: selecting Error matches both regular errors and crashes, while selecting Crash matches only crash events.

Insert variables and preview

Insert variables in the Jump link, such as ${session_id}, ${error_id}, or ${trace_id}. The page previews the final URL with sample values so you can verify that the template matches your external system’s query format.

Setting	Description	Rule
Link name	External system name shown in RUM event details	Required
Applicable event types	Controls which RUM events show the link	Select at least one event type
Jump link	External system URL that can include `${variable}` tokens	Must start with `http://` or `https://`
Per-link switch	Controls whether this external link is active	Disabled links are not shown

Available Variables

Link Integration extracts variables from the current event context and substitutes them into the URL template.

Variable	Description	Common Event Scope
`${session_id}`	Session ID	Session, View, Action, Error, Resource
`${view_id}`	View ID	View, Action, Error, Resource
`${action_id}`	Action ID	Action, Error, Resource
`${error_id}`	Error ID	Error, Crash
`${resource_id}`	Resource ID	Resource
`${trace_id}`	Trace ID	Resource, built-in Tracing
`${application_id}`	RUM application ID	All events
`${service}`	Service name	Events that collect `service`
`${version}`	Version	Events that collect `version`
`${env}`	Environment	Events that collect `env`
`${usr_id}`	User ID	Events that collect user information
`${usr_name}`	User name	Events that collect user information
`${usr_email}`	User email	Events that collect user information
`${start_time}`	Start time of the current event detail query	Explorer event details, Error Tracking issue error samples
`${end_time}`	End time of the current event detail query	Explorer event details, Error Tracking issue error samples

Not every variable resolves on every event type. The editor validates availability against the event types you select: variables that cannot resolve under the current event types appear in the variable list as dashed grey chips, and hovering them shows which event types cannot resolve them.

Variable	Session	View	Action	Error/Crash	Resource
`${session_id}`	✓	✓	✓	✓	✓
`${view_id}`	✗	✓	✓	✓	✓
`${action_id}`	✗	✗	✓	✓	✓
`${error_id}`	✗	✗	✗	✓	✗
`${resource_id}`	✗	✗	✗	✗	✓
`${trace_id}`	✗	✗	✗	✗	✓
`${usr_id}`, `${usr_name}`, `${usr_email}`	✓	✓	✓	✓	✓
`${service}`, `${version}`, `${env}`	✓	✓	✓	✓	✓
`${application_id}`, `${start_time}`, `${end_time}`	✓	✓	✓	✓	✓

Availability is judged by whether the event type’s table carries the field, not by whether a particular event happens to have a value: available only means the event type can resolve a value, never that every event does. Crashes are error events, so they share the error column.

If the template uses a variable that cannot resolve under the current event types, the editor shows an inline warning below the input: when the variable appears in a query parameter, the whole parameter is dropped when the link is generated; when it appears in the path, the literal ${variable} text is kept. The sample preview (sample data) omits the sample values of unavailable variables, so the preview matches what production actually resolves.

Legacy configurations that select the All event type only guarantee ${session_id} among the ID variables (the “all” scope is the intersection of every event table’s columns). Prefer concrete event types so the editor can validate availability accurately.

Put optional variables in query parameters, for example https://logs.example.com/search?session=${session_id}&error=${error_id}. If a query parameter only contains a missing variable, RUM omits that parameter when generating the link. Missing variables in the URL path stay as the original ${variable} text.

When an event matches an enabled link configuration, you can open the external system from these locations:

RUM Explorer event details: the Related Links dropdown appears in the top-right corner for event details such as Session, View, Action, Error, and Resource
Error event details: matching related links appear as embedded cards in the details area, with copy and open actions
Issue error samples: matching related links appear below the error sample, so you can jump from an Issue directly to logs, tracing, or another troubleshooting system

Privacy Settings

Privacy settings allow you to control the scope of user privacy data collected by the RUM SDK, meeting data compliance requirements for different regions.

Setting	Description	Associated Fields
Geo-location Information	Controls whether to collect user country, province, city, and other geographic information	`@geo_country`, `@geo_province`, `@geo_city`
IP Address	Controls whether to collect user IPv4 and IPv6 addresses	`@geo_ip_v4`, `@geo_ip_v6`

After disabling geo-location or IP address collection, the related filter and analysis dimensions will no longer be available. Please adjust carefully based on your business requirements and compliance needs.

Remote Configuration

The Remote Configuration tab lets you adjust collection and privacy parameters online, without code changes or a new release. When enabled, the configuration on this page overrides SDK initialization settings. When disabled, clients fall back to their SDK initialization settings and data collection continues uninterrupted.

Remote Configuration is currently available for Browser, iOS and WeChat Mini Program applications. Other platform types will be enabled as their SDKs ship support.
On SaaS the feature is rolled out account by account. If the Remote Configuration tab is not visible on the application detail page, contact support to enable it. On private deployments it is available by default.

Configuration values

Field	Values	Description
Session sample rate	Integer 0–100 (%)	Percentage of sessions collected. Leave it empty to skip delivering this field; clients keep the value set at SDK initialization
Session replay sample rate	Integer 0–100 (%)	Percentage of sessions recorded by Session Replay. If empty, the SDK setting applies
Trace sample rate	Integer 0–100 (%)	A second session-level sampling pass within already-collected sessions, deciding which sessions inject trace headers into eligible requests; the outcome is consistent within one session. Overall trace coverage is roughly session sample rate × trace sample rate. If empty, the SDK setting applies
Replay privacy level	`mask` / `mask-user-input` / `allow`	Default masking of page content in Session Replay: `mask` obscures text and hides input values; `mask-user-input` keeps page text and hides only what users typed; `allow` records the page as it is. Loosening the level starts collecting content that was not collected before, and replays already uploaded cannot be retroactively masked. The console asks you to confirm again before publishing
Custom configuration keys	Key–value pairs typed as string / number / boolean / JSON	Delivered to clients together with the remote configuration and read by your application code; the platform does not interpret them. Up to 5 keys; each key name is at most 64 bytes (counted in UTF-8, not characters), each value at most 4 KB and nesting at most 3 levels (objects and arrays each count one level), and all custom entries together at most 16 KB

iOS and WeChat Mini Program applications also show the Remote Configuration tab, but their SDKs read only the session sample rate and custom configuration keys (neither platform has Session Replay; the other values are neither delivered nor effective). Every SDK has to opt in with remoteConfigurationEnabled: true at initialization (off by default; an application that has not opted in never requests the configuration). On iOS this requires SDK 0.6.0 or later, see iOS SDK Advanced Configuration.

Custom entries are delivered to clients and may be readable by end users. Never put secrets, access tokens, or personally sensitive information in them.

Conditional rules

Conditional rules are a protocol-reserved capability that the current console version does not yet let you edit: there is no rule editor on the page, and when you save a configuration the rules already stored on the server are passed through untouched — saving never clears them. Rule editing will open up in a later version. For reference, the protocol semantics: besides the default values, a configuration can deliver different values to different clients based on conditions —

Match conditions support the env, app_version, and sdk dimensions, ANDed with exact comparison; a dimension the SDK does not report can never match. Each match value is at most 256 bytes.
Rules are evaluated top-down and the first fully matching rule wins; its overrides are merged on top of the defaults, and fields the rule does not set keep the default values.
Each application supports at most 20 rules.

Publishing and activation

Before publishing, the page shows a per-field diff against the live configuration and lets you inspect the raw JSON. You can optionally fill in a change note (at most 255 characters, e.g. “lower the sample rate during the sale event”), which is stored on the version and shown in the change history. Publishing creates a new version.
Activation is fixed to next new session: sessions already running are unaffected, and new sessions gradually pick up the configuration — clients that support remote configuration usually finish switching within about 4 hours after a publish.
Immediate activation (the client ends the running session as soon as the new configuration arrives and starts a fresh one under it) is a protocol-reserved capability that the current console version does not offer; it will open up in a later version. For urgent situations — stopping an over-collection flood or ramping collection up right away — call the SDK’s stopSession() to end the current session so the configuration takes effect with the next one as soon as possible.
The protocol also reserves a refresh on foreground switch (refresh_on_foreground): when on, the client re-fetches the configuration every time it returns to the foreground instead of waiting for a poll. It is off by default — every client requesting at the same foreground moment concentrates load on the configuration endpoint, the same shape as a release herd — and is meant only for applications that genuinely need a change to land within minutes. The switch cannot be set in the console yet and will open up in a later version.

Version history and adoption

Change history keeps the most recent 50 versions; older versions are cleaned up automatically and cannot be rolled back to. Each entry shows who made the change and the change note (if one was left). You can revert any retained version to make it the current configuration; a revert also produces a new version.
A new version produced by a revert carries a content-equivalence label: if its configuration content is identical to an earlier version in the history, the history list marks it as equivalent to the earliest version with that content — a version-number jump does not mean the configuration content changed.
The rollout panel shows adoption and rollout progress across recently arrived sampled sessions, with status labels waiting for new sessions (just published, no session has started under the current version yet), in effect (some sessions have switched), recent sessions switched (every session that arrived in the window is on the current version), no configuration received (none of the recent sessions reported a configuration version — usually the SDK has remote configuration disabled or is too old), no data (no new sessions in the window), and no adoption detected (published for over about 8 hours and still not on the current version); slices that did not report a configuration version are labeled not reported (SDK too old or config never fetched). Clicking View details opens the event explorer on this batch of sampled sessions. When fewer than 20 sampled sessions fall in the window, the panel shows the actual session counts only and does not estimate shares (shares are extrapolated from the sample rate, which is meaningless with too few samples).

Delete Application

If you no longer need an application, you can find the delete button at the bottom of the “Basic Info” tab in the application details.

After deleting an application:

No new events will be received
The application’s Client Token will be immediately revoked
Previously collected RUM event data can still be manually exported, or you can contact the support team to restore the deleted application

This operation requires the RUM Application Delete permission.

Next Steps

SDK Integration Guide

Learn how to integrate RUM SDK

Advanced Configuration

Learn about advanced configuration options for the SDK

Analytics Dashboard

View and analyze RUM data

WeChat Mini Program SDK

Learn how to integrate the RUM SDK into a WeChat Mini Program

Quick Start

Analytics

SDK Integration

Performance

Error Tracking

Explorer

Session Replay

Best Practices

Others

Overview

Application Permissions

Create Application

SDK Configuration

Service Definition

WeChat Mini Program SDK Configuration Assistant

Form Fields

Two-Step Integration

Link Integration

Built-in Tracing

Add External Links

Available Variables

Privacy Settings

Remote Configuration

Configuration values

Conditional rules

Publishing and activation

Version history and adoption

Delete Application

Next Steps

SDK Integration Guide

Advanced Configuration

Analytics Dashboard

WeChat Mini Program SDK

​Overview

​Application Permissions

​Create Application

​SDK Configuration

​Service Definition

​WeChat Mini Program SDK Configuration Assistant

​Form Fields

​Two-Step Integration

​Link Integration

​Built-in Tracing

​Add External Links

​Available Variables

​View Related Links

​Privacy Settings

​Remote Configuration

​Configuration values

​Conditional rules

​Publishing and activation

​Version history and adoption

​Delete Application

​Next Steps

SDK Integration Guide

Advanced Configuration

Analytics Dashboard

WeChat Mini Program SDK

Overview

Application Permissions

Create Application

SDK Configuration

Service Definition

WeChat Mini Program SDK Configuration Assistant

Form Fields

Two-Step Integration

Link Integration

Built-in Tracing

Add External Links

Available Variables

View Related Links

Privacy Settings

Remote Configuration

Configuration values

Conditional rules

Publishing and activation

Version history and adoption

Delete Application

Next Steps