- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Real User Monitoring (RUM) provides controls for implementing privacy requirements and ensuring organizations of any scale do not expose sensitive or personal information. Data is stored on Datadog-managed cloud instances and encrypted at rest. The default behaviors and configurable options described on this page are designed to protect end user privacy and prevent sensitive organizational information from being collected. Learn more about Privacy at Datadog.
The responsibility of keeping user data secure is shared between Datadog and developers who leverage the RUM SDKs.
Datadog is responsible for:
Developers are responsible for:
RUM can be configured for compliance with many standards and regulatory frameworks, including, but not limited to:
By default, there are some privacy restrictions in place that protect user data to help comply with regulatory and standards frameworks.
Browser RUM requires first party cookies to be enabled on an end user’s browser to collect data. If required by the jurisdictions in which you operate, you are responsible for configuring your pages to comply with the laws of those jurisdictions, including receiving consent to collect cookies before RUM is initialized.
Mobile RUM tracking is only run upon user consent. If the end user accepts the RUM tracking, we track their activity and session experience. If the user declines the RUM tracking, we do not track their activity and session experience.
You have several options and tools when it comes to collecting and redacting data captured by RUM.
The browser RUM client token is used to match data from the end user’s browser to a specific RUM application in Datadog. It is unencrypted and visible from the client side of an application.
Because the client token is only used to send data to Datadog, there is no risk of data loss due to this token; however, Datadog recommends good client token management to avoid other kinds of misuse, including:
One method of using the client token to filter out bots is an authenticated proxy. In this method, a placeholder string is substituted for the clientToken when initializing the Datadog RUM Browser SDK. The proxy knows the real client token, but the end user does not.
The proxy is configured to check for valid user information before passing the session data to Datadog, thereby confirming that a real user is signed in and transmitting traffic to be monitored. When receiving traffic, the proxy verifies that the data includes the placeholder string and replaces it with the real clientToken before forwarding the data to Datadog.
An event is a user interaction with specific elements of your site or app. Events can be automatically captured via the SDK or sent via custom actions. You can turn off automatic tracking of user interactions and page views to only capture the interaction of your choice. By default, RUM uses target content to generate action names from actions automatically collected by the SDK. You can explicitly override this behavior with any given name.
The data we track automatically contains primarily technical information, much of which doesn’t include personal identifying information. Data that is captured by RUM can be further redacted before it is sent and stored in Datadog through advanced configuration options for the following methods:
You can transmit all RUM events through your own proxy server so that end user devices never directly communicate with Datadog.
By default, there is no tracking of users’ identity. Each session has a unique session.id tied to it, which anonymizes the data, but allows you to understand trends. You have the option of writing code to capture user data such as name and email address, then using that data to enrich and modify RUM sessions, but this is not required.
After you have configured the event capture, events are stored in Datadog. You can decide how long your captured events and properties stay in Datadog.
By default, data retention for production environments is:
Retention can be extended to a maximum of 90 days at no additional cost by opening a support ticket. Note that this retention extension does not apply to Session Replays, Resources, or Long Tasks.
Datadog provides role-based access control (RBAC) for managing who sees captured RUM data. Default settings for data access depend on the role a user gets added to. There are three types of Datadog roles available: Administrator, Standard, and Read Only roles. More granular RUM-specific permissions are defined in Datadog role permissions. For example, you can grant or revoke access to view Session Replays.
If you need to delete data stored by Datadog, for example, if potentially sensitive data has been leaked into RUM events, you can hard-delete data from within a given timeframe. With a hard delete, all data is deleted; it cannot be targeted to a specific application. If you need any data deleted, reach out to the Datadog support team.
You have some options available for removing Personally Identifiable Information (PII), and sensitive data, including IP addresses and geolocation. Some scenarios where PII could appear in RUM:
By default, if you wish to mask all action names, you can use the enablePrivacyForActionName option in conjunction with the mask privacy setting. This operation automatically substitutes all non-overridden action names with the placeholder Masked Element. This setting is also designed to be compatible with existing HTML override attributes.
PII inadvertently included in unstructured data, such as an individual’s name in a text box, can only be removed through a data deletion requisition for a specified timeframe.
With respect to URLs, you have the option to track page views manually in order to remove any PII or use beforeSend to change the URL text.
You can also transmit all RUM events through your own (proxy) server so that end user devices never directly communicate with Datadog.
When setting up a RUM application, you can choose whether or not you want to include IP or geolocation data:
Once you disable collection of IP data, the change will be applied immediately. Any events collected prior to disabling will not have their IP data removed. It is performed on the backend, which means the Browser SDK will still be sending data, but IP addresses will be omitted by Datadog backend pipelines and dropped at processing time.
In addition to removing client IPs, you can also choose to disable the collection of geolocation (country, city, county), or GeoIP, from all future collected data. If you uncheck the Collect geolocation data box, the change will be applied immediately. Any events collected prior to disabling will not have their geolocation data removed. Data omission is done at the backend level, which means the Browser SDK will still be sending data, but geolocation data will be omitted by our backend pipelines and dropped at processing time.
Sensitive Data Scanner allows you to proactively search and scrub sensitive data upon ingestion by Datadog. RUM events are scanned on the stream before any data is stored within Datadog. The tool has the power to scrub, hash, or partially redact PII data before it is stored. It works by applying out-of-the-box or customer-developed pattern matching rules. If you’ve enabled this feature, you can find it on the Manage Sensitive Data page.
See privacy options specific to Session Replay.
| |
