Upgrade data processing
- Latest Dynatrace
- How-to guide
- 8-min read
- Published Oct 23, 2026
Some processing configurations carry over automatically because RUM and RUM Classic share the same underlying settings, so changes in one apply to the other. Others require a dedicated setup in RUM, often via OpenPipeline or newly introduced settings. This page walks you through each configuration that requires action.
User action naming
What changed
In RUM Classic, you create naming rules (regular expressions or pattern matchers applied server-side) that override the auto-generated names of user actions. Each application has its own set of rules.
In RUM, user action names are derived client-side, and you control them in your frontend code instead of in the RUM settings. There is no equivalent to the classic rule-based naming configuration in the RUM settings UI.
Web frontends
In RUM, user interaction names are derived client-side from the HTML attributes of the element the user interacts with. The RUM JavaScript checks the element for attributes in a fixed priority order: aria-label, title, name, data-testid, placeholder, and id. This is the detected name and requires no configuration. For the full naming logic, see Customize UI element naming for user interactions.
When the detected name is not meaningful enough, you control naming through HTML attributes in your page markup:
data-dt-namesets a custom name for a specific element.data-dt-children-namesets a shared name for a container and all its descendants.
Mobile frontends
The mobile agent names automatic user actions following the template {interaction type} on {element name} on {view name}, for example, touch on Checkout on CartActivity. For details, see Concepts for mobile frontends.
- The element name is derived from the UI element that handled the interaction. Depending on the technology, this is the component type (Android, iOS), the text content (Flutter, React Native), or, if the element has no text, an accessibility label, such as a
Semanticslabel (Flutter) or theaccessibilityLabelproperty (React Native). - The view name is the screen where the interaction occurred. To change it, see Page and view naming.
- In React Native, you can also override the element name with the
dtActionNameproperty. - For workflows that the agent doesn't instrument automatically, you create user actions with a custom name via the API.
What to do
For web frontends
- Review the user action naming logic to understand how names are derived from your existing markup.
- For elements whose detected names are not meaningful, add
data-dt-nameordata-dt-children-nameattributes to your HTML. This requires a change to your frontend code.
For mobile frontends
- Make sure user interaction capturing is turned on for your frontend. See Configure user interaction capturing for mobile frontends.
- Review the naming logic for your technology: Android, iOS, Flutter, React Native, or .NET MAUI.
- For names that are not meaningful, adjust them in your app code:
- Add accessibility labels to elements without text (Flutter, React Native), or set
dtActionName(React Native). - Create user actions with a custom name via the API for multi-step workflows or interactions that automatic instrumentation doesn't cover.
- Add accessibility labels to elements without text (Flutter, React Native), or set
Verify the result
After deploying your changes, verify the resulting names:
- Go to
Experience Vitals > Overview. - Select your frontend in the Explorer view and select Analyze performance.
- Review the user actions table for a timeframe that starts after your change. Historical data isn't affected, because data in Grail is immutable.
Classic naming rules you have already defined continue to apply to RUM Classic data. They have no effect on user actions captured in RUM.
Page and view naming
What changed
In RUM Classic, Dynatrace detects pages and page groups automatically, and you can override them with the RUM JavaScript API.
In RUM, page and view names are derived automatically. For web frontends, the RUM JavaScript detects page.detected_name and view.detected_name from the URL and, for single-page applications, from the framework's navigation events. Dynatrace then derives page.name and view.name from the detected names, for example by replacing dynamic IDs with :id:. For mobile frontends, the view name is the screen name reported by the agent.
What to do
Review the pages, views, and navigations concept page to understand how RUM derives these names for your frontend. For mobile frontends, view names are assigned from the screen name reported by the SDK; see Concepts for mobile frontends for details. The view name is also part of the name of automatic user actions.
For web frontends
If the auto-derived names don't match your expectations, you can't set page.name or view.name directly, because Dynatrace always derives them from page.detected_name and view.detected_name. Instead, override the detected names in your frontend:
- Register an event modifier with
dynatrace.addEventModifier from the JavaScript API. - In the modifier, set
page.detected_nameand/orview.detected_nameto the value you want.
Dynatrace then derives page.name and view.name from your overridden values.
For mobile frontends
If the default screen names are not meaningful, set a custom view name via the API. See the view monitoring instructions for Android, iOS, Flutter, React Native, or .NET MAUI. The custom name is also used in the names of user actions that occur on that view.
Custom metrics
What changed
RUM Classic provides two ways to create custom metrics:
- USQL custom metrics: Session-level metrics derived from a saved USQL query, configured per application under Settings.
- Calculated metrics: Action-level metrics (for example, average action duration for a filtered subset of actions), also configured per application.
In RUM, both types are replaced by OpenPipeline-based metric extraction. Metrics are extracted from the user event stream via OpenPipeline processors and can apply across all frontends, depending on your configuration scope. Two extraction points are available:
- Event-level metrics: Extracted from individual user events (user actions, page loads, errors). See Extract a metric from user events.
- Session-level metrics: Extracted from user sessions at session close. See Extract a metric from user sessions.
Before recreating metrics, consider whether you still need them. In RUM, you can query user events and sessions directly using DQL in 
Dashboards and 
Notebooks, for example, with fetch user.events or fetch user.sessions combined with makeTimeSeries. Many use cases that previously required a dedicated metric can be covered by an ad-hoc or saved DQL query without any extraction setup.
What to do
- List your existing USQL custom metrics and calculated metrics in RUM Classic (Settings > Web and mobile monitoring > Custom metrics).
- For each metric, decide whether a DQL query covers the use case. If so, no metric extraction is needed.
- For metrics that require time-series storage (for alerting, long-term trending, or dashboard performance), re-create them as OpenPipeline metric extraction rules following the guides linked above.
- After migration, verify that the new metrics appear in Notebooks or Dashboards by querying
timeserieswith your new metric names.
RUM Classic USQL custom metrics and calculated metrics remain available while RUM Classic is active. You can run both in parallel while upgrading and remove the Classic equivalents once the new metrics are validated.
Error detection
What changed
In RUM Classic, you configure error detection per application: you can define which HTTP status codes count as errors, create custom error definitions, group JavaScript errors by pattern, and ignore specific errors or error classes.
In RUM, error capture is automatic. The RUM JavaScript captures request errors and JavaScript exceptions, and the mobile agents capture request errors, crashes, and ANRs. To report custom errors, use the sendExceptionEvent API, which is available for web and mobile frontends. Errors are stored in Grail and analyzed mainly in our dedicated 
Error Inspector app. The error detection rules you configured in RUM Classic continue to apply to RUM Classic data and have no effect on RUM error capture.
What to do
To report custom errors, use the sendExceptionEvent API:
- For web frontends, see the JavaScript API.
- For mobile frontends, see the error and crash reporting pages for Android, iOS, Flutter, and React Native.
Ready for more?
Once you have completed all steps for upgrading RUM data processing, continue with upgrading your permissions and segmentation configuration.