Deletion does not corrupt aggregate analytics

GDPR Article 17(3) explicitly permits retention of data necessary for the purposes of archiving in the public interest, scientific or historical research, or statistical purposes — precisely because deleting event rows that underpin aggregate metrics corrupts the historical record without serving the data subject's interests. CWE-459 (Incomplete Cleanup) describes the other side: cleanup that removes more than necessary. Hard-deleting email event rows during erasure can silently corrupt dashboard metrics (open rates, click rates, send volume charts) by removing the denominator rows their calculations depend on, while the PII attached to those rows is what actually needed to go.

Anonymize event records instead of deleting them. Null out the PII fields while leaving the row intact so aggregate counts remain accurate:

// src/lib/compliance/deletion.ts — anonymize, do not delete, event rows
await db.emailEvent.updateMany({
  where: { contactId },
  data: {
    email: null,
    ipAddress: null,
    userAgent: null,
    // contactId: null  — only if FK allows null; otherwise use a sentinel 'erased' UUID
  }
})

After anonymization, a query like SELECT COUNT(*) FROM email_events WHERE occurred_at BETWEEN ... still returns the correct count, but the row carries no PII. Document this choice in src/lib/compliance/deletion.ts with a comment explaining why anonymization is used instead of deletion — future engineers must not refactor it to deleteMany.