Skip to main content
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…”

​
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. The one-line version: we built the product so we couldn’t read your leads if we wanted to.