Session Replay Tool: Analytics Product or Debugging One?

Two genuinely different products are sold under the name session replay tool, and picking the wrong one is expensive in a way that only shows up three months later.

The first is an analytics product. It records every session continuously, so you can ask why a fifth of users abandon the signup flow. The second is a debugging aid. It keeps the last few seconds before something went wrong and attaches them to a bug report. They share a mechanism and almost nothing else — not the price, not the privacy posture, not the question they answer.

Which one are you buying?

The fastest way to tell is the pricing page. Anything metered on sessions captured per month is an analytics product, because continuous recording is the thing being sold.

Those numbers describe three different intentions. FullStory’s free 30,000 sessions is an invitation to instrument everything — and the absence of public pricing above it tells you what kind of purchase the paid tier is; independent analyses put its Business plan around $5,000 a year and Advanced around $12,000, though these are estimates rather than published rates. LogRocket sells on session volume too, and states on its pricing page that you pay only for the sessions you capture while analytics, logs and errors stay unlimited across plans. Sentry’s 50 replays per plan is not a session replay product at all; it is a debugging supplement to error tracking, and the quota says so.

What session replay actually is

The name misleads. Asked what is session replay, most people picture a video file, and that is not what these tools produce.

FullStory describes its replay as a deterministic re-creation of the experience generated from captured interactions and DOM changes — explicitly not a video recording. LogRocket instruments the page through a MutationObserver to record structural and style differences, then recreates playback from those. What travels to the vendor is the page markup, the style information and a stream of events, which FullStory documents as sending HTML markup plus inline images and styles to its servers, then separately fetching referenced image and CSS assets so they can be stored for playback.

This matters for three practical reasons. Reconstruction is far smaller than video, so continuous capture is affordable. It is searchable, because the events are structured data. And it can miss things: anything the reconstruction cannot represent does not appear, which is why native mobile is handled differently — FullStory’s mobile add-on uses drawing operations rather than screenshots, and LogRocket’s mobile SDK documents that when text sanitisation is on, certain iOS custom text layers are prevented from being captured.

The privacy defaults are not the same

This is the part that most deserves attention before installing anything, because the tools start from opposite positions.

LogRocket’s web SDK records all DOM elements by default except inputs where the type is password, which are never captured. Everything else is opt-out: developers mark elements private to record only their dimensions, or delete them from playback entirely, and separate hooks let them redact request and response data. LogRocket’s own documentation recommends redacting headers and bodies rather than switching network recording off, so failed and slow requests remain visible. It also puts the legal obligation on the customer, requiring that any necessary end user consents be obtained before use.

FullStory’s mobile add-on inverts that. It requires what the company calls Private by Default, with text, images and personal data masked at the source so masked data never leaves the device.

Retention is the other half. Sentry retains replays for 30 days on Developer and 90 days on Team, Business and Enterprise, and sets the retention period when data is ingested — so upgrading a plan does not extend retention on data already captured. FullStory permanently deletes sessions older than the configured retention period, and only sessions inside that window appear in its session lists at all.

Choosing

flowchart TD
    A[What question are you answering?] --> B{Why do users behave this way?}
    B -->|Yes| C[Analytics replay: continuous capture]
    B -->|No| D{What happened before this bug?}
    D -->|Yes| E[Report-attached replay]
    D -->|No| F[A screenshot is enough]
    C --> G[Budget for session volume and a privacy review]
    E --> H[No session meter; only covers noticed bugs]

Most round-ups of the best session replay tools rank them on features, which hides this split entirely. The honest version of the trade-off: continuous capture answers questions you have not thought to ask yet, and that is genuinely valuable. It costs money per session, it accumulates personal data by default, and it requires somebody to own the privacy configuration forever.

Report-attached replay costs nothing per session and collects nothing until a person files, which makes the privacy conversation much shorter. It also cannot tell you why users abandoned a funnel, because nobody filed a report about abandoning it. If that is your question, buy the analytics product — no amount of bug-report tooling substitutes.

Where TraceItX sits

TraceItX does report-attached replay and nothing else. The software keeps a short rolling window in memory; when someone files a report, that window is frozen and attached and the rest is discarded. Nothing is uploaded unless a report is filed. Replay is switched on per app from the dashboard rather than in code, and sampled — at a rate of one in ten, nine in ten sessions never allocate the buffer at all, which is how the memory cost stays off most users.

The replay arrives inside one AI-ready envelope alongside the annotated screenshot, console and network state, device and app context, and the trail of screens and actions leading to the report. The reason to want it is narrow and real: for a bug that only appears after a particular sequence, the sequence is the bug, and asking a reporter to reconstruct it from memory is how bugs get closed as unreproducible.

On pricing, replay is included on every paid tier and on the free one, though on Free it is withheld while an organisation is over its install limit. Because the meter is monthly active installs rather than sessions or seats, adding replay does not introduce a second variable to the bill.

The one-sentence version

If you need to know why users do what they do, buy session replay software metered on sessions and budget for the privacy work it obliges you to do. If you need to know what happened in the thirty seconds before someone hit a bug, you want replay attached to the report, and you should not be paying per session for it.

Most teams eventually want both. Very few need to buy both at once, and starting with the one tied to your actual open bugs is the cheaper mistake to make.