Session Replay Monitoring: Understanding Real User Experiences Through Playback

Session replay records what users actually do in your application and plays it back like a video — mouse movements, clicks, scroll behavior, form interactions, and errors. Unlike traditional monitoring that tells you an error occurred, session replay shows you exactly what the user was doing when it happened. This context is often the difference between a bug that takes days to reproduce and one that's fixed in an hour.

What Session Replay Captures

Session replay tools reconstruct user sessions using DOM snapshots and event recording rather than video capture:

// What session replay typically captures:
const capturedEvents = {
  // User interactions
  clicks: { x, y, element, timestamp },
  keystrokes: { element, keyCount, timestamp }, // Not actual keystrokes (privacy)
  scrolls: { position, direction, timestamp },
  mouse_movement: { path, heatmap_data },
  
  // Application state
  console_errors: { message, stack, timestamp },
  network_requests: { url, status, duration, timestamp },
  page_navigations: { from, to, timestamp },
  
  // DOM changes
  dom_mutations: { element, type, timestamp },
  
  // Custom events
  custom_events: { name, properties, timestamp }
};

The recorded data is reconstructed into a visual replay — not an actual video but a re-rendering of the DOM state at each point in time.

Session Replay Use Cases

Debugging User-Reported Bugs

The most powerful use case: reproduce bugs that are hard to replicate from a bug report alone.

## Without Session Replay
User report: "I can't complete checkout. It just shows a blank page."
Debug process:
1. Ask user for steps to reproduce (vague responses)
2. Try to reproduce in local environment (fails)
3. Check error logs (generic 500 error with no context)
4. Spend 2 days investigating hypotheses
5. Eventually find: user had an older browser with missing feature

## With Session Replay
User report: "I can't complete checkout. It just shows a blank page."
Debug process:
1. Find the session in session replay tool
2. Watch the 30-second replay showing: clicks checkout, page blanks
3. See the JavaScript error in the replay: "IntersectionObserver is not a function"
4. Fix: Add polyfill for older browsers
Total time: 15 minutes

UX Investigation

Understand why users struggle with specific flows:

## Rage Click Detection
Session replay tools detect "rage clicks" — rapid repeated clicking
that signals user frustration:

Common patterns and what they mean:
- Rage clicking a non-interactive element: User thinks it should be clickable
- Rage clicking a button that's slow to respond: Perceived unresponsiveness
- Rage clicking a form submit button: Form validation failing silently
- Rage clicking a link: Link broken or opens in unexpected way

Use rage click data to:
1. Identify broken UI elements
2. Find missing affordances (things that should be clickable)
3. Discover form validation issues that don't surface through error logs

Error Investigation

Connect JavaScript errors to the user actions that caused them:

// Integrate session replay with error tracking
// When an error occurs, log the session replay URL for investigation

import * as Sentry from "@sentry/browser";
import { record as rrwebRecord } from "rrweb";

// LogRocket integration example
import LogRocket from "logrocket";

LogRocket.init("your-app-id");

// Connect LogRocket session to Sentry errors
LogRocket.getSessionURL(sessionURL => {
  Sentry.configureScope(scope => {
    scope.setExtra("sessionURL", sessionURL);
  });
});

// Now when Sentry captures an error, it includes the session replay URL
// in the error details, making debugging dramatically faster

Tools Comparison

| Tool | Primary Strength | Privacy Features | Pricing Model | |---|---|---|---| | FullStory | Best-in-class data analysis | Good masking, DLP | Per session | | LogRocket | DevTools integration, logs correlation | Configurable | Per session/MAU | | Hotjar | Heatmaps + session replay combined | Basic masking | Per site | | Microsoft Clarity | Free, basic feature set | Limited masking | Free | | PostHog | Open source, self-hostable | Full control | Per event | | rrweb | Open source library only | DIY | Free/self-hosted |

Privacy: The Critical Consideration

Session replay is powerful precisely because it captures sensitive user behavior. This creates significant privacy obligations:

What You Must Protect

// Automatic masking configuration (varies by tool)
// LogRocket example:
LogRocket.init("your-app-id", {
  // Mask all input fields by default (safe default)
  inputSanitizer: true,
  
  // Mask specific DOM elements
  shouldCaptureIP: false,
  
  // Redact specific fields
  redactionRules: [
    {
      type: "css",
      selector: "input[type='password']",
      action: "redact"
    },
    {
      type: "css",
      selector: "[data-sensitive]", // Your custom attribute
      action: "redact"
    }
  ]
});

// FullStory example:
FS.identify(userId, {
  displayName: "User " + userId.substring(0, 4) + "...",  // Partial ID only
  email: "u***@***.com"  // Masked email
});

// rrweb custom masking:
record({
  maskTextSelector: "[data-pii]",  // Mask elements with this attribute
  maskInputOptions: {
    password: true,         // Always mask passwords
    creditCard: true,       // Always mask credit card fields
    email: false,           // Show emails (if your policy allows)
  }
});

Required Disclosures

## Legal Requirements for Session Replay

### GDPR (EU users)
- Require explicit consent before recording (cookie consent banner)
- Include in privacy policy: what is recorded, how long retained, 
  who has access, right to opt out
- Provide data subject access rights for session recordings
- Document legitimate interest basis or consent basis

### CCPA (California users)
- Disclose in privacy policy
- Provide opt-out mechanism
- No selling of session data to third parties

### PCI DSS (payment card data)
- NEVER record on payment form pages (or implement strict masking)
- Credit card numbers, CVV, expiry must never appear in recordings
- Consider excluding all payment-related pages from recording

### HIPAA (healthcare)
- Session replay on pages showing PHI requires BAA with vendor
- Most session replay vendors cannot sign BAAs — exclude PHI pages
- Consider session replay only on non-PHI sections

### Best Practice
- Default to masking all form inputs
- Add explicit [data-record-safe] attributes to elements you want captured
- Exclude pages with financial or health data entirely from recording
- Store recordings with access controls — not all employees need access

Integration with Traditional Monitoring

Session replay complements, not replaces, traditional monitoring:

# Enhanced error context with session replay URL

class ErrorTracker:
    def capture_error(self, error, user_context):
        """
        Capture an error with session replay context.
        """
        error_data = {
            "error_type": type(error).__name__,
            "message": str(error),
            "stack_trace": traceback.format_exc(),
            "timestamp": datetime.utcnow().isoformat(),
            
            # Traditional monitoring context
            "user_id": user_context.get("user_id"),
            "session_id": user_context.get("session_id"),
            "page_url": user_context.get("current_url"),
            "user_agent": user_context.get("user_agent"),
            
            # Session replay context (new!)
            "session_replay_url": user_context.get("session_replay_url"),
            "replay_timestamp": user_context.get("replay_timestamp")
        }
        
        # When an engineer sees this error in their error tracker,
        # they can click the session replay URL to see exactly what
        # the user was doing when it happened.
        
        return self.send_to_error_tracker(error_data)

When to Use Session Replay vs Other Tools

| Question | Best Tool | |---|---| | Is the service up? | Uptime monitoring (AzMonitor) | | How fast is it for users? | RUM performance metrics | | What errors are users seeing? | Error tracking (Sentry, Bugsnag) | | Why are users seeing that error? | Session replay | | Where are users dropping off? | Analytics funnel | | What is a specific user experiencing? | Session replay | | What's the P99 latency? | APM/RUM |

Sampling Strategy

You don't need to record every session:

// Sample-based recording to control cost and storage
const SAMPLE_RATE = 0.1; // Record 10% of sessions

function shouldRecord() {
  // Always record sessions with errors (regardless of sample rate)
  if (window.__sessionHasError) return true;
  
  // Always record specific user segments
  if (window.__userSegment === 'beta-tester') return true;
  if (window.__userSegment === 'enterprise') return true;
  
  // Random sample for general sessions
  return Math.random() < SAMPLE_RATE;
}

if (shouldRecord()) {
  LogRocket.init('your-app-id');
}

Conclusion

Session replay bridges the gap between knowing that something went wrong and understanding what the user experienced when it did. It's most valuable for debugging user-reported issues, investigating UX problems that don't surface in error logs, and understanding the behavior patterns around known errors. The privacy obligations are real and significant — treat session replay data as sensitive personal data, implement masking for all PII, and ensure your privacy disclosures reflect what you're capturing. Used thoughtfully, session replay accelerates bug resolution and UX improvement in ways that are difficult to achieve with other tools. Combined with the uptime and performance monitoring that AzMonitor provides, session replay gives you comprehensive visibility from infrastructure health down to individual user experience.