Data retention

Per plan

Plan	Retention
Hobby	30 days
Pro	2 years (730 days)
Business	5 years (1,825 days)
Enterprise	negotiated

There is no automatic deletion job today

The retention window is what the plan entitles you to. No scheduled job that enforces it exists in the repository, so older data may still be present.

If deletion by a date is a contractual or regulatory requirement for you, confirm the operational position with the operator in writing rather than inferring it from this table — and use the manual controls below in the meantime.

What you can delete, and how

Reset site data

Settings → Danger zone → Reset data. In one transaction, for that site:

• every session
• every event — which cascades into event properties
• every visitor trait

Revenue is made of events, so it goes with them.

Kept: the site, its key, its settings, its goals and its saved reports.

There is no undo and no confirmation dialog.

Delete a site

Settings → Danger zone → Delete. Type the domain to confirm.

The site row is marked deleted: it leaves the dashboard, its public key stops resolving, and the tracker on your pages starts getting 404.

Delete is a soft delete

The collected rows stay in the database until a cleanup job removes them, and no such job ships today. If your requirement is erasure, run Reset data first, then delete.

Delete an account

From /dashboard/account. Account deletion is handled through the authentication provider.

Handling a data-subject request

A cookieless visitor id is derived from an IP address and a user agent and rotates daily. That has two practical consequences for a request from one of your visitors:

1. You cannot look them up. Nothing in the database maps a person to a visitor id, and the id cannot be recomputed from an IP because the salt has rotated. The only exception is a visitor you identified yourself.
2. The data ages out of usefulness quickly. A day-old id links to nothing.

Where you have identified someone:

• Search their email or user id in the Sessions search box — it matches trait values — to see the visits for that UTC day.
• Their traits, events and sessions are removable only by resetting the whole site today. There is no per-visitor delete in the UI.
• For a per-visitor erasure, contact the operator with the visitor id or the identified trait; the rows are keyed on visitor_id across events, event_data, session_data, sessions and web_vitals.

If you put an email address or an order id in the properties of a revenue event, that property row is usually the one an erasure request really concerns.

Backups

Backup schedules and their retention are a property of the deployment, not of this product. Ask the operator.

Related

• What is stored
• Plans & limits
• Settings