📚 Unlock the full potential of Digital Experience Monitoring with the new RUM experience

[paul_kapeller]

Digital Experience Monitoring (DEM) has become front and center within the observability space. That’s why customers have heightened demands to gain better visibility and analytics to better understand their end users’ experiences. At the same time, the landscape of web and mobile technologies is rapidly evolving and Google’s core web vitals and new mobile vitals have shaped the industry significantly.

As a leader in observability, Dynatrace is going to launch a significative upgrade to its current solution for modern frontend monitoring. The new RUM experience will allow users to gain even deeper insights, further optimize user experiences across devices and drive better business outcomes.

With this post, we’d like to inform you in advance about upcoming benefits and expected impacts, focusing on RUM and our new data model. We’re communicating details about the new apps and additional DEM enhancements in separate posts.

I’m sure you’re excited about what’s to come and at the same time, you can prepare your organization for the changes and actions required and ask any questions that come to mind when reading this. We will try our best to respond to them in a timely manner. The post including the FAQ section will be updated based on your feedback and questions.

Grail and the latest Dynatrace

We have seen how logs, business events, metrics and traces have benefited from being on Grail in the past 18 months. Starting in November 2024 (as part of an extensive preview program), your frontends will also be able to reap similar benefits. Existing as well as new use cases will be enriched with more data granularity, advanced querying capabilities and extended retention times on the new Dynatrace platform.

New RUM data model and Grail

The core of the improvement is a new, future-proof data model based on user and session events; which will subsequently be captured via a new OneAgent module, sent via an enhanced beacon protocol, ingested via OpenPipeline and stored into our new Platform and Grail. An event-based capturing approach allows us to unlock significant improvements in monitoring coverage as well as data analytics and AI. Events will enhance and elevate the value customers can gain compared to user actions today.

Key benefits

Real user monitoring data stored in Grail queryable via DQL will showcase a range of features designed to enhance your data analysis capabilities. One of the key features is extended retention of RUM data. This allows you to extend your individual retention time well over 35 days, providing a long-term view of your data trends.

In addition, we auto-capture all requests made by your frontend applications, including their W3C timings. These requests can then be monitored, analyzed and alerted on individually with the latest Dynatrace, offering a granular view of your frontend applications’ performance.

To help you better understand your end-users’ behavior, our new agent module can also auto-capture the main user interactions. This feature covers a variety of interaction types like clicks, scrolls, mouse-overs etc. provides better understanding for each interaction and navigation, enabling advanced user behavior analytics.

We’ve also made improvements to our data semantics and auto-enrichments. For instance, we will provide element context on user interactions and view-context on mobile performance data. This enhancement allows for a more straightforward but also in-depth analysis of your data.

If you’re running into property limits, our new event-based capturing and Grail will solve this. You can enrich +100s of properties on events and sessions to capture your individual context. With DQL, custom apps and custom anomaly detection, all this data is available at your fingertips. This feature allows for a more personalized analysis of your data.

Finally, if you’re unable to use cookies or don’t have a user session, there’s no need to worry. We are planning to also allow you to collect and analyze RUM data in session-less mode. This ensures that you can still gain valuable insights from your data, regardless of your ability to use cookies or establish user sessions.

Activation

Eligible existing customers (SaaS, access to Grail, DPS) need to actively decide to enable the New RUM Experience per frontend-level and environment-level settings.

New customers and tenants automatically receive the new RUM experience since July 2025 and are therefore included in the preview program by default.

After our GA in January 2026, all customers (SaaS, DPS) can enable the new RUM experience.

Technical impact of the activation

There’s no impact on the current capturing based on user actions on classic, therefore classic features, data ingest, metrics, dashboards etc. are not affected by its activation.

Web: Once the setting is enabled, additional configuration and capture code will be added to the RUM JavaScript. This will enable sending events to Grail in addition to existing data capture. It requires a minimum version of the RUM JavaScript. Despite the added capture code, the RUM JavaScript will still be smaller with better performance as we also invested in significant code cleanups and optimization. We are planning to provide evidence for this as well. Initial setup is documented here.

Mobile: OneAgent for mobile also requires a minimum version but as usual must be shipped together with the app first and downloaded by users before data is stored on Grail.

We are expecting an increased data volume sent from your end users’ browsers & mobile apps to Dynatrace as additional events and metadata are captured and are directly ingested into Grail where you can consume it within the latest Dynatrace.

Initial setup is documented here.

Consumption impact of the activation

RUM data ingest to Grail and also querying the data inside the upcoming new DEM apps on Grail will not be charged. Also, by default we store data for 35 days. Therefore, at GA in January 2026, no new billing mechanisms will be applied. Querying data (user events and user sessions) outside our core apps, hence in e.g. Dashboards, will be provided as early access and not charged neither. After early access period is concluded, we may introduce charging query outside of our apps.

Extended data retention is enabled upon request as part of a new preview program and within the preview period, not charged. Later on extended retention will be subject to DEM retain billing.

Availability

The new RUM experience is only available to customers on SaaS with access to Grail. A DPS contract (GA) is required.

Our preview program initially kicked off early November where we hand-picked the customers. Since March 2025 we gradually ramped-up the preview into a public format. Since July 2025, new customers and new tenants are enabled by default. The preview program is closed after Dec. 5th as we move towards the GA launch in mid-January.

Supporting material /contact

Public documentation is available and will be complemented and enriched gradually.

Please look out for updates on this post / comments from Dynatrace and public announcements and blog posts. Go ahead and make use of our in-product chat as well as approach your assigned Product Specialist, Customer Success Manager, Customer Success Engineer or Business Insights Analyst if you have individual questions. 

FAQs

• What will happen to user actions?
  • In classic apps (e.g. Dashboards Classic) and the current DEM features, user actions stay untouched – so zero impact on your metrics, analysis screens and dashboards.
  • On Grail, user actions will no longer exist in this form. The data currently found within user actions will be stored in separate events, so it will be way easier to analyze the information we capture. E.g. user interactions (e.g. clicks, scrolls etc.) are stored as user interaction events and web requests (e.g. document, xhr,…) as web request events. So any event can be analyzed and monitored with high granularity and full context. As an example, a web request includes properties like the page, full-URL, geolocation, response code, start and end-time, duration and more.  
  • To understand overall timings (e.g. of a page load) we are offering web vitals, and users can view resource loads and their timings in Notebooks or in an updated waterfall chart.
  • Also we'll reintroduce user actions to capture the duration and relationship of a user interaction and the performance.
  • Of course, we are listening to our customers' needs and use cases and will adapt our plans accordingly.
• How does the data model look like?
  • We will collect RUM events in the user.events table.
    • with details about requests, navigations, errors and user interactions including additional auto-captured properties. Some properties are captured by default and any RUM event will include them. Other properties are captured in addition depending on the type of data collected. E.g. a web request holds the http.response.status_code . On top of this, customers can enrich the events with their custom properties as well or send in custom RUM events via APIs.
  • We will generate user session aggregates stored as separate events in the user.sessions table.
    • With details about users, the session durations and more. The properties of a user sessions are based on RUM events captured.
  • For more information take a look at the semantic dictionary in our public documentation.
• Can I turn off ingest into classic and completely migrate to the new RUM experience?
  • No, currently you can’t turn off classic data ingest fur RUM . However, this will be possible in the mid-term.
• How do I know that the new agent module is active on my environment?
  • You can access the global RUM settings or any frontend application specific settings. If you have permission to read the specific setting you can check if it’s enabled or not. The information can be retrieved via the default settings API as well. Also you can access telemetry data stored on Grail – e.g. via Notebooks and query RUM events. The Experience Vitals app also gives you an overview of your monitoring coverage with the latest Dynatrace.
• What permission is required to turn on this new module?
  • Users who want to activate these modules and ingest to Grail need the permission to change the settings within the frontends (global or local). These are typically included in the monitoring admin permissions. From a technical standpoint, it is a Settings 2.0 schema.
  • In order to access RUM data stored on Grail, users require the appropriate access permissions to the latest Dynatrace, relevant tables and buckets.
• Due to the change of capturing, will there be metrics not available with the new RUM experience?
  • We continue offering built-in metrics based on current usage of metrics and customer feedback. We will add more over time. On top of this, customers can create any on-demand timeseries based on the events and their fields. In addition, OpenPipeline allows users to extract custom metrics on Grail.
  • Some metrics are currently not planned to be offered on the new Platform, either due to the data model changes or because they are substituted by another one.

[jegron]

Great, thanks for all this details. It helps communicate to customers what's coming.

[mark_forrester]

Wahoo, been waiting for this for what feels like a long time.

The DPS requirement is this DPS LA or DPS GA? We have DPS LA and currently blocked from using the new Kubernetes apps because of this.

[paul_kapeller]

In order to get access, DPS GA is required.

[dimitris_pistio]

Will it be possible to export live session data? The options to export data will continue to be a) API and b) the session export (streaming). What will be the limitations on those 2 export types?

[paul_kapeller]

Events are accessible through DQL immediately after they are stored. Hence, you can also make use of the Grail Query API to retrieve this data after its ingested. The above-mentioned RUM events are accessible immediately. The session aggregate event is stored after the session is finished and can then be fetched/exported thereafter. I'm sure, many of the use cases can be covered with the RUM event querying already.

[Dant3]

Hi, in the new datamodel, is there a plan to capture position of mouse? To allow to create ClickMaps/Heatmaps with that info?

[michalmajewski]

Yes, it will be possible. We have already started an internal project to evaluate the possibilities for this topic. It looks like the first step will be clickmaps visualizing most clickable elements. Heatmaps based on mouse movements will come later.

[Dant3]

I started to see in API and in a few widgets the "DTAQL" is there any open preview to check?

[paul_kapeller]

@Dant3 can you share a link as to where you discovered the API / the widgets mentioned? 

In general, our current plan for RUM is to kick-off a private preview program with hand-picked customers in October, followed by a gradual ramp-up of the preview in the following months. Any customer interested can either inquire through their account team or can comment here and we will follow-up with the customer individually. Please beware that there are selection criteria and therefore some candidates won't be able to participate in the preview program.

[Dant3]

When you migrate Dashboards with USQL showup talking about DTAQL in gen3 dash app, when we search for it we only found this on gen2 dash api. 

Thanks, will reach AE/SE to pass details of customer. 

[paul_kapeller]

Ok this is a different scenario. In your case, you can use the API to query user session data (with USQL). This API can be used within e.g. a Dashboard or Notebooks app. But essentially, it would query the data from user session storage and not from Grail, where we will store the data to in the next months. And where you can then directly use DQL (e.g. fetch user.events) to retrieve DEM data - with all its event fields and granularity and DQL functions available.

[Nick-Montana]

Hi,

"Finally, if you’re unable to use cookies or don’t have a user session, there’s no need to worry. We are planning to also allow you to collect and analyze RUM data in session-less mode. This ensures that you can still gain valuable insights from your data, regardless of your ability to use cookies or establish user sessions."

Interested in knowing more about this. Will OpenKit be receiving an update reflecting these changes? We have an OpenKit Java abstraction that bootstraps many of our organization's Spring services with the tool. We currently instruct users to create/end sessions for data ingest even though they aren't conventional "user sessions". Example is sendBizEvent() method is only obtained after the creation of a Session object

[paul_kapeller]

Hi,

great to hear this resonates with you. I mentioned this future possibility as there are more and more customers struggling to capture user sessions as they e.g. cannot use cookies. In addition, scenarios like the one you mentioned - basically ingesting events with a certain context but w/o a session, should be doable in future as it is also in line with our vision and value proposition of OpenPipeline. With OneAgent or potentially also with frontend Otel collectors.

However, as this is a completely new "space" for us, there's still a lot of research and conceptual work required, before we can actually offer this in our product. Right now, our focus is to cover our core DEM use cases on Grail. Then we will take a look at this field in more detail.

[Nick-Montana]

I should mention that it isn't necessarily a problem! Creating/ending sessions gives the bizevents a unique identifier. I imagine customers struggle with this because its not immediately apparent why the session-based data ingest behaves the way it does. It took me a while to grasp all the ins-and-outs of how OpenKit works

As I mentioned previously, our architecture is powered through SpringBoot and we have many business-critical services that are now using that sendBizEvent() functionality to send data into GraiI. I bet there are a lot of customers who may be in a similar situation of needing to send bizevents from the client-side application.

I feel like the OpenKit documentation could improve by tailoring the information to this audience. Perhaps another page in the public docs that explains the reasoning behind session-based data ingest (e.i session-id and useful session duration metrics) for business-critical backend services

[IanM]

Hi Paul, is there any update on when RUM metric availability in Grail will be GA? I see an October-24 timeframe is mentioned for some availability as an EA.  KR Ian

[paul_kapeller]

We can't share a GA date yet for RUM on Grail. However, next quarter the preview is planned to be broadened, hence a lot of customer can opt into RUM on Grail and the available metrics on Grail. Which use cases would you like to unlock with it?

[sivart_89]

@paul_kapeller we would definitely like to enroll in this, are we able to get this enabled?

[Dripto]

Hi @sivart_89  - thank you for your interest. If you could let your Dynatrace team (particularly the customer success manager) know, they will submit your request with some additional details on your behalf.

[9sagarelluru]

Thanks, Paul, for sharing more details. I know you guys are working on enhancing the features for RUM as part of 3rd gen. At the same, would be possible to create a custom metric that raises an alert when for a particular user action with frustrated score like FRUSTRATED, TOLERATED, SATISFIED. Right now, unfortunately it seems you do not support useraction name as a dimension. I got to that this feature is not there and requesting you to consider this which will be a big enhancement if you bring up this to show the list of useractions impacted with particular apdex score on alert as other tools showing up this. Kindly consider. 

[mark_forrester]

If you are able to query the data and get that result in Grail then you could use the Davis anomaly detector to do just that (until it is possibly added in any future product), I use it for BizEvents on Grail where we see an abnormal amount of failed order pushes information being received.

[paul_kapeller]

I can confirm that this is the way to go on the new platform:

1. Create a custom anomaly detection (query via DQL + maketimeseries command if it's not a built-in or custom timeseries)

2. Create a workflow listening to the anomaly events to notify or create a ticket

In terms of data points, any measurements available on Grail can be used for that. For RUM, e.g. page load timings of specific pages or views (based on page/view summary events), request durations of specific requests, specific error types etc. Currently, there is no categorization of performance in terms of Adpex available.

For classic, we also offer key user actions to possible cover your use case already today @9sagarelluru . 

[Bill_Demsky]

I am looking to enable RUM on Grail on a few servers in an application with 20 servers total.

I don't see a way to enable just 2 of the 20 production servers to ease into using this on production.

Is that something that will be available, or is there someway that I am not seeing?

[paul_kapeller]

Can you explain why you want to do it that way?
You're right that this is something that's not possible. You can only disable/enable RUM overall for e.g. a specific process group. But it's not possible to enable/disable only the RUM on Grail piece / config. Also this is not planned on our end.

[Dant3]

HI @paul_kapeller How can one request access to the preview? 

[paul_kapeller]

We are going into a "public" preview soon and I will then update this post - for now you can reach out to your account contact (e.g. Customer Success Manager, Insights Analyst...) to inquire for participation, which will then be managed in a couple of weeks.

[paul_kapeller]

Request form for preview participation:
https://docs.dynatrace.com/docs/whats-new/preview-releases#real-user-monitoring-on-grail

[Dant3]

Thanks, already did. 

[LesH]

Hi Paul, we have requested for preview participation a couple of weeks ago. Can we somewhere check if access has been activated? Thanks  

[Peter_Youssef]

Thanks @paul_kapeller for organized and insightful content.

[WellPP]

Currently, we can see the image size in the waterfall analysis. Would it be possible to make this information available in Grail as well? It would be very helpful for identifying images that could be resized within the application.

[paul_kapeller]

On Grail, we are currently capturing encoded and decoded body size, transfer size of requests captured.

Since we recently published the semantic dictionary for user events, you can review the full request model here 

Or are you referring to something else?

[GregOReilly]

Any other update on the availability of RUM in Notebooks/New Dashboards / Grail ?

I can see "user.sessions", and I can see the buckets. But not yet available to pull back any data. 

[Julius_Loman]

@GregOReilly have you signed up for the Preview program ?
If you are not in the preview, you won't see any data in the user.sessions table. If you are part of the preview, you need to configure your apps, see https://docs.dynatrace.com/docs/shortlink/rum-on-grail-capture-data

General availability is planned later this year.

[AntonioSousa]

@paul_kapeller ,

Eagerly waiting for extending the 35 day retention time. When will it happen?

[paul_kapeller]

Can you elaborate why / what data you'd like to store for longer and why?

As it stands now, we will launch a preview program for extended retention ~at the time we go GA with the new RUM experience. Mid next calendar year we are planning for the GA of extended retention in Digital Experience.

[AntonioSousa]

@paul_kapeller ,

Quite simply, GA does it, and the client (I'm a partner) wants to use Dynatrace for UX. But can't if limited to 35 days...

[Julius_Loman]

Since the new RUM experience data resides in Grail, why is this not available with its launch along with processing rules? 

I had several cases with customers with RUM classic offering where longer retention (60 days or more) would solve the case. 35 days is simply just one month. Many customers have monthly releases and comparing the data with the previous month is essential. With custom metrics, it's solvable only to some degree. 

[jegron]

Hi,

Is there a way to get something like Apdex with the new RUM? Customers are familiar with this easy-to-understand indicator.

[AurelienGravier]

Hello @paul_kapeller,

Is there a way to change how the page.name value is detected?
I’m looking for something equivalent to the User Action Naming Rules, which allowed fairly advanced matching using regex.

My first attempts with DQL feel cumbersome and hard to reproduce consistently across dashboard widgets:

fetch user.events, samplingRatio: 1, scanLimitGBytes: 500
| filter characteristics.has_page_summary == true OR characteristics.has_w3c_navigation_timings == true
| filter dt.rum.application.entity == "APPLICATION-8C7D0B9CE4FDFC30"
| filter isNotNull(page.name)
| fieldsAdd error.count = error.csp_violation_count + error.exception_count + error.http_4xx_count + error.http_5xx_count

| filter matchesValue( page.name, "/products/*")

| fieldsAdd variabilized = replacePattern( page.url.path, "'/'LONG'/'", "/xxx/")
| parse variabilized, """DATA:shorturl "\/xxx\/" """
| fieldsAdd target = concat(shorturl, "/xxx/")
| fieldsKeep page.url.path, page.name, target

The parameterization of URL paths seems to be the foundation for correctly aggregating Core Web Vitals statistics.

Thank you for your help.
Regards

[paul_kapeller]

Hello @AurelienGravier ! Please create a thread in the future inside the community group.

As of now, you can influence the resulting page names and view names via the eventModifier API.

You'd need to modify the page.detected_name

Which then results in a change of the page.name on ingest.

Via an OpenPipeline processing step, you can also enrich your own field with the page name you'd like to have. However, direct modification of these fields is not possible on ingest yet, but it's planned.

Hope this helps!

[Stephen1_Lee]

HI

Since the RUM data would be in Grail, will the useractions, usersessions be "linked" to the span data that is stored for services ?

Thank you

[paul_kapeller]

Linking frontend to backend data basically follows the Otel-standards and the context is enriched on user event level as well as spans. A request includes a trace-id which is stored on spans as well. You can - soon after our GA  in January e.g. go to the trace

- from a user event within the user session in the Users & Sessions app

- a request error in Error Inspector

- or a waterfall view in Experience Vitals

Also from the span/trace-view users can go to the user event triggering it,

- on DQL level

- in future within the Distributed Tracing app.