# everything we store about a visitor, field by field

Every field Spookat keeps when a visitor writes, and what we never keep. Nothing before a click, no IP address, no cookies, and a short list you can check yourself.

2026-11-02 · Kuba

A chat widget sits on your site, in front of your customers, and every one of them is trusting you with whatever it collects. So here's the whole list: every field Spookat keeps about a visitor, when it's written, why it's there and how long it stays. And the longer list of things we never keep.

It's short on purpose. You can read it in five minutes and check most of it in your own browser.

## before a click: nothing about the visitor

The launcher is one file, about 2 kb, from `cdn.spookat.com`. It draws a button. That's all it does until someone clicks it.

- No cookies. Not before a click, not after.
- Nothing in the visitor's browser storage.
- 0 requests to our API.

There's one thing we record at this stage, and it isn't about a visitor. The first time your launcher loads on your domain, we note the time, once per site, so the dashboard can tell you the snippet is live. No page view counts, no visitor count, nothing per person. We genuinely don't know how many people visit your site, and we [measured what other widgets do before a click](/blog/chat-widget-cookies/) to show that this isn't the default.

## in the visitor's browser

When a visitor sends their first message, the widget saves one value in their browser's local storage: a random chat token, under a key named after your site. It's how the widget finds the same conversation when they come back tomorrow.

- It's written only after the first message is saved. Opening the chat and closing it writes nothing.
- It's not a cookie, so it never travels with requests to your site or to anyone else's.
- If the browser blocks storage, the chat still works for that page view. It just won't remember the conversation next time.

On our side, we don't keep that token either. We keep a SHA-256 hash of it, which is enough to recognise it when it comes back and useless to anyone who steals a copy of our data.

## when they send a message

This is the part that matters, so here it is as a table. Each visitor message is stored with a small snapshot of context, taken once, at the moment it's sent.

| field | example | why |
|---|---|---|
| the text | "do you ship to austria?" | it's the message |
| the time | 2026-11-02 14:03 | order and history |
| the page | `https://yoursite.com/pricing` | so your team knows what they were looking at |
| where they came from | `https://news.ycombinator.com/` | same, one step back |
| browser language | `de-AT` | so your team can answer in it |
| time zone and local time | `Europe/Vienna`, 15:03 | "good morning" at the right time |
| the kind of browser and system | chrome on android | "the button doesn't work" makes more sense with it |
| the country | AT | routing and context |
| the widget's language | de | the reply email goes out in it |

Two details on the page fields, because they're easy to get wrong. We drop the query string and the fragment from both the page and where they came from. Query strings are where email addresses, order numbers and tracking ids end up, so they never reach us. And the "kind of browser" is a two-word label like "safari on ios" that we work out in memory. The full user agent string isn't kept.

## what we never store

- **The IP address.** Not in the conversation, not in a log, not in an error report, not in a backup. It's used in memory while the connection is open, to rate-limit and to look up the country, and then it's gone.
- **The full user agent string.** Only the two-word label above.
- **Query strings and fragments**, on any URL.
- **Browsing history.** We see the page where they wrote and the one right before it, both without query strings. Nothing earlier.
- **Behaviour.** No mouse movement, no scroll depth, no time on page, no session recording.
- **A fingerprint.** Nothing that could recognise the same person on another site, or on the same site after they clear their storage.
- **Anything before the click**, as above.

## the country, without the address

The country comes from a file on our own server, the free country database from DB-IP. When a visitor sends a message, the server looks up their address in that file, writes down the two-letter country code, and forgets the address. The address never goes to a third party, and nothing about the lookup is stored except the result. DB-IP's attribution is on our [/privacy](/privacy/) page, as their licence asks.

## if they leave an email

If nobody answers within five minutes, the widget offers once to take an email, so a reply that comes after they've left can reach them. Visitors can also type `/mail` to ask for it themselves. The ask is on every plan; replies go out by email on pro and up.

- We store the address on the visitor, and we use it for one thing: sending them your replies.
- Every reply email has a link to stop, and following it removes the address.
- The email also has a link back to the conversation that works once. We keep only a hash of that link, like the chat token.

No newsletters, no "you might also like", nothing from us. The emails are your replies.

## if your site says who's logged in

On pro and up, your site can tell the chat which of your users is writing. We store your user id on the visitor, and only if its signature checks out with a secret only your server knows. A wrong or missing signature isn't stored at all. We never get your user's name, email or anything else unless you put it in the id yourself.

## what your team adds

The conversation also holds what your side writes:

- your team's messages, with the name each teammate chose to show,
- notes, which the visitor never sees,
- who the conversation is assigned to, and whether it's open or closed,
- intent tags, once they arrive (they're coming soon) and only if they're on for the site.

None of that is data about the visitor's device or behaviour. It's the conversation.

## where it goes, and only if you say so

Everything above stays with Spookat unless you connect something. When you do, the conversation goes where you pointed it, and nowhere else:

- **Slack.** The thread shows the messages, and its status card shows the page, the kind of browser, the country and your user id if you sent one.
- **Webhooks.** By default a webhook carries the full message text, so your CRM or your automation can use it. If you'd rather keep text out of other systems, switch the payload to ids only, and the receiver reads back what it needs.
- **Agents.** An API key or the MCP server lets an agent read and answer conversations, with the same view your team has.
- **Email.** Reply emails carry your team's replies, to the address the visitor left.
- **Intent tags and live translation**, both coming soon, and only if you turn them on. The message text goes to a language model to be tagged or translated, never a name or an email address.

The services we use to run all this, from email delivery to backups, are listed on [/privacy](/privacy/). We don't sell any of it, share it with advertisers or use it to train anything.

## how long it stays

Conversations are deleted after 30 days on starter, 90 on pro and 365 on agency. A visitor with no conversation left is deleted with it, email included. Copies of webhook deliveries, which can carry message text, go after 7 days. Backups age out 30 days after the data they hold was deleted.

Admins can also delete a single conversation whenever they want, and anyone on the team can block a visitor. If the owner deletes the whole site, every conversation and visitor on it is wiped within minutes.

## how to check it

Most of this you can verify without trusting us.

- **Your browser.** Open DevTools on a site with Spookat, reload, filter the network tab by `spookat`. One request before a click. Check Application → Cookies: nothing from us. Send a message and look at local storage: one key.
- **Your export.** The site owner can download everything Spookat holds for the site as one JSON file from the dashboard: every conversation, every message with its context, every visitor's email if they left one. Search it for an IP address. You won't find one.
- **Our test.** Every build runs a test that plays a visitor through the whole product with a made-up address from the range reserved for documentation: chat, replies, an email, webhooks, an export, a delete. At the end it searches everything we stored and every line we logged for that address. It finds nothing, and if it ever does, the build fails.

## what it means for you

When you add Spookat to your site, you can tell your visitors exactly what happens when they write, in two sentences, and it will be true: we keep the message and a little context about where it was written, for as long as your plan's history, and never their IP address. The long version is on [/privacy](/privacy/), with every subprocessor listed.

That's the whole list. [See the plans](/pricing/) and try it on your real site for 14 days, no card.

---
source: https://spookat.com/blog/what-we-store-about-a-visitor/