Erasing visitor data (right-to-delete)

In the admin: Privacy — the screen this page documents (opens in the running app).

What/why: Privacy & data governance — what this screen manages and why it exists.

Purpose: honour a right-to-delete request — erase a visitor's NanaSelect behavioral data and queued lead submissions, by anonymous session id or by lead email, with a preview before anything is deleted.

When to use

• A data-subject erasure request (GDPR/CCPA "delete my data") arrives for this app.
• Cleaning up a specific session's captured data after a test or a mis-capture.

Prerequisites

• Admin access with the edit_data capability (any data_editor or admin role).
• The key to erase by: the anonymous session id, or the lead email the visitor submitted.

Steps

1. Open Admin → Privacy (/admin/privacy).
2. Pick the key: by session id (erases that session's behavioral trail) or by email (erases the queued-lead data tied to that address).
3. Click Preview first — it reports what would be deleted, across every table the key touches, without deleting anything.
4. Click Erase to perform the deletion. The erase modules own the cross-table cascade, so nothing is left dangling.
5. The action lands in the audit trail with a masked form of the email — the erased address is never re-stored in plaintext.

Behavior guarantees

• Preview never deletes; erase is the only destructive action and it is audited.
• Erasure is one action per key — no partial table-by-table cleanup to get wrong.
• This erases NanaSelect's copy. Data already synced to Eloqua is governed by Eloqua's own deletion process — handle that side in the marketing platform.

For the lawful basis, the consent gate, and the retention windows that sit around this screen, see privacy, consent & retention.