Retention schedules
A retention schedule is a documented table that assigns each category of analytics data a defined keep-period and a disposal action (delete or anonymise) when that period ends. It operationalises the storage-limitation principle: rather than keeping data 'just in case', you decide up front why and how long each field is needed. This page is educational, not legal advice.
What a schedule defines
A retention schedule lists, for each data category — raw event logs, aggregated reports, identifiers, IP-derived data — the retention period and the action at expiry. The action is usually deletion or irreversible anonymisation. Periods should be justified by the purpose (for example, comparing year-over-year trends may justify keeping aggregates longer than raw logs). The schedule is the bridge between the storage-limitation principle and the actual deletion jobs that enforce it.
Why aggregates and raw data differ
Not all analytics data deserves the same lifespan. Raw, per-event logs that may contain identifiers carry more risk and usually warrant the shortest retention; once aggregated or anonymised, data poses less privacy risk and may be kept longer for trend analysis. Tiering retention this way satisfies the purpose test while preserving useful reporting. Crucially, a schedule is only effective if automated deletion or anonymisation actually runs — a documented period with no enforcement is a paper promise.
Review periods as purposes change.
- Per-category keep-period plus a disposal action
- Shorter retention for raw, identifier-bearing logs
- Enforce with automated deletion or anonymisation jobs
How it appears in analytics and logs
If raw analytics events accumulate with no defined deletion date, you lack a retention schedule; a schedule makes storage limitation concrete and enforceable.
Diagnostic use case
Assign each analytics data category a defined keep-period and disposal action, so data is not kept indefinitely beyond its measurement purpose.
What WebmasterID can help detect
WebmasterID favours short-lived, minimised measurement; a retention schedule makes the keep-and-delete rules explicit per data category.
Common mistakes
- Documenting a period but never running deletion.
- Applying one retention period to raw logs and aggregates alike.
- Keeping identifier-bearing logs 'just in case'.
Privacy and accuracy notes
This page is educational, not legal advice. Storage limitation expects data be kept no longer than necessary for the purpose it was collected.
Related pages
- Data retention in analytics
Data retention is the policy for how long an analytics system stores collected data before automatic deletion. Many platforms expose configurable retention windows for user- and event-level records. Shorter windows reduce breach exposure and support data-minimisation principles, while aggregate reports can often outlive the raw data. This is an educational overview, not legal advice.
- Retention and deletion policies
Storage limitation means keeping personal data only as long as the purpose needs, then deleting or anonymising it. For analytics, that means defining retention windows tied to a stated purpose, automating deletion, and being able to honour erasure requests. This page explains, educationally, how to build retention and deletion practices for analytics data.
- Data minimisation in analytics
Data minimisation is the principle that personal data should be adequate, relevant, and limited to what is necessary for the purpose. In analytics it translates to: do not collect identifiers you will not use, prefer aggregates over per-person rows, and avoid storing precise values like full IPs. Minimising at collection beats trying to protect data you never needed. This is educational, not legal advice.
- Privacy-first analytics
Short-lived measurement makes retention rules simpler.
Sources and verification notes
- EUR-Lex — GDPR Article 5(1)(e) (storage limitation)Primary basis for time-bounded retention. 'Retention schedule' is the operational practice. Educational, not legal advice.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.