Two tools on the same page, watching different things
Most websites that run live chat also run something that records behaviour: a session replay tool, a heatmap product, a product-analytics SDK, or all three. They coexist quietly, they are usually installed by different people for different reasons, and almost nobody has written down what the combination actually collects.
That is worth doing, for two reasons. The first is that your privacy notice has to describe it accurately, and a notice written for one tool rarely covers the other. The second is more practical: agents and analysts keep assuming each tool can see what the other one sees, and it leads to bad decisions in both directions.
A session replay tool reconstructs the page. It captures the structure of what was rendered and the visitor's interactions with it, then replays them as something that looks like a video. It can show you a rage-click on a broken button, a form field abandoned halfway, and the exact scroll position where somebody gave up. That is genuinely useful, and it is also the most invasive thing on your page by a wide margin, because by default it is capturing the contents of what people type.
Live chat records the conversation and the context around it. It knows which page the visitor is on, where they came from, roughly where they are, how long they have been on the site and the path they took through it. It records what the visitor chose to send you, and what your agent sent back.
The distinction that matters is between page-level context and page contents. Chat sees which page somebody is on; replay sees what was on the page and what they did to it. Confusing these two is how a team ends up believing an agent can watch a visitor fill in a form, which is a different product with different obligations.
Where the combined picture becomes sensitive
Each tool on its own is defensible. Together they are more than the sum of the parts, and that is where the risk sits.
A chat transcript often contains a name, an email address and an order number, because that is what a support conversation needs. A replay session contains everything the visitor did on the page. If the two can be joined, and they usually can be, because both are keyed to the same visit, you have created a record that ties an identified person to a detailed reconstruction of their behaviour. Neither vendor sold you that record. You assembled it.
The specific hazards are worth naming. Anything the visitor typed into a form before deciding not to submit it may be in the replay. Anything on the page while they were logged in may be in the replay, including other people's data on a shared account. And a support conversation that touches health, finances or a legal problem sits next to a recording of them navigating your site while dealing with it.
Masking is a setting you have to choose
Every serious replay tool can mask input, and the important question is what it does by default. Some mask everything and let you selectively unmask; some mask password fields only and record the rest. Find out which yours does before assuming you are covered, because the two defaults produce very different archives.
Mask by default and unmask deliberately, rather than the other way around. A blanket rule survives the next page somebody adds; a list of fields to hide does not, because the person who builds the next form will not know the list exists.
Pay particular attention to anything that is not obviously a form field. Text pasted into a search box, values rendered into the page after a lookup, and error messages that quote back what the visitor entered are all easy to overlook and all end up in the recording.
Consent and notice cover both, or neither
If you ask visitors for consent before loading tracking tools, decide explicitly which category chat belongs to. Treating chat as strictly necessary and replay as optional is a defensible position, and so is putting both behind consent. What does not work is a banner written for analytics that quietly loads a recording tool, or a privacy notice that describes chat and says nothing about replay.
Write the notice in terms a visitor can act on. Saying that you record how people interact with your pages, and that conversations with your team are stored, is more useful than a list of vendor names. If a visitor asks what you hold about them, you need to be able to answer for both systems, which in practice means knowing how to search both by the same identifier.
Retention is the cheapest control available and the one most often left at the vendor default. Replay data ages badly: a recording from eight months ago will not tell you anything you can act on, and it is still a liability. Set a period you can justify for each tool, and make sure someone owns the job of checking it is applied.
Practical rules for running them together
Write down what each tool collects, in one page, in plain language. This document is what your privacy notice, your vendor reviews and your access requests all draw on, and it takes an afternoon.
Decide who can see what. The people who need replay are usually a small group in product or design; the people who need transcripts are the support team. There is rarely a good reason for the same person to have routine access to both, and separating them is a real control rather than a paperwork one.
Do not paste replay links into chat transcripts. It feels helpful, and it permanently joins the two records in the system with the longer retention and the wider audience.
Finally, use replay to answer questions chat has already raised, rather than browsing it. A transcript that says the checkout would not accept my card is a specific question, and a recording is a fast way to answer it. Open-ended watching produces very little and carries all of the same risk.
How MyLiveChat fits
MyLiveChat's visitor monitoring is page-level. An agent can see which page a visitor is on, the path they took through the site, where they arrived from and how long they have been there. It is not screen capture and not a recording: an agent cannot read what a visitor has typed into a form field, cannot see other tabs or applications, and cannot act on the visitor's behalf. That boundary is deliberate, and it is the reason chat can run on a public page without asking anyone to hand over anything.
Conversations are kept in a searchable archive, which is the record you will need when somebody asks what you hold about them. Because that archive is separate from whatever your replay tool stores, answering an access request means going to both, and it is worth rehearsing that once before you need to do it under a deadline.
What to measure
- Whether your privacy notice names both categories. Re-read it against the one-page inventory above; a notice that only describes one tool is the most common gap and the easiest to close.
- Default masking behaviour of your replay tool. Verify it by recording yourself filling in your own forms rather than by reading the settings page.
- Retention actually applied, per tool. Check that old data is really gone rather than merely scheduled to go.
- How many people hold access to both systems. A number you can say out loud, reviewed when people change roles.
- Time to answer an access request end to end. Rehearsing it tells you whether your two archives can be searched by the same identifier.