Data retention
Everything AdPix stores has a defined lifetime and is dropped automatically at the end of it. This page says how long each class of data lives, what never expires on its own, and which of the numbers you can change yourself.
How retention works#
Every table in AdPix has a lifetime. Once a row passes it, AdPix drops it — nothing is asked of you, and nothing can hold it back. That is a different mechanism from removing one person's data on request; that path is an erasure request.
Two things worth knowing:
- The clock starts at a different point per table. For events it is the event's own time, for the raw archive it is the receipt time, for fingerprints it is when they were last seen.
- Deletion happens at the next merge, not at the moment of expiry. The analytical store drops expired data while merging its data parts, and a merge also runs nightly. So crossing the expiry line usually takes hours, not days.
What lives how long#
Analytical data#
| Class of data | Lifetime | Measured from |
|---|---|---|
| Events — what almost every report reads | 25 months | Event time |
| Raw event archive — the original of each message, for debugging and replay | 24 months | Receipt time |
| Sessions | 25 months | Session start day |
| Daily rollup — small, and holds the multi-year trend | 38 months | Day |
| Bot traffic that was discarded | 3 months | Receipt time |
Heatmaps#
| Class of data | Lifetime | How it is enforced |
|---|---|---|
| Raw click, move and scroll points | 90 days by default | Applied nightly; the table's hard ceiling is 400 days |
| The captured page snapshot the replay is drawn on | 180 days by default | Same nightly pass |
Both numbers are set at the platform level and can sit anywhere between 1 and 400 days. Heatmaps are the heaviest data AdPix keeps, so if you need a shorter lifetime this is the first place to negotiate one.
Identity and operations#
| Class of data | Lifetime |
|---|---|
| Recorded fingerprints | 30 days from when last seen |
| Probabilistic identity edges (fingerprint) | 30 days without re-corroboration, then they expire |
| Audit log | 365 days |
| Server-to-server idempotency keys | 30 days |
| Delivered webhook queue rows | 14 days |
| Console sessions after expiry or revocation | 7 days |
Expiring probabilistic edges is an identity decision, not a storage saving: a guessed link between two devices dies unless it is refreshed, while a deterministic one — an email or phone the user typed themselves — stays. The logic is in How AdPix identifies visitors.
What never expires on its own#
None of these has an automatic lifetime:
- Identified users and the identity graph. Email, phone, your CRM's customer ID, traits and deterministic edges. The only way they leave is an erasure request.
- Consent records. They are the record of what each visitor chose, and are kept deliberately; the IP address in them is hashed.
- Order attribution. The frozen channel snapshot for each order, keyed by order ID. It is a business record and financial reporting leans on it.
- The identity override table that resolves anonymous IDs to a user, which is rewritten nightly.
- Your own configuration — properties, streams, segments, audiences, custom definitions, alerts.
Deleting a property or an account is a soft delete: it leaves the lists and sits in Trash until an account manager restores it. No event is removed, and everything stays for its normal lifetime. If your goal is removing one person's data, raise an erasure request.
What you can change yourself#
Table lifetimes are defined at the platform level and property settings carry no field for them. These are the levers you do hold:
| Lever | Where | What it does |
|---|---|---|
| Attribution window | Admin → Property details | How many days a touch stays eligible to take credit for a conversion; the server-side visitor-ID cookie takes its lifetime from the same number |
| Consent expiry (days) | Cookie consent → Builder | How often a visitor is asked again |
| Consent categories | The same page | What is collected at all — a rejected category means its data is never created at the source |
| Enhanced measurement | Admin → Data streams | Which automatic events are sent in the first place |
| An erasure request | Through the API | Immediate removal of one named person's data |
The shortest route to not retaining data is not collecting it. A rejected consent category, or an automatic measurement switched off, creates no row whose expiry you later have to wait for.
What retention does not solve#
- It does not answer an individual request faster. If someone wants their data gone now, waiting out a 25-month expiry is not the answer.
- It does not reach outside AdPix. Events you forwarded by webhook or a CRM module live by that system's rules.
- Backups run on their own cycle and still hold that period's data until they are naturally replaced.
AdPix gives you these numbers and these levers. What your retention policy should be is a decision to take with your own legal counsel.
The conceptual difference between retention and deletion is in Data retention and deletion, and the procedure for removing one person is in Erasure requests.
Frequently asked questions#
Can I shorten event retention for my own property?
No. Event lifetime is defined at the platform level and is the same for every property — 25 months today. There is no field in property settings to shorten or extend it. If your internal policy needs a shorter number, raise it with AdPix.
Why is data past its lifetime still showing in a report?
Because the analytical store drops expired data at the next merge of its data parts, not at the exact second of expiry. A merge also runs nightly, so the gap is usually hours rather than days.
If I delete a property, is its data erased?
No. Property deletion is a soft delete; it moves to Trash and restoring it brings the reports back exactly as they were. The events stay untouched for their normal lifetime. To remove one person's data you need an erasure request.
Do consent records expire too?
No. Consent records have no automatic expiry, because holding the proof is their job — who answered, when, and to which revision of the banner. The IP address in them is hashed and never stored raw.
Thanks — your feedback helps us improve the docs.