Data Retention
Retention policies tell the platform to delete certain kinds of records automatically once they're older than a number of days you choose. They're how you apply the GDPR's storage-limitation principle to activity data that stops being useful over time. You'll find them under Settings → Retention Policies.
Access: admins; other roles who open the page see it read-only.
How retention works
- Nothing is deleted by age unless your organization has a policy for that type of data. No policies are set up by default.
- Each policy applies to one data type and deletes records older than its number of days. The allowed range is 30 to 3650 days (10 years).
- A background job applies the policies once a day. By default it runs at 2:00 AM UTC; the Enforce Retention job on the Background Jobs page shows the schedule in effect.
- When the job deletes records, it adds an Enforced Retention entry to the audit log with the data type, the number of days and how many records it deleted.
Large backlogs aren't cleared
If more than 10,000 records of one type are past their limit at once, the job deletes none of them and tries again the next day. A backlog that size doesn't shrink on its own, so the job never clears it.
The data types
The page shows one card per data type, each with a switch, a Delete data older than (days) field and a What gets deleted note. The days value starts at the suggestion shown below when you switch a card on; nothing is switched on by default.
| Card | What it deletes | Age is measured from | Suggested days |
|---|---|---|---|
| Behavioral Events | Contacts' activity history: chat messages, poll votes, offer clicks and similar events. The live-session data itself isn't affected. | When the event was recorded | 365 |
| Segment Members | Links between contacts and segments. The contacts and segments stay. | When the contact was added to the segment | 365 |
| Mobile Push Tokens | Push tokens from the mobile app that haven't been refreshed. The app refreshes its token on every launch, so old tokens usually mean the app was uninstalled or abandoned. | The token's last refresh | 60 |
| Lead Scores | Lead scores, per webinar and overall. Your scoring configuration stays. | When the score was last calculated | 365 |
| Email Send Logs | Not accepted as a retention data type (see below). | 365 | |
| Push Notification Logs | Not accepted as a retention data type (see below). | 365 | |
| SMS Send Logs | Not accepted as a retention data type (see below). | 365 | |
| Job Run History | The run history shown on the Background Jobs page. | When the run started | 30 |
A few side effects to know about:
- Segment Members: for rule-based segments, a contact who still matches the rules is added back at the next segment evaluation, with a new date. The policy mainly affects manually added members. See Segments.
- Lead Scores: scores are calculated from behavioral events. When all of a webinar's scores have been deleted and its behavioral events are still stored, the next lead-score run calculates them again. See Lead Scoring.
- Job Run History: background jobs are shared by all organizations on the platform, so this history isn't only yours, and a policy for it deletes the history for everyone.
Saving policies
Saving is rejected
Save always sends all eight cards, and three of them, Email Send Logs, Push Notification Logs and SMS Send Logs, aren't accepted as retention data types. The whole save is refused with a Failed to save message (invalid data_type: email_sends) and nothing is stored, including your changes to the other cards. As a result, retention policies can't be created or changed from the dashboard.
Policies that already exist for your organization show as switched on, with their number of days, and the daily job keeps applying them.
What retention never deletes
Retention policies can only cover the accepted data types above. Everything else stays until it's removed another way:
| Data | How it's removed |
|---|---|
| Contacts, registrations and attendance, current consent status | Only by a GDPR deletion request. See GDPR. |
| Consent history | Never. After a deletion it's kept without the link to the contact. |
| Funnel entries, including campaign attribution | A GDPR deletion request, or deleting the funnel |
| Landing-page visit records | Deleting the funnel |
| Live-session data: chat messages, display names, presence, poll votes, reactions, offer clicks, feedback answers | Deleting the session or the webinar. A GDPR deletion removes one person's data. Moving a session to replay or archived doesn't remove anything. |
| The copy of each session's chat saved when it moves to replay | Deleting the webinar. Deleting only the session leaves it. |
| Email and push delivery history | A GDPR deletion request |
| SMS delivery history, segment broadcast records | Not removed through the dashboard |
| Automation enrollments and their history | A GDPR deletion request, or deleting the automation |
| AI generation records, webhook activity records | Not removed through the dashboard |
| Audit log and GDPR requests | Never |
| Uploaded files and media | Deleting the item they belong to |
| Anonymous attendee sign-ins | Flush Anonymous Accounts under Settings → Team Members (see Team & Roles) |
Backups are kept for their own cycle, so deleted data stays in backups until they expire.