> ## Documentation Index
> Fetch the complete documentation index at: https://docs.granvl.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How zero-PII works

> The architecture that keeps your leads' personal data off granvl's servers entirely.

granvl's privacy posture is architectural, not a policy promise: **lead data has no path onto granvl's servers.** This page explains how each feature works within that constraint, because several of them look impossible at first glance.

## The submit path

When a visitor submits a form on a granvl-served page:

1. The browser POSTs the form **directly to your destinations** (CRM, webhook, Zapier, LeadProsper). granvl's servers are not in the request path.
2. A separate, tiny event beacon tells granvl *that* a submission happened: session, variant, timestamp. No field values, ever.
3. With multiple destinations configured, the browser fans the submission out to each one itself.

There is no server-side buffer, queue, or log holding form contents. The database has no column that could store them.

## "But then how does…"

| Feature                                      | How it works without seeing the data                                                                                                           |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Conversion tracking**                      | The event beacon carries session + variant identity only; conversions and attribution never need field values                                  |
| **[Qualification](/guides/qualification)**   | The rule ships to the browser and evaluates there; only the verdict (qualified / not) is recorded                                              |
| **Delivery confirmation**                    | Where destinations return a readable response, the browser reports accepted / failed; granvl records the status, not the payload               |
| **[Pixels & CAPI](/guides/tracking-pixels)** | Server-side platform events fire from session identity (IDs and hashes), not lead details                                                      |
| **Phone formatting**                         | The formatting rule is baked into the page; the browser formats the value before sending it to your destination                                |
| **Deal values / revenue**                    | Your CRM echoes a value back against a session ID via the qualify webhook; granvl learns "\$4,200" belongs to a session, not who the person is |

## Visitor analytics

* Visitor identifiers are salted hashes, and the salt rotates; sessions can't be walked back to a person.
* Page analytics are aggregate: views, clicks, journeys, devices, sources.
* No third-party pixels are required for any granvl feature; any you add are your choice, configured per domain and disclosed by your privacy policy.

## Why it matters

* Your lead data lives in exactly one place: your stack. There is no second copy to breach, subpoena, or leak.
* Compliance conversations get short: granvl is not a processor of your form data because it never receives it.
* Ad platform reviews (Google, Meta) get simpler for the same reason.

The formal version lives in the [privacy policy](https://granvl.com/privacy). The one-line version: we built the product so we couldn't read your leads if we wanted to.