Chat quietly collects personal data
A live chat widget touches more personal data than teams expect: names and emails from pre-chat forms, the message content itself, IP-derived location, the pages a visitor viewed, and any custom attributes you attach. Under GDPR and similar laws, that is personal data you are responsible for — so the first step is simply knowing what your widget captures and why.
This is practical guidance for support teams, not legal advice; confirm specifics with your own counsel.
Collect only what you will use
Data minimization is both a legal principle and good design. Every pre-chat field is personal data you now have to protect, justify, and eventually delete. If no one downstream acts on a field, it is not "nice to have" — it is liability with no upside. The leanest form that still lets you help is also the most defensible.
Consent and transparency at the point of chat
- Say what you collect. A short line linking to your privacy policy, shown before or as the chat starts, beats burying it in a footer.
- Ask when it matters. Where consent is required, request it at the moment of collection, not retroactively.
- Separate necessity from marketing. Answering the question needs an email; adding them to a newsletter is a different, explicit choice.
Decide a retention window and honor it
Transcripts are useful for training and review — and a growing store of personal data if you keep them forever. Decide how long you actually need chat records, write it down, and delete on schedule. "We keep transcripts for X months" is a policy you can defend; "we never delete anything" is a breach waiting for a bigger blast radius.
Be ready for access and erasure requests
Data subjects can ask what you hold about them and ask you to erase it. Have a repeatable process before the first request arrives: know which systems hold a given person's chat data, be able to export it, and be able to delete it across every store — transcripts, tickets, visitor profiles, and events. MyLiveChat's API includes a data-subject export and a dry-run-first erasure keyed by email, so these requests become a defined workflow rather than a fire drill. The step-by-step version, including which records are found by email and which by phone, is in answering a data erasure request.
Basics that prevent most incidents
Serve the widget over HTTPS, limit who on your team can read transcripts, rotate and scope any API tokens to the minimum they need, and keep an eye on where chat data flows through integrations. Most privacy incidents are not exotic attacks — they are ordinary data kept too long, shared too widely, or reachable by too many people.
Know who else touches the conversation
Before mapping the copies, settle the original: where your chat data is stored is a region you choose, and it is the first thing an assessment will ask about.
Your privacy obligations do not stop at your own database. A chat conversation frequently ends up in
several other places — a CRM record, a ticket, an email notification, an analytics event, a
webhook payload sent to something a colleague configured last year — and each of those is a place
personal data now lives.
Draw the map once. List every integration that receives chat data, what it receives, and who
controls it. Most teams are surprised by the length of the list, and the surprise itself is the point:
you cannot honour a deletion request from a system you forgot exists.
Then check that the map matches your privacy notice. A notice describing a tidy two-system setup
while five integrations quietly receive transcripts is the sort of inaccuracy that turns a routine
question into a serious one.
The paragraphs you actually need to write
Privacy documentation for chat does not need to be long, but it does need to be specific and it
needs to be reachable from the point where someone starts a conversation. Three short passages cover
most of it.
First, what you collect and why — the message content, any name or email the visitor gives,
and the technical details like page and approximate location that arrive automatically. Second, how
long you keep it and what happens at the end of that period. Third, who else receives it, in
categories a reader can understand, plus how to ask for a copy or deletion.
Write these in the same plain register you would use in the conversation itself. A visitor deciding
whether to type their order number into a chat window is not going to read a legal appendix, and a
notice nobody reads provides very little of the transparency it was written to demonstrate.
What to measure
Track how long a deletion or access request takes you end to end, including the integrations. The
first time you run one properly is usually the moment you discover which system nobody can log into,
and it is much better to find that out on a rehearsal than on a deadline.
Check periodically that your retention window is actually being enforced rather than merely stated.
Stated retention with no deletion happening is the most common gap between a privacy notice and
reality, and it is trivially discoverable by anyone who asks for their data.
Watch how often agents ask for information the conversation does not need. Every unnecessary field
collected is data you must now protect, disclose and eventually delete, and the cheapest privacy
improvement available is to stop collecting it.