Real User Monitoring on Grail introduces granular control over access to user events and user session data. This is a significant shift from RUM Classic, where access was managed at a coarser level. These best practices help you configure data access correctly so teams see the data they need without exposing sensitive fields.
RUM data in Grail is stored across two main tables: user.events and user.sessions. Both permissions are required for teams using RUM features.
| Permission | What it provides |
|---|---|
| Access to detailed performance, behavioral, and error events recorded during user interactions. These events are granular and can include every resource loaded or every interaction made. |
| Access to session-level summaries of events performed during a user's visit. Useful for quicker analysis when you need to understand the scope of a user's journey. |
Grant both permissions to all users and groups that need to use RUM features such as Experience Vitals, Error Inspector, and User Sessions.
Removing access to user.events or user.sessions is not a recommended way to restrict access to sensitive data. Reducing access to either table significantly impacts the ability to use Experience Vitals, Error Inspector, and User Sessions.
Instead, use the sensitive data fieldset to restrict access to specific fields. The following fields are marked as sensitive in both user.events and user.sessions:
client.ipdt.rum.user_taggeo.location.latitudegeo.location.longitudeUsers without the builtin-sensitive-user-events-and-sessions fieldset permission cannot search or view these fields. This permission is not included in any policy by default and must be assigned explicitly:
ALLOW storage:fieldsets:read WHERE storage:fieldset-name="builtin-sensitive-user-events-and-sessions";
This masking applies only to display. It does not prevent the data from being collected. Use it alongside the JavaScript tag's built-in privacy settings for a complete privacy approach.
It is not possible to mark additional fields as sensitive beyond the four listed above, including fields created via OpenPipeline. The sensitive data fieldset controls display access only; it does not control data capture.
frontend.name to scope access by application The primary way to grant access to specific subsets of RUM data is the frontend.name field. This field is set when a frontend is created and is automatically included with user.events, user.sessions, and metrics generated by the frontend.
Use frontend.name to restrict which applications a user or group can see:
For user events:
ALLOW storage:user.events:read WHERE storage:frontend.name = "EasyTrade";
For user sessions: because user sessions may span multiple frontends, use the MATCH operator:
ALLOW storage:user.sessions:read WHERE storage:frontend.name MATCH ("EasyTrade","frontendreverseproxy-easytrade");
For metrics:
ALLOW storage:metrics:read WHERE storage:frontend.name = "EasyTrade";
The frontend.name value may differ from the display name shown in Experience Vitals. Always validate frontend.name by enabling the frontend.name column in Experience Vitals before configuring access policies. Applying an incorrect frontend.name value results in users being unable to see data for the intended application.
For cases where more granular access is needed than frontend.name allows—for example, restricting access to specific pages or captured fieldsets—enrich RUM data with dt.security_context via OpenPipeline and use it as the access control dimension.
Grail stores RUM data across seven built-in buckets. All buckets have a 35-day retention period by default:
default_web_user_replaysdefault_user_sessionsdefault_user_eventsdefault_user_error_eventsdefault_synthetic_user_sessionsdefault_synthetic_user_eventsdefault_mobile_user_replaysYou cannot currently modify these buckets or create custom RUM buckets. Extended retention for RUM data is available in preview; refer to the Dynatrace documentation for current preview release details.
Synthetic Browser Monitor data uses user.sessions for execution listings and user.events for individual executions, but does not currently support frontend.name for access scoping. To provide access to all synthetic data while restricting access to specific frontends, grant access using the bucket name directly, for example: ALLOW storage:user.events:read WHERE storage:bucket-name = "default_synthetic_user_events";
Explore the other best practices for this stage, or return to Enrich your observability signals to continue your upgrade.