Where your data goes
Every place a visitor’s words travel when they use the assistant, every place they are kept, and every place they don’t go. Written to be checked against the plugin, not taken on trust.
The short version
A visitor’s message goes to two places: your own WordPress site, and the one AI provider you configured, on your own account. It is stored on your site only if you turn logging on. Nothing goes to AnswerRails, to Celtic3D, or to any analytics service. The provider sees the message, the recent conversation, the knowledge-base excerpts chosen for it, and the titles of your site’s pages — and a hashed session identifier, never a name or an address.
1. Browser to your site
The widget talks to your WordPress site’s REST API. Each request carries the message, a session identifier and a per-session token; responses are marked not to be cached. The plugin sets no cookies. What it keeps in the browser is governed by a setting, Privacy → Browser storage, with three modes:
| Mode | What the browser keeps |
|---|---|
| session default | Session id, token, consent state and conversation history in sessionStorage — gone when the tab closes. |
| local | As above, but the conversation history moves to localStorage, so it survives a closed tab. |
| none | Nothing is written; id, token and history live in memory and die on reload. |
Two small preferences — the chat window’s saved size and position on desktop — are kept in localStorage in every mode; they hold no conversation data. An optional auto-clear timer wipes the stored conversation after a number of minutes you choose (off by default). A session that goes two hours without a message is dropped.
If you switch on Google reCAPTCHA v3 (off by default), its script loads when a visitor first opens the chat, and each send carries a token that your server verifies with Google. Google receives that token and the visitor’s IP address. That is the only third-party script the plugin can load, and it loads only if you enable it.
2. Your site to your provider
Before any answer, the visitor’s message is sent to your provider’s moderation service. A blocked message stops there and never reaches the chat model. Then the chat request goes to the same provider, containing:
- the visitor’s message and recent conversation context;
- the excerpts from your knowledge base judged relevant — not the whole knowledge base;
- a list of your site’s published page titles and addresses (public information, but it is sent, so it is listed here);
- a hashed session identifier, passed as the provider’s abuse-monitoring id where the provider supports one (OpenAI and Anthropic do; Mistral has no such field).
Nothing is sent to any provider until you have entered a key, and only the provider you configured is ever contacted. If you use OpenAI’s optional vector store, your knowledge items themselves are uploaded to that store, on your OpenAI account, when you sync them.
3. What your site stores
Conversation logging is off by default. With it off, no transcript is written at all. With it on, each conversation is stored as a private WordPress record, in one of two modes:
| Logging mode | What is stored with the transcript |
|---|---|
| anonymised default | A one-way hash of the session id. No IP address, user agent or referrer. |
| identified | The session id, IP address, user agent and referrer as well. Available on every plan. |
Transcripts are stored as plain text and markdown only; HTML from the model is stripped before anything is saved. Each turn also carries its own record of how it was answered — which sources were used, what the moderation check returned, what outcome it earned.
Other records your site may hold: consent receipts, if you switch consent on (timestamp and session id always; IP, user agent and referrer only in identified mode; a hash of the exact wording agreed to); your knowledge base items and their search index; health metrics per service (success rates, latency, last error — no visitor data); and two privacy ledgers, an erasure log and an audit trail of privacy actions, both deliberately free of names, emails, IPs and transcript content. No location data is stored; an earlier geolocation feature was removed and its history purged.
4. How long it is kept
A daily task deletes identified logs older than your retention period, which defaults to 180 days and can be set anywhere from 1 to 365. Anonymised logs are not purged by time, because there is nothing in them to tie to a person. A record under legal hold is skipped by the purge until the hold is released. Subject-based erasure — a visitor asking for their data to go — is a separate tool and works regardless of retention; Consent, privacy and retention covers it.
5. Licensing and diagnostics
The plugin includes the Freemius SDK, which handles Pro licensing and, for paid plans, billing. Licence status checks go to Freemius. Diagnostic data — your site address, WordPress and PHP versions, and activation events — is sent only if you opt in when asked on activation; the choice is off unless you accept it. No visitor conversation content is involved in any licensing or diagnostic flow.
6. When you uninstall
Deleting the plugin through WordPress always removes your provider keys, the reCAPTCHA secret, every transient and every scheduled task. What happens to the rest depends on one setting, Privacy → Delete all data on uninstall, which is off by default so that a reinstall finds your knowledge base, logs and settings intact. Switch it on and the uninstall removes everything the plugin created — including records under legal hold and consent receipts, which is why the warning sits beside the switch. Removing the plugin’s folder by FTP runs none of this.
The privacy audit trail records what was done, by which admin user, to which records. It is not tamper-evident: an administrator with database access could alter it. Treat it as your own processing record, not as independent proof.
