Session Replay

It records and replays DOM changes rather than "recording video"

Session Replay does not capture the screen as video. According to the official documentation, the recorder is part of the RUM Browser SDK; it takes snapshots of the DOM and CSS and records timestamped events such as DOM changes, mouse movements, clicks, and inputs (as of September 2026, source: Browser Session Replay). On playback, the screen is reconstructed from this record. This mechanism produces two properties. One is that you can decide "do not record" per element. Password fields and name fields that would appear in a video can be designated as elements and never written down in the first place. The other is that, because the record is text and structure, it can be connected to search and analysis. Combined with RUM performance data, the official positioning is that it can be used to identify, reproduce, and resolve errors, and also reveals usage patterns and pitfalls in screen design. The center of the design is less "what can be recorded" than "what you decide not to record."

What can be recorded and what cannot

Let us organize what can and cannot be recorded, following the official documentation. In the browser, the DOM and CSS and the interaction events are what gets recorded. On mobile, native Android and iOS apps are the target, and interactions such as taps, swipes, and scrolls are replayed (as of September 2026, source: Session Replay). On the other hand, some elements are always masked regardless of privacy settings: input fields of type password / email / tel, and elements with autocomplete attributes such as credit card number, expiration date, and security code (source: Session Replay Privacy Options).

Most of what "cannot be recorded" is not a technical limit but something you decided not to record through settings. That is exactly why the decision to leave the default as is or to open up element by element is the subject of the next section.

How to choose the masking level - decide by business impact

The defaults and the three modes are left to the RUM entry; here we focus on how to choose. The official documentation divides text masking into three kinds: "no mask," which shows text as is; "space-preserving mask," which replaces each character with x and keeps only the length; and "fixed-length mask," which turns the whole thing into ***. Which one applies is determined by the combination of mode and text type (as of September 2026, source: Session Replay Privacy Options).

Read in terms of business impact, Mask all turns even static text into a string of x's, so you cannot read error messages or button labels when watching the replay. Even so, you can still tell "where it stopped," so the safe order is to start with Mask all and open only the spots where not being able to read is a problem, element by element. There are two ways to open: add the data-dd-privacy="allow" attribute or the dd-privacy-allow class to the element, and the opposite mask and hidden can be applied in the same form.

Differences between the browser and mobile SDKs

The browser version's recording unit is the DOM. The mobile version replays taps, swipes, and scrolls in native Android and iOS apps (as of September 2026, source: Session Replay). Privacy settings are also split: the browser uses defaultPrivacyLevel plus per-element attributes / classes, while mobile (Android / iOS / React Native / Flutter) chooses levels along three families, "text and input," "image," and "touch." The levels are 3 for text and input, 3 for image, and 2 for touch (source: Session Replay Privacy Options). Even if a WebView is set to hidden, the WebView itself keeps collecting, so its contents are protected through the Browser SDK settings. Remember it as "browser is per element, mobile is per type" and the design stays consistent even in an organization that has both.

Retention and billing - 30 days, 15 months, per 1,000 sessions

Retention of replay data is 30 days by default. Extending the default is something to discuss with your account representative, and individual replays can be extended to 15 months with Extended Retention. Adding a replay to a playlist also automatically extends it to 15 months, counted from the moment the extension was enabled (as of September 2026, source: Session Replay). Billing is an add-on SKU to RUM; on the pricing page as of August 2026 it is listed as a monthly amount per 1,000 sessions with three unit prices, annual commitment, month-to-month, and on-demand, including 30 days of replay retention. Using it in both RUM and Product Analytics does not bill you twice (source: Datadog Pricing). The FAQ explains that a session expires after 15 minutes of inactivity and lasts at most 4 hours. For the concept of retention, see retention; for the SKUs as a whole, see how to read the pricing structure. This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

Consent and personal information in practice

Recorded data is stored in the cloud managed by Datadog and encrypted at rest. Unlike Sensitive Data Scanner, which obfuscates at ingestion while letting authorized people see the original values, the official documentation cautions that masking cannot be undone afterward (as of September 2026, source: Session Replay Privacy Options). Who viewed which replay can be checked from the view count on the playback screen, and playback is also kept as an Audit Trail event (source: Session Replay). These two points become the material for accountability toward the people being recorded. On consent, this article does not name laws or assert what is permissible. The premise is that whether consent is required and its wording follow your own organization's rules and legal judgment, and on top of that there are four things to decide in practice: an inventory of the pages and screens being recorded, the decision on whether to keep the default masking, a list of the spots to open per element, and the operation of playback permissions and viewing history.

Conditions for passing and how to start with a minimal setup

Let us first list the situations it does not suit. For flows where most of the screen is occupied by sensitive input, such as payment or uploading identity documents, masking leaves the replay unreadable and opening leaves risk, so excluding them from scope or painting them over with hidden is the realistic decision. Stages where the consent design is not settled, or where it has not been decided who will watch replays, are also reasons to pass. If you do start, the following order is recommended.

Playback includes a built-in debugging panel called Dev Tools, which lets you follow requests and performance bottlenecks during replay (as of September 2026, source: Session Replay). The effect of shortening bug reproduction time is most reliably measured in this order, starting from the first single app. If Synthetics is "the watch during hours when nobody is there," Session Replay is "the record of what the people who were there saw," and the two complement each other. Slowness behind the screen is the domain of APM.