​
Anonymous by default

Every deflection carries a browser-scoped anonymous id from localStorage (bq:anon) — a random value that identifies nobody off your site, is readable and clearable by the reader, and is generated on first use. It is the same id the Ask AI widget uses. That sharing is the point: one person who asks the assistant and then reaches the support form has to be one person in both tables, or the deflection rate — the number that says whether the deflector is worth having — is computed against a population that does not exist. Set data-user-analytics-cookie-enabled="false" and no anonymous id is sent at all — a deflection then counts in totals and towards nobody in the distinct-user figures. It is the same switch the Ask AI widget reads, because it is one id in one storage key, and turning it off on one surface and not the other would leave half a reader. If storage is unavailable (private mode, a partitioning browser, a reader who blocked it) the id is empty rather than regenerated per page. A fresh id on every page load would report one determined reader as forty visitors, which is worse than reporting them as none: an empty id counts in totals and is excluded from distinct-user figures.
No IP address is stored. Country, when it is recorded at all, comes from the CDN edge header. Browser and operating system are recorded as family only, never version — a version string is fingerprinting entropy and nothing groups by it.

​
Attributing a deflection to a person

There are two ways, and they compose. The form’s own email field:
The field is read at submission time — not watched, because it is often filled after the deflector attached, and nothing about it is wanted until there is a deflection to attribute. And identity your page already knows, on a signed-in portal: These are the same two attributes the Ask AI widget reads, so one signed-in reader is one reader on both surfaces. userId wins over the anonymous browser id — it is the same person across their devices, which is the whole reason to pass one. The form’s email field wins over userEmail: whoever is signed in is not always whoever is filing the ticket, and the address on the form is the one the reply goes to. What this buys is the join your support team actually needs: the ticket that arrived anyway, and the answer you gave that person twenty seconds earlier, are the same person’s — and the email is the only handle both sides carry.

​
What is kept, and for how long

  • The address is stored on the conversation and nowhere else. It is not written to the deflection analytics row.
  • It is therefore deleted by the same retention job that deletes the conversation, on your workspace’s own schedule.
  • A zero-retention workspace never receives it at all — the field is dropped server-side before anything is written.
  • It is never sent anywhere, matched against anything, or used to build a profile across sites.
It is not validated as an address, either. It is whatever was in the field on a form we do not own, and rejecting a half-typed one would be a rule enforced on someone else’s markup.

​
What the deflector does not do

Nothing is fingerprinted by default. The widget has an opt-in data-user-analytics-fingerprint-enabled that derives an id from the browser instead of storing one, so it survives a cleared localStorage. It is deliberately low-entropy — user agent, language, timezone and screen size, no canvas, no font probing, no audio — and it is still a fingerprint, which is why it is off unless you name it. The deflector does not read it. A support form collects this from people who never signed up for anything, and a durable id they cannot clear is not the default for that. No cross-site identity. The anonymous id is scoped to your site’s storage. It does not follow a reader to your community forum or anywhere else. No third-party analytics. Nothing about a deflection leaves your workspace.

​
Reading it back

A deflection persists a conversation like any other answer, so it appears in Conversations with its questions, answers and citations, and in Analytics in the same counts as your widget and bot traffic. unique_users counts the anonymous id, which is why the widget and the deflector sharing one matters.