Session Replay Data Retention: A Policy for Cost & Privacy
Watch this session from last quarter. At 0:09 she taps "Apply" on a promo code, and nothing moves. The field doesn't clear, no error shows, the button just sits there dead. She taps it again. And again. By the fourth tap she's scrolling up hunting for a mistake she didn't make. We'd been seeing this dead-click pattern all week — a broken client-side validation that swallowed valid codes.
Here's the part that stuck with me. When we went to pull the original replay of that bug — the one from about 90 days earlier that first triggered a support ticket — it was already gone. Expired. And nobody missed it. The fix had shipped, the code had changed, and a three-month-old recording would've shown us a flow that no longer existed.
The short answer on session replay data retention: keep raw replays around 30 days for bug triage, extend to about 90 days for UX research, and only pull specific sessions into a documented compliance hold beyond that. Longer default retention buys almost no insight while it quietly stacks up privacy risk.
Why the industry already answered this — and set the bar near 30 days
You don't have to theorize about the right window. The vendors already voted with their defaults, and the vote was lopsided.
| Vendor | Default playback retention |
|---|---|
| Microsoft Clarity | 30 days (recordings) |
| Mixpanel | 30 days from ingestion |
| Datadog | 30 days |
| Siteimprove | 30 days |
| New Relic | 8 days |
Microsoft's own Clarity documentation states that "Recordings data is retained for 30 days." Mixpanel's docs say "By default, replays are stored for 30 days after the time of ingestion." Datadog and Siteimprove land on the same 30-day figure. New Relic goes shortest of all — its documentation notes that "Session Replay data is stored for 8 days" unless you upgrade.
There's a pattern buried in these numbers worth pulling out. Several of these vendors expire the watchable recording first while keeping aggregate data much longer. Clarity retains heatmap data for 13 months but recordings for 30 days. That split is an implicit admission: the full replay's value decays fastest, and the aggregate signal is what's worth keeping around.
The counter-intuitive part: replay value decays faster than you think
Most retention debates assume a replay is an asset that holds its worth like a filing cabinet. It doesn't. A session recording is most useful in the days right after it happened, and it loses relevance fast.
Think about what you'd actually do with a six-month-old replay. The code has shipped past it. The flow it shows might not exist anymore. The user's context — what campaign brought them, what the page even looked like — has drifted. Siteimprove says as much in justifying its default, noting that specific replays lose relevance over time. That's not a storage excuse. It's an honest description of how debugging works.
In my own field notes, the replays we reopen are almost always under two weeks old. Something breaks, we watch the last few days of sessions hitting that flow, we find the pattern, we fix it. Stale replays get watched approximately never. In a year of triage work I can count on one hand the times we needed something older than 30 days, and every one was a legal matter, not a UX one. If you're weighing this against building heatmaps instead, we covered when each earns its keep in heatmaps versus session replay.
The cost argument cuts the other way
Teams often justify long retention with "storage is cheap, why delete?" The premise is right. The conclusion is backwards.
Let's run a tiny model. Say you record 100,000 sessions a month. An rrweb-based replay compresses to roughly 100–500KB per session. Take the middle, call it 300KB. At 100k sessions, that's about 30GB a month.
- 30-day retention: ~30GB resident. Object storage runs a few cents per GB-month, so you're looking at roughly a dollar or two.
- 90-day retention: three months resident, ~90GB. Still low single-digit dollars.
- 365-day retention: ~360GB standing. A handful of dollars a month.
Cross-check that against New Relic's own figures. Its documentation offers "an average of 5.3 MB per replay" and a formula: "sessions x sampling_rate x gb_per_replay x cost_per_gb." Use their heavier per-replay number and the total climbs, but the shape holds. This is not where your cloud bill lives.
So here's the take. Since raw storage is nearly free, the real variable you're trading on isn't cost. It's privacy exposure. Every replay you keep is a recording of someone's screen, sitting in a bucket, waiting to become part of a breach report. Most teams over-retain to save money they were never actually spending.
What the law actually requires: storage limitation, per purpose
GDPR's Article 5(1)(e), the storage-limitation principle, says identifiable personal data must be kept no longer than necessary for the purpose you collected it, and that you should document that per-purpose justification.
The trap has two sides, and Legiscope frames it well: "A data set that is minimal at collection still breaches Article 5 if it is never deleted, and a rigorously purged system still breaches Article 5 if it over-collected in the first place." Masking PII at capture doesn't get you off the hook if you then hoard the masked sessions forever. Deletion is its own obligation.
And regulators are now checking. Legiscope reports that in February 2026, the EDPB published the results of its 2025 coordinated action, in which "32 DPAs audited 764 controllers across Europe on erasure practices." The recurring finding was a lack of automated deletion capability — organizations that could collect data fine but had no reliable machinery to make it go away on schedule. If your replay pipeline can't delete on its own, that's the gap they're looking for. For the adjacent legal-exposure question of whether replay itself is lawful, see our piece on session replay and the wiretapping lawsuit wave.
The retention-by-purpose matrix
Here's the spine of the whole policy. Don't set one retention number. Set a window per purpose, and tag each replay so the system knows which window applies.
| Purpose | Retention window | Why this window | Deletion trigger |
|---|---|---|---|
| Bug triage / debugging | 30 days | Matches vendor defaults; replay value decays fastest here | Auto-expire at 30d TTL |
| UX research / flow analysis | 90 days | Spans a full research cycle; sample sessions, don't hoard them | Auto-expire at 90d; promotion required |
| Aggregate heatmaps / trends | Longer OK | Not identifiable playback — mirrors Clarity keeping heatmaps 13 months | Tied to reporting need, not raw session |
| Compliance / legal hold | Exception only | Specific tagged sessions with documented justification | Defined release date on the hold |
The logic per row is minimization, not convenience. Debugging gets 30 days because that's where the value lives and it matches what every major vendor already ships. Research gets 90 because a proper study — recruit, observe, analyze, report — takes longer than a month, and you'll want to revisit sessions across that span. Aggregates can persist because a heatmap isn't a recording of a person. It's a density map, and Clarity's 13-month heatmap retention is the model.
The legal hold is the only path past 90 days, and it's a per-session exception with a paper trail, never a default. Siteimprove's extendable 365-day option is a ceiling for edge cases, not a starting point.
A deletion policy you can actually ship
The matrix is the intent. Here's the mechanism.
Tag every replay with its purpose at ingestion, then set the default TTL to the shortest justified window — 30 days. From there, allow explicit promotion: a researcher can move a session into the 90-day bucket, or legal can flag one into a hold. Automate the deletion itself, since that's precisely the capability the EDPB found missing across those 764 controllers. And log every deletion, so you can prove the machinery ran.
One field-note warning about the promotion step. Expired means gone. Clarity's documentation is blunt that expired data, including backups, is unrecoverable. So if a 30-day replay is going to matter to a research project, someone has to promote it before day 30. You can't reach back for it later. Design and socialize that promotion path first, before you rely on it. In practice, that means researchers doing a triage pass around week three of anything they might want to keep.
How the tools handle it: configurability compared
Same rubric for everyone, honest caveats included.
| Tool | Default window | Max extension | Notable trait |
|---|---|---|---|
| Microsoft Clarity | 30 days | 13 months (labeled); heatmaps 13mo | Splits recording vs heatmap retention cleanly |
| Mixpanel | 30 days | 7–360 days (Enterprise add-on) | Retention starts from ingestion |
| Datadog | 30 days | Up to 15 months (Extended Retention) | Extension covers replay only, not events |
| Siteimprove | 30 days | Up to 365 days | Explicitly cites relevance decay as rationale |
| New Relic | 8 days | Extend via Data Plus | Shortest default of the group |
| Kixo | Not published on our fact sheet | Evaluate directly | rrweb web + native iOS/Android replay, heatmaps, privacy masking |
A word on Kixo, listed here on the same terms as the rest. It offers rrweb-based web replay plus native iOS and Android capture, heatmaps, and privacy masking at collection. I don't have its specific default-retention windows on my fact sheet, so I won't quote a number. Evaluate its configurability directly when you're comparing, the same way you'd pin down Datadog's Extended Retention scope before signing.
And one honest framing note that applies to Kixo and everyone else offering it: masking at capture lowers the privacy stakes of whatever you retain, but it doesn't replace a deletion policy. A masked recording is still a recording. When you're picking a tool, retention configurability belongs on the same shortlist as everything in how to choose a session replay tool.
The short version
Three windows. Bug triage lives at 30 days, matching every vendor default and the decay curve. UX research earns 90 days if you sample deliberately instead of hoarding. Aggregates and heatmaps can run longer because they aren't identifiable playback. Everything past that is a per-session legal hold with a documented reason and a release date.
The closing field note, from someone who's watched more expired replays vanish than I can count: the recording you'll wish you'd kept is genuinely rare. The one that turns into a breach liability is the boring 8-month-old session nobody ever reopened, sitting in a bucket, adding risk and zero insight. Delete on purpose.