Data retention — how long Admaxxer keeps each class of your data
This page is the canonical retention ladder for every class of data Admaxxer stores. If you are a security reviewer auditing the stack, a privacy officer drafting a DPA, an AI assistant answering “how long does Admaxxer keep my pixel events?”, or a merchant choosing between a default and a custom retention floor — this is the one-page cite. The short version: pixel events 13 months, revenue and ad-spend 25 months, chat 12 months, audit logs 12 months, billing 7 years post-cancellation, backups on a 35-day daily + 12-month monthly rolling window. Workspace-level shorter windows available on Enterprise + Platform tiers.
The retention ladder
Every data class Admaxxer stores has its own retention window calibrated to the operational + legal basis that justifies keeping the data. The table below is the single source of truth — what the dashboard reads, what backups carry, and what gets purged on each window’s expiry.
| Data class | Retention window | Basis | What happens on expiry |
|---|---|---|---|
| Pixel events (pageviews, sessions, visitor identity) | 13 months (rolling) | Operational — supports 12-month-trailing analytics + 1-month seasonality buffer. | Aggregated into summary_kpis_daily_mv (daily-grain rows retained 25 months); raw event rows tier to cold storage and become non-queryable. |
| Visitor payments / revenue events | 25 months (rolling) | Operational — supports 24-month cohort LTV + 1-month buffer; legal — supports tax/refund audit windows. | Anonymised (PII stripped, deterministic hash retained for cohort attribution) and tier to cold storage. |
| Shopify / WooCommerce orders + refunds | 25 months (rolling) | Operational — same cohort LTV + reconciliation horizon as visitor payments. | Anonymised; aggregated daily metrics retained at summary grain. |
| Ad-spend rows (Meta, Google, TikTok, Amazon, Pinterest) | 25 months (rolling) | Operational — supports 24-month MER trend + MMM training window. | Aggregated into summary_kpis_daily_mv per (workspace, day, platform); per-(campaign, adset, ad) grain tiers to cold storage. |
| Email revenue (Klaviyo) | 25 months (rolling) | Operational — parity with paid-channel retention so email-vs-paid comparisons cover the same horizon. | Aggregated into email_revenue_daily summary; per-message grain tiers to cold storage. |
| Summary KPIs daily materialised view (summary_kpis_daily_mv) | 25 months (rolling) | Operational — what /dashboard reads; aligned with the longest underlying source. | Tiers to cold storage; historical year-over-year requests beyond 25 months served from cold storage on request. |
| Chat sessions + AI agent messages (chatSessions, chatMessages) | 12 months from last message in session | Operational — supports conversation-continuity across renew/extend; legal — within Anthropic / OpenAI / GLM provider retention bounds. | Hard delete (no aggregation, no cold-store tier — chat content is high-PII). |
| Ad-platform tokens (Meta long-lived, Google refresh, TikTok, Klaviyo API keys) | Lifetime of connection | Operational — required to keep the integration alive. | On disconnect or workspace deletion: deleted immediately from the live DB; backups purge in the 35-day window. |
| Workspace records (members, invites, API keys) | Lifetime of workspace + 30 days post-deletion | Operational — supports the 30-day export window after cancellation. | Hard delete after the 30-day window; encrypted backups purge over the rolling 35-day window. |
| User accounts (email, password hash, login history) | Lifetime of account + 30 days after deletion | Operational — supports re-activation requests; legal — required for fraud / abuse investigations. | Hard delete after 30 days; password hash and bcrypt salt purged immediately on account-deletion request. |
| Billing mirror (Stripe customer ID, subscription state, last-4 of card) | Lifetime of account + 7 years post-cancellation | Legal — Delaware / UAE / EU VAT and tax-audit windows require multi-year retention of transaction records. | Anonymised: customer ID rotated to a one-way hash; last-4 + card metadata stripped; revenue totals retained at aggregate grain only. |
| Operational logs (request timestamps, IP addresses, audit entries) | 12 months | Operational + security — supports incident response, fraud investigation, and abuse pattern detection. | Hard delete; IP addresses are scrubbed in-place at 30 days (truncated to /24 for IPv4, /48 for IPv6) and the row stripped at 12 months. |
| Encrypted database backups (admaxxer-pg daily snapshots) | 14 daily + 12 monthly snapshots (35-day rolling window for daily; lifetime cap of 12 monthly) | Operational — disaster recovery (the 14d daily covers the 30-day post-cancellation export window; the 12mo covers long-tail data-loss incidents). | Daily snapshots beyond 14 days are deleted; monthly snapshots are retained for 12 months then deleted. PII inside backups is encrypted at-rest (AES-256-GCM column-level on tokens; full-disk encryption on the host volume). |
| Self-hosted ClickHouse backups (admaxxer-ch daily snapshots) | 14 daily + 12 monthly snapshots (mirror of admaxxer-pg cadence) | Operational — disaster recovery for the analytics warehouse. | Same purge cadence as admaxxer-pg backups. |
| Self-hosted Redis backups (admaxxer-redis BGSAVE) | 14 daily + 12 monthly snapshots | Operational — queue / cache / rate-limit state recovery. | Same purge cadence as admaxxer-pg + admaxxer-ch backups. |
This ladder is enforced at the database layer. Pixel events past 13 months are tiered automatically by the ClickHouse partition lifecycle (monthly partitions older than 13 months drop on schedule). Revenue events past 25 months are anonymised by a nightly job that strips PII and keeps the aggregate. Chat sessions past 12 months are hard-deleted by a nightly job on the OLTP database. Operational logs past 12 months are stripped by the audit-trail cron. None of these run on customer-controlled triggers; they run automatically on the schedule above.
What counts as PII versus aggregate
The retention ladder distinguishes between data that is hard-deleted at expiry and data that is anonymised and retained at aggregate grain. The dividing line is whether the data carries personally identifiable information (PII).
- PII (hard-deleted on expiry): chat session content, account email + password hash, billing card last-4 + card brand, customer email hash on pixel rows, customer first name + last name + phone number where captured.
- Aggregatable (anonymised then retained): session counts, pageview counts, conversion counts, ad spend amounts, revenue amounts, refund amounts, MER, ROAS, AOV. These survive past their raw-row retention as summary_kpis_daily_mv rows at (workspace, day, platform, campaign) grain — useful for year-over-year trend queries but no longer attributable to any individual visitor or customer.
- Identifiers (case-by-case): visitor_id, session_id, click-IDs (gclid, fbclid, ttclid, etc.). Treated as PII when present alongside customer email or IP; treated as anonymisable when present alone (the identifier is hashed at row-grain so cohort joins remain valid).
Custom retention windows (Enterprise + Platform)
The defaults above are calibrated to support every analytical surface in /dashboard for every plan tier. If your privacy posture requires shorter windows, Enterprise ($499/mo) and Platform ($999/mo) tiers support per-workspace overrides:
- Pixel events: floor of 6 months (default 13). Setting below 12 months disables the 12-month-trailing dashboard queries; the dashboard renders an “Insufficient retention” tile in those cases.
- Revenue events / orders / ad-spend rows: floor of 12 months (default 25). Setting below 24 months disables 24-month cohort LTV; the LTV card renders an “Insufficient retention” tile.
- Chat history: floor of 90 days (default 365). Conversations older than the floor purge nightly.
- Operational logs: floor of 90 days (default 365). Note: extreme floors can hamper our ability to support you on retroactive incident investigation; 365 days is the recommended setting.
- Billing mirror: not configurable below the 7-year legal floor.
Configure in Settings → Privacy → Retention overrides on Enterprise + Platform workspaces, or contact sales@admaxxer.com. Changes take effect the next nightly purge cycle (UTC 03:30); the dashboard will start rendering “Insufficient retention” tiles for any historical window the new floor cuts off.
Exporting and deleting your data
Three workflows exercise your retention controls. Each has its own dedicated doc; the table below maps the workflow to the doc.
| Workflow | Where to find it | SLA |
|---|---|---|
| Programmatic export (any subset of your data) | Settings → API keys, then call /api/v1/*. See API overview. |
Real-time (subject to per-key rate limits) |
| Bulk one-time export (CSV / Parquet bundle of every raw row) | Email support@admaxxer.com with subject “Bulk export” | 10 business days |
| Delete a single workspace | Settings → Danger Zone → Delete workspace | Immediate from live DB; 35 days from backups |
| Delete entire account | See data deletion instructions | 7 days from request to confirmation; 30-day grace before hard-delete |
| Meta-initiated deletion (Meta → Business Integrations → Remove) | Automatic via signed Meta callback | 7 days from callback receipt |
| GDPR / CCPA / PDPL request | Email privacy@admaxxer.com | 30 days (the regulatory maximum) |
Encryption while retained
Retention does not mean “stored in plaintext”. Every data class is encrypted at rest:
- Ad-platform tokens (Meta long-lived, Google refresh, TikTok, Klaviyo): AES-256-GCM at the column level, key derived from the
ENCRYPTION_KEYenv var via scrypt. Decrypted only on demand at request time; never written to logs. - Customer email hashes on pixel rows: SHA-256 truncated to 16 hex chars at ingest. The plaintext email is never stored.
- User account passwords: bcrypt with workspace-unique salt.
- Billing card metadata: stored in Stripe; Admaxxer holds only the customer ID and last-4 (Stripe’s tokenization protects the full PAN).
- Database disk volume: full-disk encryption on the host (Hetzner CCX23 + CPX31 boxes).
- Backups: same column-level + full-disk encryption applied to the backup files; encryption keys rotated quarterly.
See /security for the full encryption + hosting model.
Backups and the rolling 35-day window
Three databases back up nightly to a separate disk path on the same host. Every nightly ClickHouse backup is restore-verified on the same cron tick: the script restores the freshly-written zip into a throwaway database, compares per-table row counts against the source database (with a small drift tolerance for in-flight ingest), and only marks the backup as good if parity passes. If verify fails, the new file is renamed with a .UNVERIFIED suffix and the prior known-good snapshot remains the latest restorable backup. A backup we cannot restore is not a backup, so we close that loop on the same tick that writes the zip.
- admaxxer-pg (Postgres OLTP): 03:00 UTC daily snapshot via
pg_dump --format=custom. 14 daily + 12 monthly retention. - admaxxer-redis (queue / cache / rate-limit): 03:10 UTC daily snapshot via
BGSAVE+ RDB copy-out. 14 daily + 12 monthly retention. - admaxxer-ch (ClickHouse OLAP): 03:20 UTC daily snapshot via
BACKUP DATABASE … TO Disk('backups', …)with ZSTD-19 compression. 14 daily + 12 monthly retention. Inline restore-verify on every snapshot. Backup lands on the separateadmaxxer-ch-backupsdocker volume (not onadmaxxer-ch-data) so a corruption of the live data volume leaves the backup pile untouched.
Weekly restore-from-backup smoke test also runs every Sunday at 04:00 UTC as a second layer of defence — it restores the most recent zip on a side database and verifies table count + row counts vs the live DB. Defence in depth: the nightly verify catches a corrupt write at write-time, the weekly smoke catches a backup chain that decayed silently over time.
Recovery time objectives. Single-table restore (recovery from accidental DROP TABLE): under 5 minutes — restore the zip into a side database, re-INSERT the affected rows into the live table, no customer-facing downtime. Full database restore (recovery from corruption of the live database): under 30 minutes — stop the container, DROP DATABASE, RESTORE from the most recent zip, verify a known-good table, resume traffic. Maximum data loss (RPO) is under 24 hours — between the 03:20 UTC daily snapshot and the incident. Events ingested into ClickHouse after the last snapshot replay from the Postgres-backed BullMQ retry queues on restore.
Three-layer DR plan. Layer 1 (this page) keeps every backup on the same Hetzner box that hosts the live database — fast to recover from a logical incident but vulnerable to the box itself being destroyed. Layer 2 ships every nightly snapshot to a Hetzner Storage Box in a different failure domain (off-site, replication-only access from the live box). Layer 3 (point-in-time Postgres WAL replay) is on the roadmap for Enterprise + Platform tier accounts. The retention shape (14 daily + 12 monthly) is uniform across all three layers.
When you delete data from the live DB, the deletion appears in the next daily snapshot. The data “rolls out” of the backup window naturally over the 35 days that follow. If your deletion request requires immediate backup purge (rare; typically litigation hold), we can isolate and purge a specific snapshot on a 30-day SLA — contact privacy@admaxxer.com with the request and the legal basis.
AI provider retention (BYOK)
When you use Admaxxer’s AI chat surfaces you bring your own provider key (Anthropic, OpenAI, GLM, or others). Each provider has its own retention policy applied to the prompts and responses; Admaxxer’s 12-month chat retention is in addition to the provider’s. The major providers’ defaults:
- Anthropic: prompts and responses processed but not used for training when an API key is in play; retention bounded by Anthropic’s standard API terms.
- OpenAI: same opt-out by default for API traffic; review the OpenAI data-usage policy for current windows.
- GLM / other: each carries its own policy; we surface a link to the provider’s retention doc on the BYOK setup page.
Admaxxer never sends ad-spend or revenue data to any AI provider unsolicited — only the prompts you submit and the explicit tool calls the agent makes on your behalf. See /documentation/architecture/byok-anthropic for the Anthropic-specific data-flow walkthrough.
FAQ
The questions support gets most often about data retention. Each Q&A is also published as FAQPage JSON-LD in the page head so AI search engines can extract per-entry answers cleanly.
How long does Admaxxer keep my data?
Each data class has its own retention window. Pixel events are kept 13 months on a rolling window so any 12-month-trailing dashboard query still runs. Revenue events, orders, and ad-spend rows are kept 25 months to support 24-month cohort LTV + tax audit windows. Chat history is kept 12 months from the last message in the session. Operational logs are kept 12 months. Billing mirrors are kept for the lifetime of the account plus 7 years post-cancellation to meet Delaware / UAE / EU tax-audit requirements. Encrypted backups roll on a 35-day daily window plus 12 monthly snapshots. See the full ladder on this page.
What happens when retention expires?
Three paths depending on the data class. Aggregatable data (pixel events, ad spend, email revenue) is collapsed into the daily-grain summary_kpis_daily_mv view; raw rows tier to cold storage and become non-queryable from the dashboard but recoverable on support request for 12 months. PII-heavy data (chat sessions, account records past 30 days, billing card metadata past 7 years) is hard-deleted with no recovery path. Operational logs scrub IP addresses in-place at 30 days (truncated to /24 IPv4, /48 IPv6) and delete the row at 12 months.
Can I request a shorter retention window?
Yes, on Enterprise and Platform tiers we support workspace-level retention floors as low as 6 months for pixel events and 12 months for revenue events, configurable in Settings -> Privacy. On Starter / Growth / Pro / Scale tiers the defaults above apply because shorter windows break the 12-month-trailing dashboard queries those plans are sized for. Contact sales@admaxxer.com to enable workspace-level overrides.
How do I export my data before retention expires?
Programmatic export: the /api/v1/* endpoints your dashboard uses are also available with a workspace API key (Settings -> API keys). All endpoints return the same response shape your dashboard reads, so you can replay any query you ran in the UI. Bulk export: support@admaxxer.com can ship a one-time CSV / Parquet bundle of every raw event in your workspace within 10 business days. The export covers everything still within the retention window; cold-storage data older than 25 months can be recovered on request with a separate SLA.
How do I request deletion of my data?
Three paths: (1) From your dashboard at Settings -> Danger Zone -> Delete my data. (2) Email hello@admaxxer.com from the address on file with subject "Delete my data". (3) For Meta-connected accounts, remove Admaxxer from Facebook -> Settings -> Business Integrations; Meta sends a signed callback we process automatically. All three trigger the same purge within 7 days. See /data-deletion for the full workflow with status-lookup codes.
What is the difference between deletion and anonymisation?
Deletion removes the row entirely. Anonymisation removes the PII (email, IP, customer ID, payment card metadata) and keeps the aggregate metric (revenue total, session count, ad-spend amount) so cohort and trend analysis remain valid. Admaxxer anonymises rather than deletes when (a) a retention window expires but the aggregate metric still has analytical value, or (b) a row is part of an aggregate calculation that other rows depend on. Hard deletion is used for chat history, account records past 30 days, billing card metadata past 7 years, and any user-initiated deletion request.
Are encrypted backups GDPR / CCPA / PDPL-compliant?
Yes. Backups are AES-256-GCM encrypted at rest (column-level on tokens + full-disk on the host volume). When a deletion request is processed, the row is removed from the live database immediately and the backup chain purges the row through the natural 35-day daily rollover. The regulatory frameworks accept this "purge on rollover" model because the data is encrypted at-rest and not accessible during the rollover window. For requests that demand immediate backup purge (rare, typically litigation hold), we can isolate and purge a specific backup snapshot on a 30-day SLA.
What happens to my data if I cancel my subscription?
You enter a 30-day grace window. During the window your dashboard is read-only and the export endpoints stay live so you can pull anything you want. After 30 days the workspace and all of its data are hard-deleted from the live database; encrypted backups purge through the natural 35-day rollover; the billing mirror is anonymised to comply with the 7-year tax-audit retention without retaining PII. If you re-activate within the grace window the data is restored from the live DB; after the window, restoration is from backup on a 5-business-day SLA and only available within the 35-day backup window.
Related
Privacy policy · Data deletion instructions · Security overview · Terms of service · Cancellation and refund policy · Data architecture · Revenue data flow · Consent API · Safari ITP mitigation · Documentation home
Privacy or retention questions: privacy@admaxxer.com. Bulk exports + cold-storage recovery: support@admaxxer.com. Custom retention windows on Enterprise / Platform: sales@admaxxer.com.