# How do you choose a session replay tool?

Choose a tool by asking it to help with a real question about your site. Can your team find the relevant visits, understand what happened, and decide what to fix? Test that with your own page states, including errors and privacy boundaries. A polished demo doesn't tell you whether your checkout or navigation will replay correctly.

Keep the shortlist small enough that you can give every candidate the same test. The feature list will help you narrow the options. The investigation will show you whether someone on your team can use them.

## Start with the decision your team needs to make

Write down three questions you expect the purchase to help answer. “Why do mobile visitors fail to finish booking?” gives you something to test. “We need better insights” leaves plenty of room to buy a tool without agreeing on its job. Decide who will investigate, fix the problem, and approve the change.

Those people may need different things. A marketer needs to explain the finding. A developer needs enough page and error context to reproduce it. A team using agents needs to control which evidence the agent can access and check how it reached its conclusions. Include those needs before you compare plans.

You could investigate [Crazy Egg](https://www.crazyegg.com/recordings), [Hoot Lens](https://hootlens.com), [Hotjar (now Contentsquare)](https://contentsquare.com/hotjar/), and [Microsoft Clarity](https://clarity.microsoft.com/). That list isn't a ranking, and the offerings aren't interchangeable. Hoot Lens publishes this guide and belongs on the same scorecard as the others.

Include free and paid options, and check current plans, collection limits, and terms directly. An expensive feature can be worth paying for. First, be able to explain what you'll do with it.

## Give every candidate the same awkward little website

Give each tool a staging page with synthetic content, or a tightly scoped public test page. Include the troublesome parts of your site. If your checkout has a dynamic form, an embedded payment component, and a custom confirmation state, a test page containing one working button won't tell you much.

Prepare a repeatable visit script:

1. Land on the page at a mobile-sized viewport and open a navigation menu.
2. Scroll to an image that loads later, then open an accordion.
3. Begin a form with invented values, trigger a validation error, and recover.
4. Submit successfully and verify the accepted outcome.
5. Follow a client-side route change and use the browser back button.
6. Encounter a deliberate test failure with a clear expected result.
7. Navigate into an excluded page and change the consent preference.
8. Repeat against a second page version with a rearranged layout.

Keep the device, network conditions, and actions consistent. Reset the synthetic data, and test installations separately so several trackers don't influence the comparison. Write down what happened independently of the replay tool. You'll need that record when the playback looks plausible but something seems missing.

## Check fidelity where your site is complicated

Watch the timeline, layout, scrolling, menus, loading states, and route transitions. Compare them with the visit you performed. The recording can look convincing while leaving out the very interaction you need to understand.

Spend extra attention on the components your business depends on: embedded booking services, shadow-root components, canvas charts, videos, or authenticated views your policy permits. Ask the vendor what won't be captured and what requires additional setup. A clearly explained limitation is something you can plan around.

Compatibility limits differ by implementation. Contentsquare's documentation, for example, discusses conditions and limitations around iframes, single-page applications, animations, and canvas. A general “works with your framework” claim does not answer those component-level questions. [Contentsquare web compatibility](https://docs.contentsquare.com/en/web/compatibility/).

Check historical evidence after publishing the second page version. Old clicks should not be presented as if they occurred on a new layout. Inspect how the tool identifies a page version, selects a screenshot, groups devices, and handles assets that have changed or disappeared. Those distinctions matter when you [measure a website redesign](https://hootlens.com/learn/measure-website-redesign/).

Judge each gap against your question. You may be comfortable losing a decorative animation. If the price selector is missing, the same recording may be useless for investigating how people choose a plan.

## Score the investigation, not the dashboard tour

Ask a teammate who didn't create the test to investigate one of its problems. Give them the business question, then see what they need to do. Can they locate the visit, explain the failure, and give another person enough evidence to reproduce it? Count the searching and context-gathering as part of the work.

| Criterion | Strong evidence | Reason to investigate further |
| --- | --- | --- |
| Finding the issue | Relevant visits can be filtered and opened | Only a general alert is available |
| Understanding it | The sequence and page state explain the observation | A label substitutes for visible evidence |
| Sharing it | A teammate can open the exact relevant moment | The teammate must search the session again |
| Comparing changes | Versions and relevant audiences stay distinguishable | Old and new behavior are blended |
| Acting on it | The finding leads to a specific verification task | The recommendation is generic |

Include ordinary visits that succeeded. You need to understand those, too. And check what the tool means by its problem labels. Repeated clicks and pauses can point you toward something worth investigating; they can't reliably tell you how a visitor felt.

If you plan to use automated summaries or agents, ask for the recorded moments behind each conclusion. Include an ambiguous case. You want to know whether the system acknowledges missing evidence or fills the gap with a convincing story.

## Make privacy and access a pass-or-fail check

Define what must never be collected before the trial. Use invented markers to test input masking, private text, URL handling, excluded pages, and consent transitions. A [session replay privacy checklist](https://hootlens.com/learn/session-replay-privacy-checklist/) helps you test collection requests as well as playback. Keep your legal and contractual assessment separate from the technical pass.

Test with different roles and projects. Confirm that a viewer cannot change collection settings and that a project-scoped credential cannot retrieve another project's recordings. Examine share-link controls, expiration, exports, retention, and deletion procedures.

For agent access, find out what “MCP supported” lets the agent do. Can you limit it to reading one project? Can it delete data or change collection settings? Does it get the same evidence boundaries as someone using the interface? These details affect how confidently you can connect it to your workflow.

A privacy failure needs to be resolved before the installation passes. Strong search or a beautiful interface doesn't compensate for sending data your approved policy excludes. Correct the configuration and test again.

## Measure performance and the complete cost

Compare the page with and without the tracker under repeated, comparable conditions. Include a slower device and connection, and examine loading, interaction responsiveness, network transfer, and long-running work. Keep other third-party scripts constant so you know what changed.

Third-party JavaScript can add network and main-thread work; how it loads affects its impact. A small advertised script size alone does not establish a negligible runtime cost. [web.dev on third-party JavaScript](https://web.dev/articles/third-party-javascript).

Ask what happens when collection limits are reached: stopping, sampling, overage charges, or a required upgrade. Check how the product defines a billable unit and whether its retained recordings cover the audience you need to review.

Then account for the team's work: installation, masking maintenance, replay debugging, review, access administration, and exports. A free product may do the job well. A paid one may save meaningful work or provide something you need. Use the trial to find out which is true for your team.

## Choose with a scorecard you can defend

Start with the requirements that must pass, then compare the remaining tradeoffs. Attach the trial evidence and an owner to each requirement. If you haven't tested something, mark it untested. You can investigate a promising sales-page claim without treating it as a completed check.

Explain which questions the tool answered, where it struggled, and what work it will need from the team. Agree on when someone will review findings and who can act on them. Otherwise, you've bought another place where useful information can sit unnoticed.

Revisit the choice when the site or the team's workflow changes. You don't need a tool that wins every category. You need to know what you can depend on it for, where its limits are, and who will turn the evidence into better pages.

## Sources

- [Contentsquare: Web compatibility](https://docs.contentsquare.com/en/web/compatibility/)
- [web.dev: Third-party JavaScript](https://web.dev/articles/third-party-javascript)

## Related reading

- [What should you check before enabling session replay?](https://hootlens.com/learn/session-replay-privacy-checklist)
- [Heatmaps, session recordings, and web analytics](https://hootlens.com/learn/heatmaps-session-recordings-web-analytics)
- [How do you review session recordings?](https://hootlens.com/learn/how-to-review-session-recordings)

---

This is the Markdown copy of https://hootlens.com/learn/choose-session-replay-tool/