Session Replay

Reconstruct exactly how a case was worked, step by step.

Session Replay reconstructs a case as a step-by-step timeline β€” every screen, with handling time, page load, app switches (swivel), and clicks β€” so teams can see the friction behind a metric and jump straight to the moments that matter.

Capabilities

  • Step/screen timeline with handle, load, swivel, and click signals
  • Jump-to-friction: seek to rage/dead clicks and re-entry
  • Session search and filtering on any dimension
  • Link a session from any chart, funnel step, or anomaly
  • Privacy-first: PII masked at capture, no raw screen content

How it works

  1. Sessions are reconstructed from autocaptured events β€” no separate recording.
  2. Open a session from a chart/funnel, or search the session list; use jump-to-friction to seek.

What gets captured

Session Replay reconstructs each session from page changes and captured signals. You choose what’s recorded β€” and what’s kept private β€” per app.

  • Network requests β€” captures fetch and XHR calls with their URL, timing, and status. Request and response bodies are off by default; turn on body capture only when you need it. Sensitive headers (cookie, set-cookie, authorization) are never recorded, and you can add more headers to ignore. Optionally record only failed (4xx/5xx) requests.
  • Console logs β€” records console output (log, info, warn, error, debug, assert). Choose which levels to keep, or turn console capture off.
  • JavaScript errors β€” captures unhandled errors with their stack traces, so you can see what broke during a session.
  • Page performance β€” captures page-load and performance metrics (on by default; can be turned off).
  • Respect Do Not Track β€” when enabled, Session Replay honors the browser’s Do Not Track signal and skips recording for those users.

Sanitization

Session Replay never records your screen as video. Instead, it captures the page’s structure and the changes to it, then rebuilds the session as a faithful re-render of what the user saw. Because the replay is reconstructed rather than filmed, sensitive values can be stripped out before anything ever leaves the page.

When sanitization is turned on, masking is the default β€” anything typed into a form appears as asterisks instead of the real text, email addresses shown in page text are hidden, and passwords are always fully hidden. You can see how someone moved through and interacted with your app, but never what they typed, and because masking happens at the point of capture, masked content can’t be recovered later.

Choosing a protection level

You decide how form-field values are recorded, per app:

Level What the replay shows
Show values The text exactly as typed
Mask values (default) Dots matching the number of characters typed β€” you see how much was entered, not what
Hide values Nothing at all, not even the length

At the default level every field is masked, so nothing a user types is visible. If you choose to show values in clear text instead, Session Replay can still mask the most sensitive types on its own β€” email addresses, long numbers, and dates β€” so those stay protected even when other fields are visible. Protection can only be added this way, never removed: passwords stay hidden no matter what. (Some fields, such as dates and dropdowns, appear empty when masked rather than showing dots.)

Masking specific areas

When you need more control than the per-app level, you can protect individual parts of a page:

  • Mask an element β€” its text becomes asterisks, and any fields inside it record only how much was typed. This applies to the element and everything within it.
  • Hide an element β€” the element and its contents are left out of the recording entirely.

The simplest way to do this across a whole app is to give Pyze a list of CSS classes: any element using one of those classes is masked automatically, so you can protect sensitive areas everywhere they appear without marking each one by hand.

Availability

Enabled with the Pyze agent; PII masking applies (see Data Privacy & Consent).


Last modified 0001-01-01