What a Session Replay Tool Records on a Practice Website

Every analytics tool on a practice website records that a visit happened. A session replay tool records the visit itself: the pointer moving across the page, the scroll, the hesitation over one field, and in most default configurations the characters typed into that field. It is the difference between a tally and a recording, and on a page carrying an intake form that difference decides whether a vendor is holding an audience metric or a patient's account of why they are calling you.

Practices rarely install these deliberately. They arrive bundled inside a marketing suite, switched on by an agency during a conversion audit, or added by a developer who wanted to see where a form was losing people. The reason for installing one is legitimate. What makes it worth a separate article is that the exposure is not proportional to the intent.

What session replay actually records

The name suggests video. It is not. The tool serializes the structure of the page when it loads, then streams the changes: every mutation to the document, every pointer coordinate, every scroll offset, every keystroke that alters an input. The vendor reconstructs a moving picture from that stream on their own servers. Nothing is filmed, and the result is more precise than film, because it is the underlying data rather than an image of it.

That precision is the point for a marketer and the problem for a medical practice. A heatmap tells you a field was abandoned. A replay tells you what the person had written before they abandoned it.

It also persists. An analytics table is an aggregate that gets less revealing as it ages, because individual rows stop mattering once they are summed. A stored session does the opposite: it stays exactly as revealing on the day somebody asks for it as it was on the day it was captured, and the default retention on these products is measured in months rather than days. Whatever is in the recording is in it for as long as the account exists.

The default masking mode is the whole problem

Every serious tool in this category ships with masking, and the vendors are not hiding it. The question is what the shipped default covers, because a practice that installs a script and never opens the settings has accepted that default on behalf of every patient who fills in the form.

Microsoft Clarity is a useful example precisely because its documentation is explicit. It offers three modes, and the one applied unless somebody changes it is Balanced, described in the vendor's own masking documentation as masking only sensitive content, where sensitive is classified as numbers and email addresses. Strict masks everything. Relaxed masks nothing beyond input boxes and dropdowns.

Read that classification against a medical intake form. A phone number is masked. A date of birth, being numeric, is masked. The free text box asking what brings you in today is not numbers and is not an email address, so under the default it is not sensitive content, and it is the single most revealing field on the page.

This is not a criticism of the tool. The default is a reasonable one for the retail and media sites that make up most of the install base, where the free text field is a search box or a delivery note. It becomes wrong when the same default is carried onto a page where the free text field is a clinical inquiry, and nothing in the installation flow tells the practice that the context changed.

Where session replay crosses into PHI

The legal test does not turn on whether a recording exists. It turns on what is in it and who holds it. Under the HIPAA definitions at 45 CFR 160.103, health information is individually identifiable when it relates to a person's health, care or payment and there is a reasonable basis to believe it can be used to identify them.

A replay tends to satisfy both halves at once, which is unusual. The identifying half is satisfied by the session itself, because the recording carries a persistent visitor identifier and frequently an IP address, and increasingly by a form field the visitor completes inside the same recording. The health half is satisfied by the page they are on and by what they typed. We wrote separately about what actually counts as PHI on a website, and the short version applies here with unusual force: the two halves arriving in the same record is the whole question.

That reframes the vendor relationship. A company reconstructing and storing those sessions on your behalf is handling the information, and under 45 CFR 164.502 that is the relationship a business associate contract exists to govern. Most replay vendors will not sign one, and a practice is entitled to ask before installing rather than after. The same reasoning we set out for analytics vendors and business associate agreements applies without modification.

Consent is a separate question from the contract

A signed contract with a vendor governs what that vendor may do with information you have given them. It does not answer whether you were entitled to collect it in that way in the first place, and on a health-intent page those are genuinely different questions with different answers.

State consumer health data law is where this bites hardest, because several statutes attach their obligations to collection rather than to sale, and a recording is collection at the moment it starts. A recorder that begins before anyone has been asked anything is not made retrospectively acceptable by a later answer, which is the same structural point we made when documenting a real pre-consent leak request by request.

What to do before the next recording

Four steps, in the order that removes the most exposure for the least work.

Find out whether you have one. These scripts are frequently installed by somebody who has since moved on, inside a tag manager container nobody audits. The install is one line and leaves no visible trace on the page, so the only reliable method is to look at what the page actually loads rather than at what anyone remembers approving. This is the step practices skip, because a session replay tool is the rare tracker with no visible artifact at all: no banner, no badge, no widget in the corner, and nothing in the page a patient or a staff member would ever notice.

Decide page by page, not site wide. There is a real argument for studying how people move through a services page or a location page. There is no equivalent argument for recording the consult form, and the two decisions do not have to match. Removing the recorder from health-intent pages keeps most of the analytical value and drops nearly all of the exposure.

If it stays anywhere near a form, mask by element and verify it. Set the strictest mode the tool offers, add explicit selectors for every field, then open a real recording and confirm the fields are blank. A masking setting that was configured and never checked is a belief, not a control, and this is one of the few controls a practice can verify in five minutes by watching one of its own sessions.

Put the recorder behind the same gate as everything else. A replay script is an ordinary third-party tag and can be held until a visitor answers, exactly like an ad pixel. Our note on how consent gating works covers the mechanism, and the one category where a gate genuinely cannot reach is a third-party iframe, which we set out in the embedded form gap.

Set a retention period and hold it. If the reason for recording is to fix a form, the useful life of a recording is the length of that project. Shortening retention to the shortest window that answers the question is the one control that reduces exposure without any ongoing effort, and it is usually a single setting.

The useful frame is not whether session replay is permitted. It is that a recording is a durable artifact that will outlive the marketing question it was collected to answer, and it is worth deciding on purpose who holds it.