Retention depends on the record and purpose
The proposed policy is to retain personal information only as needed for the service, documented customer instructions, security, legal obligations, or disputes, and then delete or de-identify it appropriately. Customers should minimise the information they send and set an agreed retention requirement before collection.
The table below describes repository defaults rather than independently verified production enforcement. Timed database expiry can be asynchronous. Aggregates containing linkable identifiers are not automatically anonymous. The approved operational schedule must include replicas, queues, vendor logs, exports, and backups.
Record-specific defaults found in the code
| Record | Repository default | Limit of that statement |
|---|---|---|
| Raw analytics events, user event projections, and personalisation event projections | 90 days. | Analytics-table TTLs; not every operational or profile copy. |
| Feedback responses, survey responses, and survey attempts in analytics | 365 days. | Analytics-table TTLs; matching transactional response records may have a different lifecycle. |
| Push delivery analytics | 180 days. | Does not by itself remove current device tokens, transactional delivery records, or provider logs. |
| Profiles and some aggregate/projection tables | No universal timed expiry established. | Require customer instructions, data-subject deletion, and an approved account/retention process. |
| Partitioned PostgreSQL operational records | Rotation metadata specifies 13 months for contact ledger; 6 for audience-join state; 25 for prompt impressions/responses and survey-offer ledger; 84 for audit, survey attempts, and survey responses. | Monthly partition rotation differs from analytics TTLs; default partitions and actual worker operation require verification. These periods need necessity/legal review. |
| Projected ingest outbox records | Cleanup default of 7 days for eligible records. | Pending/failed work and other queues require separate checks. |
| Invite/support email outbox records | Cleanup default of 30 days for eligible records. | Does not remove delivered email or vendor delivery logs. |
| MCP operation/effect content | Payload/result redaction after 24 hours; operation/dispatch cleanup after 30 days. | Audit records and external AI-client copies have separate retention. |
| Portal verification codes and sessions | Codes 10 minutes; visitor sessions up to 30 days. | Visitor identities, submitted content, and correspondence remain separate records. |
| Dashboard/account, billing, audit, portal, and support records | No single automatic period established across all records. | A business/legal schedule and deletion procedures must be approved. |
| Private export objects and backups | No verified universal lifecycle in this audit. | A signed export URL expires after 15 minutes by default; the file itself is not thereby erased. |
Deletion scope and timing
The SDK-subject deletion workflow resolves anonymous and identified aliases, removes or redacts matching transactional records, and requires analytics deletion to succeed before completion. Removing a user’s authored request content can preserve unrelated people’s votes, comments, and other engagement.
A successful request acknowledgement means a job was scheduled, not that all processing is finished. This workflow does not establish complete erasure of every portal email identity, account/authentication record, third-party destination, export file, legal record, or backup. Those surfaces must be handled and verified through the relevant process.
Stopping collection, withdrawing a consent purpose, resetting a device, cancelling a subscription, deleting an app user, and closing a workspace are different actions. Re-sent data or restored backups can reintroduce information unless deletion is reapplied. Customers should stop collection for a deleted subject where appropriate.
End of service, backups, and legal holds
The final agreement must specify the export opportunity, active-system deletion deadline, vendor deletion procedure, backup expiry, and exception process. No unverified thirty-day or ninety-day deletion promise is made here. Backup data should be isolated from ordinary processing and prior deletion requests reapplied if restoration is necessary.
Records retained for tax, accounting, security, or claims need a documented purpose, lawful basis, access restriction, and expiry. A legal hold must be limited and reviewed. The operator’s jurisdiction and financial obligations determine the final statutory record periods.
Contact [email protected] with the subject “Privacy request” or “Legal request”, as appropriate. Do not send passwords, API keys, payment card numbers, or identity documents in an initial message.
You can save or print this document using your browser’s print menu. Keep the version and draft status with any copy.