> For the complete documentation index, see [llms.txt](https://docs.mediarithmics.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediarithmics.io/setup-and-monitor/plan-and-integrate/set-up-the-environment/manage-data-retention.md).
# Data retention
Decide how long each kind of data lives in your datamart, and know which windows you cannot change.
## Your goal
Decide, before you start collecting, how long each kind of data stays in your datamart - and understand which retention windows you control and which are fixed by the platform.
## Expected outcome
A retention decision per data class, implemented as cleaning rules for the data you control, and no surprises about the data whose window is fixed.
{% hint style="danger" %}
Retention for user data is enforced by cleaning rules, and **cleaning rules are not retroactive**. The expiration timestamp of an object is computed when the object enters the datamart, becomes part of the object, and cannot be modified afterwards. Changing the rules only affects future incoming events and profiles. Decide before you collect.
{% endhint %}
## What you control: user data
The retention of your user data is governed by **cleaning rules**, defined per datamart in **Settings > Datamart > Cleaning Rules**. They apply to two objects - events and profiles - and each rule combines an action (`KEEP` or `DELETE`), a duration, and a set of filters.
Two decisions to take per data class:
| Decision | Consequence |
| ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| How long **events** are kept, overall and per channel, activity type, or event name | Behavioural history available for segmentation, analytics, and funnels. |
| How long **profiles** are kept, overall and per compartment | Known-customer data available for personalisation and activation. |
{% hint style="info" %}
Cleaning up events and profiles cleans up your UserPoints too: when a UserPoint has no activity, no profile, and no `USER_LIST` segment, it is removed from the platform.
{% endhint %}
For the full mechanism - how rules are prioritised, how their lifecycle works, and worked examples - see [Cleaning rules](/setup-and-monitor/collect-and-manage-your-data/clean-and-delete-data/cleaning-rules.md).
To remove data for a specific person rather than by policy, see [Delete user data](/setup-and-monitor/collect-and-manage-your-data/clean-and-delete-data/delete-user-data.md) and [Exercise rights of the user](/setup-and-monitor/ensure-privacy-and-compliance/exercise-rights-of-the-user.md).
## What you control partly: device identifiers
You can set an **expiration duration** for identifiers stored in device registries you created manually. It applies only to identifiers captured after the duration is set.
Device technical identifiers are stored for a period of **one year** after their creation.
See [Device registries](/setup-and-monitor/plan-and-integrate/set-up-the-environment/set-up-device-registries.md).
## What is fixed by the platform: derived and monitoring data
These windows are not configurable. Design your reporting around them - if you need a longer history, extract the data before it expires.
| Data | Retention |
| -------------------------------------- | ----------------------------------------------- |
| Activities analytics data | 4 months, to keep query performance predictable |
| Events ingestion monitoring statistics | 3 months |
| Collection volume statistics | 2 years |
| Usage report statistics | 2 years |
Where you read each of these is covered in [Operate & monitor](/setup-and-monitor/operate-and-monitor/monitor-data-ingestion.md).
## Plan it in this order
{% stepper %}
{% step %}
### Write down the requirement per data class
Legal or contractual retention obligations, and the analytical history your teams actually need. These usually differ by channel and by event type, which is exactly the granularity cleaning rules support.
{% endstep %}
{% step %}
### Translate it into rules before collection starts
Because expiration is stamped on write, rules that arrive after the data does not fix the data already stored.
{% endstep %}
{% step %}
### Keep an escape hatch
`KEEP` rules take priority over `DELETE` rules, and there must always be a `LIVE` event-based rule with a `DELETE` action. Plan the combination deliberately rather than adding rules one at a time.
{% endstep %}
{% step %}
### Extract what you need to keep longer
For anything whose platform window is fixed and shorter than your requirement, schedule an export. See [Export your data](/setup-and-monitor/collect-and-manage-your-data/export-your-data.md).
{% endstep %}
{% endstepper %}
## Verify
* Every data class in your tracking plan has a stated retention, and a rule that implements it.
* The rules that must be `LIVE` are `LIVE`, not `DRAFT` - only `LIVE` rules are taken into account when computing an expiration timestamp.
* Any reporting that needs more history than a fixed window allows has an export in place.
## Related pages
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.mediarithmics.io/setup-and-monitor/plan-and-integrate/set-up-the-environment/manage-data-retention.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.