> ## Documentation Index > Fetch the complete documentation index at: https://docs.helpalive.com/llms.txt > Use this file to discover all available pages before exploring further. # What data HelpAlive collects, redacts and keeps > What HelpAlive collects in your users' browsers, what the agent sees, what is redacted, how long each kind of data is kept, and how to delete it. HelpAlive collects usage events from your users' browsers the whole time its script runs in your app, and more only when a user uses the chat or an assist. This page lists the data HelpAlive collects about your users, what it does with it, and how long it keeps it. It is for the admins, privacy teams and security reviewers who need to describe HelpAlive in their own privacy notice. ## Data collection at a glance * The script collects no screenshots, screen or session recordings, keystroke timing, screen size or cookies. * Before usage events are saved, our servers scan them and replace personal data, such as names, email addresses and card numbers, with a tag. The scan is automatic and can miss some. * Apart from password, card, one-time-code, file-upload and hidden fields, the page the agent reads is not redacted, because it is what the agent needs to see to help. * Usage events are kept for 12 months. Chat and assist text is kept for your setting, 1 year by default. * HelpAlive's servers, database and backups run in US East (Virginia). ## What the script collects The script records usage events the whole time it runs in your app. Chat and assists send more, only when the user uses them. | What | Details | | - | - | | Page views | Page address, title, and the previous page on your site. Secret-looking parts of the address are removed first (see below). | | Clicks | The element's visible text, label, id, CSS classes, position and state, such as checked or disabled. For text fields, only whether they have a value. | | Field changes | The value typed or picked, and the value before it. Password, card and one-time-code fields send no value, and neither does a field holding a card number. | | Form submits | The submit button's label and the form's name. No field values. | | Errors | Error messages shown on screen. When a request your page makes to change data is rejected, the start of that response, from any server your page calls. | | Seen elements | Once per page, what was on screen long enough to be seen, and whether the user touched it. | | Custom events | Whatever your code sends with `track()`. | | Device facts | Browser and operating system family, device class, language, window size, and a shortened browser description. | | Ids | A random browser id, a random visit id, your tenant's id and name, and the user's id, hashed in the browser. The hash is pseudonymous, not anonymous, which means that anyone with the raw id can recompute it. | | Profile | Display name, email, role, plan and sign-up date, if you send them in `identify()`. Stored as given. | | Verified-users token | If you use verified users, the signed token, sent as a request header. | | Start-up and error reports | When the script starts, its status, version, and the page's host and path. When it fails, the error message and stack. No user ids. | **Not collected:** screenshots, screen or session recordings, keystroke timing, screen size, and cookies. The script doesn't read the user's IP address, though our servers and network provider see it, as every web server does. **In the browser:** the script sets no cookies. It keeps ids, unsent events, the running assist's position, a copy of the widget's settings and the current chat's id in your site's browser storage. Signing out with `reset()` clears the chat entries. ## What is stripped from page addresses Before a page address leaves the browser in a usage event, the script removes: * tokens of every kind, keys, secrets, passwords and one-time codes; * signatures, including cloud-storage signatures; * session ids, user ids and email addresses; * everything after the `#`. This applies to usage events only. The page the agent reads keeps its full address. ## What the agent sees When a user opens the chat, asks a question or runs an assist, the agent reads the page as structured text, never as a picture. It sees: * the page's title, headings and visible text, such as banners and notices; * each button, link and field, with its label, role and state; * **the values in fields**, as shown, except password, card, one-time-code, file-upload and hidden fields, and any field holding a card number. For those it sees only whether the field is filled; * the full page address, the browser's time zone and local date. It also gets the user's message and recent turns, and recent activity on this visit. It gets the role, plan and display name you send in `identify()`, and the matching passages from your docs. The `email` field you send in `identify()` is never sent to the model. Anything else is: if you pass an email as `displayName`, or an email shows on the page or in a chat, the agent sees it. Apart from those fields, the page the agent reads is not redacted. A code typed into a field your page doesn't mark as a one-time code (`autocomplete="one-time-code"`) is included. This is deliberate, because it is what the agent needs to see to help. See [How the AI uses your data](/trust/ai-and-your-data). ## What is redacted, and what is not Before usage events are saved, our servers scan them and replace personal data with a tag, such as ``. The scan looks for names of people, email addresses, phone numbers, IP addresses, card numbers and US social security numbers, in English only. It covers page titles, element text and labels, form names, typed field values and on-screen error text. These are **not** redacted: * chat messages and answers; * assist data, and the page the agent reads; * ids, the profile you send in `identify()` (name and email are stored as given), custom `track()` events and the seen-elements list; * our server logs. ## Our server logs Our server logs can hold your users' chat questions and the page text assists read, but never values typed into fields. They also hold your team's email addresses at sign-in and when invites are sent. Logs are kept for 30 days. Deleting a user doesn't reach these log copies; they age out. ## How long we keep it HelpAlive's servers, database and backups run in US East (Virginia). Each customer's data is kept logically separate, and every request is limited to that customer's own data. | Data | How long | | - | - | | Usage events | 12 months, then deleted month by month | | Summaries built from usage events, such as daily counts and the events around each chat or assist | Until you delete the person or tenant | | User profile from `identify()` | Until you delete that user | | Chat messages and answers, word for word | Your setting, 1 year by default. After it, the words are cleared and the dates and counts stay. | | Assist requests, plans, questions and answers | Same setting as chat | | Assist step titles and the labels clicked | Same setting as chat | | A running assist's working state | Cleared soon after the assist ends or is left | | Records of chat messages and assist starts refused at a limit: who, which limit and when | As long as the rest of that user's data, and deleted with it | | Your docs' text from **Train** | Until you remove the source | | Script start-up reports | 12 months, with usage events | | Chats your team runs on **Test** | 30 days, or your chat setting if it is shorter | | Server logs | 30 days | | Database backups | Taken daily and weekly, and kept for up to about a month | ### Set how long chat and assist text is kept Go to **Settings → Privacy Management**. Under **Chat and assist text**, choose **Keep for**: 30 days, 90 days, 180 days, 1 year (the default) or 2 years. Press **Save** and confirm your password when asked. A shorter window clears older text at the next daily clean-up. It can't be brought back. ## Stop tracking or delete data On **Settings → Privacy Management**, find the person under **People** or the company under **Tenants**: * **Stop tracking** means that their new usage events are dropped as they arrive. **Resume tracking** starts again. * **Delete their data** deletes their usage data and their chat and assist text. The rest is made anonymous, so your counts stay. The reason you give is kept in **History**. Deletions reach the database within a minute, and a second pass 15 minutes later removes anything that was still on its way. Log copies age out within 30 days, and backups within about a month. To delete your whole workspace when you leave, email [support@helpalive.com](mailto:support@helpalive.com). ## Things to tell your users * **Your team can read their chats.** Everyone on your team can read chat transcripts on **Audience**. * **There is no consent mode.** Once the script loads and `identify()` runs, usage events are recorded. To wait for consent, load the script only after the user accepts. See [Consent](/sdk/consent). * **Browser privacy signals aren't read.** Do Not Track and Global Privacy Control don't change what the script does. ## Privacy policy and terms These pages explain how HelpAlive handles data in practice. The legal terms are in our [Privacy policy](https://helpalive.com/legal/privacy) and [Terms of use](https://helpalive.com/legal/terms). ## Next What goes to the model provider, and why. The companies that process data for us. Stop tracking, delete data and set retention. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.