> ## 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.

# Two-layer PII redaction in browser and on server

> HelpAlive removes personal data twice — once in your users' browsers before anything is sent, then again on our servers before anything is stored.

Personal data is removed in two places before HelpAlive stores anything. This page explains what's removed where, and what's never collected at all.

## What's never collected

Some things never leave your user's browser, ever:

* **What users type into inputs.** We never watch keystrokes.
* **The values inside forms.** When a user submits a form, we know it happened — but the values they typed are not collected.
* **Passwords.** Password fields are excluded completely.
* **Anything you mark private.** Add `data-helpalive-redact` to any element you want excluded — handy for things like account numbers shown on the page.

## What's removed in the browser

Before any data leaves your user's browser, HelpAlive cleans it:

### URLs

If a URL contains something that looks personal, it's replaced before being sent.

| Before                            | After                                                                |
| --------------------------------- | -------------------------------------------------------------------- |
| `/users/jdoe@example.com/edit`    | `/users/:redacted:/edit`                                             |
| `/billing?email=jdoe@example.com` | `/billing`                                                           |
| `/share#token=eyJhbGc...`         | `/share`                                                             |
| `/orders/4827`                    | `/orders/4827` *(plain numeric IDs are kept — they're not personal)* |

### Captured text

Common personal-data patterns are stripped:

| Pattern                   | Replaced with |
| ------------------------- | ------------- |
| Email                     | `[email]`     |
| Phone number              | `[phone]`     |
| Card number               | `[card]`      |
| US Social Security number | `[ssn]`       |
| IP address                | `[ip]`        |

### Element references

When the SDK records that a user clicked something, it doesn't send the element's class names, IDs, or text. It sends an anonymous reference — useful for grouping clicks in analytics, but reveals nothing about what the element actually says.

### If something goes wrong

If anything in the redaction step fails (rare), the data is dropped instead of sent. Better lost analytics than leaked data.

## What's removed on our servers

After the browser pass, the data goes through a second cleanup before it's stored. This second pass catches things the browser layer can't reasonably handle on its own:

* Names and addresses.
* Locale-specific identifiers (national IDs, regional phone formats, address shapes).
* Any edge cases the browser pass missed.

Detected items are replaced with type tokens (`<PERSON>`, `<EMAIL_ADDRESS>`, etc.) before storage.

## What's stored

| Where                  | What's in it                                                                          |
| ---------------------- | ------------------------------------------------------------------------------------- |
| **Adoption analytics** | Cleaned activity events — clicks, pageviews, form submits, friction signals.          |
| **Chat conversations** | Question and answer text, with personal data removed.                                 |
| **User profiles**      | The identity fields you sent through `identify()` — userId, displayName, email, plan. |

## Where text is intentionally kept

Two places keep the user's words on purpose:

1. **Chat conversations.** The whole point of the AI assistant is to read the user's question and respond. Personal data is stripped, but the question itself is kept so your team can read it in [Topics](/studio/topics).
2. **Identity fields** (display name, email). You provide these through `identify()`. They live on the user's profile so your team can search and support — and they can be deleted on request, see [Data deletion](/privacy/dsar).

## Next steps

<CardGroup cols={2}>
  <Card title="Data deletion" icon="trash" href="/privacy/dsar">
    Delete a user's data on request.
  </Card>

  <Card title="Configure consent" icon="shield-check" href="/sdk/consent">
    Pause tracking until consent is granted.
  </Card>
</CardGroup>