The nine data kinds and their defaults
| Data kind | Default | Why this long |
|---|---|---|
| events | 395 days | thirteen months allows year-over-year comparison with a month of overlap |
| click_ids | 90 days | the longest attribution window in common use |
| consent_snapshots | 1,095 days | proof of lawful processing across the limitation period most operators apply |
| delivery_attempts | 90 days | enough to debug vendor disputes and monthly reconciliation |
| audit_log | 730 days | configuration and access history for two annual review cycles |
| chat_transcripts | 30 days | AI assistant conversations are operational, not records |
| raw_archive | 14 days | replay buffer for incidents; contains unprocessed payloads |
| dsar_records | 1,095 days | demonstrates that requests were handled |
| ip_hashes | 30 days | abuse detection only; the salt rotates, so older hashes are unusable anyway |
Each window is a default, not a recommendation for every business. A retailer with a 14-day return policy may cut delivery attempts to 30 days; a B2B company with 9-month sales cycles may extend click ids to that length if its ad platforms' windows actually go that far. Extending a window beyond the default is a decision to document in your records of processing; the change itself is written to the audit log.
Scope and precedence
Retention is set per organisation and can be overridden per site for events and click ids; delivery attempts, audit log and chat transcripts are organisation-wide. The effective window is the site override if present, otherwise the organisation value, otherwise the default. Shortening applies at the next daily run; lengthening applies only to records not yet expired — there is no resurrection.
Enforcement
- A retention job runs once a day. For events it applies the effective window per site and deletes older rows; the event store is partitioned by month, so most expiry is a partition drop rather than row deletes.
- After the click-id window, click ids and vendor ids are removed from events that are otherwise kept, so a thirteen-month event history does not carry thirteen months of attribution identifiers.
- Delivery attempts, audit log and chat transcripts are deleted per organisation with the organisation's window; dedup keys, nonces and attribution touchpoints expire on their own schedules.
- Each run logs the number of rows removed per data kind; the worker log is the evidence that expiry ran.
- Backups follow the same windows plus the backup cycle; the security page states the backup retention so the total lifetime is knowable.
What retention is not
- It is not anonymisation. Aggregates computed from events (daily counts, health scores, funnel rates) are kept beyond the event window because they contain no personal data; the policy page names them explicitly.
- It is not vendor retention. What Meta or Google keep follows their terms; the subprocessor page links to each vendor's retention documentation.
- It is not a substitute for consent. Short retention of data collected without a legal basis does not make the collection lawful.
Setting it up
- Open Privacy → Retention, review the defaults against your actual reporting and attribution needs.
- Shorten anything you cannot justify; extend only with a written reason.
- Confirm the site overrides for sites in different jurisdictions or with different business models.
- Check the status page after the first scheduled run; the job entries are your evidence.