Data retention and deletion

Retention is how long data survives on its own. Deletion is you asking for it to go now. They are separate paths and they remove different things.

Guide5 minUpdated August 3, 2026

Two entirely different things#

Retention is automatic: every table has a lifetime and AdPix drops rows past it. It asks nothing of you and is the same for everyone.

Deletion is on request: a person asks for their data to be removed, you raise the request, and that person's rows go at once. There is no undo.

Neither substitutes for the other. Retention will not honour an individual request sooner, and erasing one person does not change any table's lifetime.

What is kept, and for how long#

What	How long it is kept
Events — what almost every report reads from	25 months
Raw event archive	24 months
Sessions	25 months
Identity override table (anonymous id to user)	No expiry — rewritten nightly, and cleared by an erasure request
Daily rollup	38 months
Fingerprint edges	30 days
Heatmap raw points	90 days (platform default)
Heatmap page snapshots	180 days (platform default)
Audit log	365 days
Consent records	Kept — they are legal proof

Event retention is applied platform-wide and is not editable in property settings. Heatmap retention can be shortened by AdPix at the platform level and is enforced nightly.

The lifetimes differ on purpose

The raw archive expires a month before the events themselves, because it exists only for debugging. The identity override table is short-lived because it is rebuilt every night from the identity edges. The daily rollup lives longest because it is small and carries multi-year trend.

Deleting a property is not deleting data#

Deleting a property or an account is a soft delete: it leaves the lists and sits in Trash until an account admin restores it. No event is removed. Restore it and the reports come back exactly as they were.

If your goal is data removal, deleting the property is not enough

A deleted property still holds all of its events and keeps them until their retention expires. To remove one person's data you have to raise an erasure request.

Erasing one person's data#

This is the right-to-be-forgotten path. The request is scoped to an organization and only an Org owner can raise it — Org admin is not enough. You identify the person by email, phone number or global user id.

There is no console screen for this today; the request goes through the API:

curl -X POST "$API/api/v1/admin/erasure?organization_id=<ORG>" \
  -H 'Content-Type: application/json' \
  -d '{"email":"person@example.com"}'

Send the phone number in international format with the country code so the match is reliable.

Once the request is raised:

The person's events are deleted from the analytical store — both the main table and the raw archive.
Their sessions are deleted too. That is a separate step, because the session table is built from events and does not retract itself when an event goes.
The identity override rows for their anonymous ids are tombstoned, so any straggler resolves to nobody.
On the transactional side, their email, hashes, CRM client id and traits are scrubbed, and their stored emails, phone numbers, profile, identity attribution, identity edges, first touch and seen fingerprints are deleted.

Every request is written to the audit log — who, when, for which id — without the identity data itself. Reports stop returning that person from the same moment.

What sits outside its reach#

The list is short, but every item matters in practice:

Order attribution is retained. It is a frozen snapshot of each sale's channel, keyed by the order id and the user id. The email, phone and other identity fields are scrubbed, so what remains is an opaque id. It is a business record and financial reports need it.
The audit row itself stays. It records that an erasure happened; it holds no identity content.
Erasure is scoped to one organization. If the same person is also known in another organization of yours, raise the request there too.
What already went out stays out. If you forward events by webhook or a CRM module, the AdPix erasure does not reach that system; delete it there as well.
Backups taken before the request still contain the data until they rotate out normally.

The right order of operations#

If the person only wants collection to stop, withdraw consent or reject the statistics category — no erasure is needed.

If they want their data removed, first establish which organization they are known in, and under which email or phone number.

Raise the erasure request in that organization.

If you forward events to a CRM or another destination, delete there as well.

Confirm in the audit log that the request was recorded.

The difference between consent and deletion is covered in consent categories; who is allowed to raise the request is in roles and data restrictions.

Frequently asked questions#

Can I change event retention from the console?

No. Retention is set at the platform level and is the same for every property - today 25 months for events. There is no screen in property settings to shorten or extend it.

Does deleting a property delete its data?

No. Deleting a property is a soft delete; it only leaves the lists and lands in Trash. The recorded events are untouched, and restoring the property brings the reports back exactly as they were. To actually remove a person's data, raise an erasure request.

Does withdrawing consent delete earlier data?

No. Withdrawing consent stops collection from that moment and clears that category's cookies. What was collected earlier stays until its retention expires, unless an erasure request is raised as well.

How long after an erasure do the reports update?

Immediately. The delete in the analytical store is reflected in query results at once, so the next report no longer returns that person.

Was this page helpful?