Privacy & data governance

What the Privacy screen manages — and why behavioral capture fails closed.

What it is

NanaSelect captures behavioral data (guided-flow activity, leads) only behind an affirmative consent signal, retains it on defined windows, and honours the right-to-delete. The /admin/privacy screen is the erasure surface: preview and erase a visitor's behavioral and queued-lead data by anonymous session id or lead email, cross-table, audited with the email masked.

Consent is owned by Iubenda (via Google Tag Manager on nanawall.com) — NanaSelect shows no banner of its own; the Worker reads Iubenda's consent cookie server-side and gates capture on it.

Why it exists

The one-line policy: capture nothing about an identifiable person, and retain no anonymous analytics, without an affirmative consent signal — and fail closed whenever that signal is absent, unreadable, or unconfigured.

Failing closed is the load-bearing choice. A consent gate that fails open turns every misconfiguration into a compliance incident; failing closed turns it into missing analytics — annoying, but harmless. Reading consent server-side at the edge (rather than trusting client JS) means the gate can't be bypassed by a blocked script or a stale tag. And consent stays with Iubenda because nanawall.com already runs it: one consent banner, one source of truth, no double-asking.

The erasure screen exists because right-to-delete is only real if an operator can actually execute it in minutes: one action per key, cross-table cascade owned by one module, preview before delete, nothing re-stored in plaintext.

In the admin

Screen	How-to
Privacy	Erasing visitor data

Learn more

• Privacy, consent & retention — the full governance layer: lawful basis, consent tiers, retention windows.
• Session store — what an anonymous session actually records.
• The lead lifecycle — the identified half this governs.