Consent, privacy and retention
Setting up consent, choosing what is logged and for how long, and answering a visitor’s data request. Everything on this page is in the free plugin, and stays there.
1. Decide whether to log at all
Go to AnswerRails → Settings → Privacy. The first switch, Save chat conversations for analysis, is off on a new install. With it off, no transcript is written and most of the rest of this page does not apply to you — though the assistant still works, citations still show, and moderation still runs.
If you turn logging on, choose a logging mode. Anonymised (the default) stores a one-way hash of the session id and nothing that identifies the visitor. Identified also stores the session id, IP address, user agent and referrer, which lets you find a specific visitor’s records later — and obliges you to be able to delete them. Both modes are available on every plan.
2. Set retention
Retention period defaults to 180 days and accepts 1 to 365. Once a day, identified logs older than that are deleted. Anonymised logs are not purged by time, because nothing in them can be tied to a person. The privacy-policy text the plugin suggests to WordPress quotes whichever number you set, and WordPress flags the policy for review when you change it.
3. Choose browser storage
Browser storage decides what the widget keeps on the visitor’s device: session (the default) keeps the conversation only until the tab closes; local keeps it across visits; none keeps nothing past a page load. Auto-clear after (minutes, 0 = off) wipes a stored conversation after inactivity. These are settings about the visitor’s browser, not your server; Where your data goes has the full map.
4. Switch consent on, if you need it
Show consent dialog before any chat interaction is off by default. Turn it on and write the disclaimer text the visitor will agree to; it accepts links, line breaks, bold and italics and nothing else. From then on:
The visitor ticks to agree before they can chat.
The tick is sent to your server and stored as a consent receipt: the event, the time, the session id, and a hash of the exact wording on screen at that moment, so you can later show what was agreed to. In identified mode the receipt also carries IP, user agent and referrer.
Consent is checked on the server, not trusted from the browser.
A chat request is accepted only if a matching receipt exists; the widget cannot assert consent it never recorded.
Withdrawing is as easy as giving.
While consent stands, the chat shows an Edit consent control. Using it records a revoked event and the chat closes to further messages until consent is given again. Receipts are append-only: a revocation is added, the grant is never deleted.
Receipts live under Consent Records and are also shown read-only in the Privacy panel. If you change the disclaimer wording, new grants carry the new hash; old receipts keep the hash of what their visitor actually saw.
5. Answer a data request
Two routes, and they work together.
WordPress’s own tools
AnswerRails registers with Tools → Export Personal Data and Tools → Erase Personal Data. These are keyed by email address and WordPress handles the identity check. One quirk of WordPress itself: on the erase screen use Erase personal data (or Force erase), not Complete request, or nothing is actually removed.
The Privacy panel on Chat Logs
For requests that arrive with a session id or an IP address rather than an email, or when you want to see what you hold before acting, use the panel on AnswerRails → Chat Logs. Search by email, session id or IP; then Export (JSON), Anonymise (the default action) or Delete everything. Anonymising strips the identifying metadata and redacts the email — and any phone number — from the transcript text itself, leaving a record indistinguishable from one logged anonymously in the first place. Consent receipts are stripped of IP, user agent and referrer but keep their session id and timestamp, and the response tells the requester so.
6. Legal hold
A record can be placed on legal hold from the Chat Logs screen, and the plugin places one automatically when a conversation trips the self-harm or session-ending moderation tier. A hold does one thing: it keeps the record from being deleted. A held record is skipped by erasure, by hard delete and by the retention purge, and the requester is told an item was retained. Export is unaffected. Nothing is sent anywhere — a hold notifies no one outside your site. Whether a held record is ever shared with anyone is a decision for you as the data controller, made in your own time and on your own advice; the plugin only makes sure the record is still there if you need it. When a hold blocks an erasure, the record is flagged and, on release, you are shown which records still owe a completion, so a request is not forgotten because it was paused.
7. The audit trail
Every privacy action — export, anonymise, delete, hold placed, hold released, erasure deferred and resolved — is written to an audit trail with the time, the admin user, and the record ids involved. It contains no email, phone, IP, session id or transcript content, so it can be kept after the records it describes are gone. It is capped at 1,000 events with a visible count of what has been pruned, it is never exported to a requester and never erased by a request, and the last twenty events are shown on the panel.
It is an ordinary WordPress option that an administrator with database access could alter. Treat it as your own processing record under Article 30, not as independent proof.
8. What goes in your privacy policy
AnswerRails adds suggested text to WordPress’s Settings → Privacy policy guide. It names the provider you actually configured, quotes your retention period, follows your logging mode, and includes the consent, contact-capture and reCAPTCHA paragraphs only when those features are on. It is a starting point for your policy, not a substitute for reading it.
