Replay Storage Under Pressure
Your team enabled Session Replay on 100% of web traffic three weeks ago. The app has about 400,000 monthly active users and heavy mobile-web usage. Replays now account for most of your Amplitude event volume, and the monthly quota is being consumed about twice as fast as projected. Support loves the replays for debugging, but finance is asking why analytics cost doubled. You also get complaints that replays sometimes fail to load for long sessions, and privacy wants assurance that no sensitive form fields are captured. You need a plan that keeps replay useful without blowing the budget.
1. How do you decide what to sample and what to keep at full fidelity, and what signals guide that?
Read the worked answer
Start from use cases, not from a blanket percentage.
- Debugging and support: you need replays for sessions that hit errors, rage clicks, or support tickets. Those are a small fraction of traffic, so capture them at 100% via targeted triggers (error events, funnel drop-off, flagged users).
- Product research: you need a representative sample, not everything. Sample a stable percentage (e.g. 10-20%) of ordinary sessions so trends are still visible.
- High-value flows: checkout and onboarding may justify higher sampling than browsing, because the cost of a missed bug is higher.
Signals to guide the split: error rate by flow, support ticket volume, funnel drop-off points, and the cost per captured session. Compute the quota burn rate by flow to see where replays are expensive and whether that spend buys insight.
A tiered policy (100% on error/flagged sessions, sampled baseline elsewhere, higher on critical flows) usually cuts cost sharply while keeping the replays people actually use.
2. Privacy wants assurance on sensitive fields, and support reports long-session load failures. How do you address both?
Read the worked answer
Sensitive fields:
- Configure masking at the SDK level so inputs like passwords, payment fields, and health or ID fields are masked or blocked before capture. Masking must be default-on for form inputs, with an explicit allowlist for fields that are safe to show.
- Verify with a test session: enter known values in sensitive fields and confirm they do not appear in the replay.
- Document the masking rules and review them whenever a form changes.
Long-session load failures:
- Long sessions produce large replay payloads. Check whether failures correlate with session length and network conditions.
- Reduce payload size: lower capture fidelity where acceptable, break long sessions, and avoid capturing heavy elements unnecessarily.
- Confirm the SDK and replay configuration are current and that network buffering settings are appropriate for mobile-web users.
Both fixes should be validated with a small canary before rolling out, and the masking check should be part of the release checklist so it does not regress.