Session Replay
Session Replay
Session Replay tests how Mixpanel records and inspects user sessions alongside event data. The exam emphasizes privacy, sampling, playback interpretation, and linking replays to quantitative reports.
Core rules
- Replay captures interactions such as clicks, scrolls, DOM changes, and often console and network activity, depending on configuration and platform.
- Recording is usually sampled. A configured percentage of sessions is recorded, so replay is illustrative unless you account for the sampling rate.
- Masking protects sensitive content. Configure text and input masking for PII, and verify selectors or CSS classes cover payment and health fields.
- Retention limits determine how long replays remain available. Replay is not a permanent archive.
- Replays link to the event stream, so you can jump from a funnel drop-off or event to a session and inspect what happened around it.
- Mobile replay follows the same privacy logic but captures app screens rather than DOM; availability depends on SDK and plan settings.
Worked example
A checkout funnel shows a 22% drop between Payment Submitted and Order Confirmed. In Session Replay, sampled sessions show users repeatedly tapping a disabled button after a validation error that is not logged as an event. The team adds a Validation Error Shown event and confirms the pattern in aggregate. The reasoning: replay generated a hypothesis; event instrumentation verified it across all users, not just recorded sessions.
Traps
Treating recorded sessions as a representative sample; leaving unmasked PII in inputs or page text; assuming replay captures every session; using replay alone to claim statistical impact; and forgetting that console logs and network payloads can expose secrets.