Data Retention Policy
Last updated: 16 July 2026
What this policy covers
This page states how long Astrina.io keeps each kind of data, and when it is deleted. It is meant to be read alongside our Privacy Policy, our Cookie Policy and our Security page.
We have written this in specific terms rather than general ones. Where a retention window is a default that the operator can change, we say so. Where data is kept indefinitely, we say that too, instead of implying it expires.
Retention at a glance
| Data type | Retention | Notes |
|---|---|---|
| Raw analytics hits (including the visitor IP address) | Free 33 days · Pro 180 days · Business 365 days · Business Plus 730 days | Deleted by a job that runs daily. The window that applies is the one for the plan of the member who owns the tracked site. The IP address is stored in raw form and is deleted together with the hit row. |
| Custom events and conversions (with the same pseudonymous visitor id as a hit) | Free 33 days · Pro 180 days · Business 365 days · Business Plus 730 days | Deleted on exactly the same schedule and by the same daily job as raw hits, on the plan of the member who owns the site. |
| Aggregated statistics (daily and dimension totals) | Kept indefinitely | Derived from raw hits before those hits are pruned. These are counts and totals only. They hold no IP address and no visitor-level rows, which is why long-range charts survive after the raw data is gone. |
| Session recordings | 30 days | Default window, configurable by the operator. Recordings are masked in the browser before they are sent: password, email and telephone fields never transmit a value, not even its length. |
| SEO reports and per-page monitoring history | 180 days | Default window, configurable by the operator. |
| Bot-classification records (ip_intel) | Kept indefinitely | A record of an IP address and its reverse-DNS hostname, used to flag datacenter and hosting IPs as probable bots. The row holds four fields and nothing else: the address, that hostname, a yes/no datacenter flag and the date it was checked. It carries no pages, no visits and no link to a person. These records are not covered by the daily raw-hit pruning job, so an IP can remain here after the hits that introduced it have been deleted: the classification is what stops those hits being counted as human traffic, and re-doing the lookup every time the same crawler returns would mean querying more, not less. |
| Reviews, ratings and evidence files | Kept while published | A review also stores the submitter IP address, used only to rate-limit abuse, plus the moderation status. Evidence images and video are stored outside the web root and served only through a gated endpoint. |
| Support tickets and messages | Kept while the account exists | Applies to both support desks and your own tickets. |
| Account data | Kept while the account exists | Email address, password hash, role, plan, plan expiry, balance and created date. The password is only ever stored as a bcrypt hash, never in plaintext. |
| Email-verification and password-reset tokens | Until used or expired | Stored as a SHA-256 hash of the token, single-use, with an expiry time. |
| API keys and daily call counters | Kept while the account exists | One key per member, plus a per-day counter of member id, date and number of calls. You can regenerate a key at any time, which revokes the old one instantly. |
| Linked identities from Login with Astrina | Kept while the account exists | For each linked identity we store the provider, the provider user id, and whatever that provider returns to us, which may include email, display name and avatar. |
| Backups | Roughly one daily copy, on the same server | See the section on backups below. Deleted data can still exist in the most recent backup until that backup is rotated. |
Visitor IP addresses in analytics
We want to be plain about this rather than bury it: for every hit we record, the visitor IP address is stored in raw form. It is not anonymised and it is not truncated.
We use it for two things:
- To derive a fallback visitor id, as md5 of the IP, the user agent and the date, when the first-party visitor id is not available.
- To detect probable bots, by classifying datacenter and hosting IPs through reverse DNS. A job runs every 5 minutes over IP addresses seen in the last 4 days, and the result of that lookup is stored in the ip_intel table.
The IP address is retained for exactly as long as the raw hit row that holds it, so the plan windows in the table above are the windows that apply to it. The separate ip_intel record, which holds the IP and its reverse-DNS hostname, is not pruned on that schedule and is kept indefinitely.
Our analytics uses only a first-party visitor id. We set no third-party cookies, we run no cross-site tracking and we use no advertising pixels. We never sell this data and we never share it with advertisers.
Aggregated statistics are kept indefinitely
Aggregated daily and dimension tables are built from raw hits and are kept indefinitely. This is deliberate: it is what lets a chart still show last year once the raw rows behind it have been pruned. These aggregates are totals and counts, not personal-level records, and they contain no IP addresses.
The practical consequence is that deleting raw hits does not reset your historical charts, and aggregated history is not removed by the retention windows above.
Session recordings
If you enable the recorder script, recordings are kept for 30 days by default and the operator can change that window. Masking is on by default and is enforced in the browser, before anything is transmitted:
- Password, email and telephone input fields never transmit a value, not even its length.
- Payment-card fields are treated exactly the same way.
- All other input text is masked to bullets.
- Any part of the page you mark with the data-astr-mask attribute is redacted before it leaves the browser.
Backups, and what that means for deletion
Our server takes a daily backup of files and database, at approximately 05:12 UTC, using the Hestia control panel. In practice roughly one daily copy is retained.
Two things about this are important enough to state plainly rather than leave you to discover:
- The backup is stored in a directory on the same server as the live data. There is no off-site copy and no geo-redundant replication. A failure that destroys the server would destroy the backup with it.
- Because of the backup, data does not always disappear the instant it is deleted from the live system. After we delete something, a copy can still exist in the most recent backup until that backup is rotated and overwritten by a newer one.
If we need to restore the service, we restore from the latest daily backup. We do not guarantee a recovery time or a recovery point, and we do not offer a service level agreement publicly. An SLA exists only under a separately concluded individual contract.
Who can change these windows
The retention windows on this page are the values the service ships with. They are settings, not fixed properties of the system, and the operator can change them in the admin settings. If a window is changed, the daily pruning job simply starts applying the new one, which means data can be deleted earlier than this page describes, or kept longer.
Retention is also tied to plan. If a paid plan lapses, a tracked site falls back to the free retention window, and raw hits older than that window become eligible for pruning.
Deleting your data
There is no self-service account deletion in the panel today. We are not going to pretend otherwise: there is no button for it yet. To have your account and its data deleted, email support@astrina.io and we will do it on request.
Some things you can do yourself, without asking us:
- Delete an individual tracked site from your panel, which removes its data.
- Regenerate or revoke your API key at any time from /my/api.php, which invalidates the old key instantly.
Please bear in mind the two points above: aggregated statistics are kept indefinitely, and deleted data can persist in the most recent backup until it is rotated.
Contact
For any request under this policy, including data deletion and privacy questions, write to support@astrina.io. It is our only contact address, and it reaches us for security reports as well.
Related pages: Privacy Policy, Cookie Policy, Security, Subprocessors, Data Processing Agreement, Terms of Service.
What this page answers
- data Retention Policy
- data Retention Policy guide
- data Retention Policy explained
- data Retention Policy tutorial
- getting started with Data Retention Policy
- data Retention Policy best practices
- what is Data Retention Policy
- data Retention Policy for beginners
- data Retention Policy checklist
- data Retention Policy examples
- why Data Retention Policy matters