Deletion policy

• raw events: according to the retention chosen by the tenant, within their plan between 30 and 1,095 days; default 180 days
• derived journeys, touchpoints and attribution shares: for as long as the underlying raw events exist
• rejected events: not stored; for troubleshooting only the reason, time, source, website, event type and the names of the affected fields with type and length of the value are recorded, no field contents and no identifiers; deleted with the raw-data retention period
• conversions: like the raw events, since they arose from them; the records for the tenant’s accounting are held in its own systems, not in the measurement
• answers to the post-purchase question: like the raw events they belong to
• matching data for attribution via the checkout (checksum of the checkout identifier, exact time of the order): at most 24 hours after the order in every place they are stored, on the browser’s events at most 24 hours after they arrive; immediately once attributed
• outgoing webhooks: the content of a delivery until it is delivered or abandoned, at most 24 hours; the log without content 30 days
• ad spend: until the tenant is deleted; as a rule it carries no personal reference
• log of administrative and security-relevant actions, including sign-ins: 180 days per entry, at the latest with all of the tenant’s data 30 days after the contract ends. Where an incident is investigated, the extract needed is secured separately. Minimised records are kept separately: for erasures, objections and withdrawals 90 days outside the database, so that they can be reapplied after a restore; for completed data subject requests until the end of the third calendar year after completion
• website server logs: 7 days
• chat on the website: question, course of the case and any email address given, 30 days after the last message; for a recurring support case, 365 days after the last message
• accounts and access: with the tenant 30 days after the contract ends, insofar as they belong to no other tenant. Kept separately are a minimised record of the conclusion of the contract, as a rule six years after the year of conclusion (§ 257 German Commercial Code), and our invoices as accounting records for eight years; neither is part of the data we process on your behalf

The person is looked up through a pseudonymous identifier — journey identifier, order number, case number or pseudonymised customer identifier. The “Privacy” area in the product shows in advance how many records are affected.

Identity links, journeys, touchpoints, conversions and raw events for that identifier are deleted.

Aggregated figures remain if they no longer carry a personal reference — and only then. That recalculating would be expensive is not a reason to keep anything. A total for one day and one channel says nothing about an individual; a row with the value one would be closer to an event than to a statistic. In reach measured without consent, sources therefore appear individually only from five views upwards, smaller ones are pooled into a single row, and the count expires on the same schedule as the events themselves.

An erasure without lasting effect would be a snapshot: the next event from the same browser would recreate the person under a new identifier. For an objection this weighs heavier than for an erasure — someone who objects to processing does not want to be processed again a minute later.

The identifier is therefore suppressed. Only a checksum is stored, not the value itself. If it were held in clear text, the suppression list would be exactly what it is meant to prevent: a store of the deleted identifiers in plain text. The checksum is nonetheless pseudonymous personal data: it recognises the identifier but cannot be turned back into it. Its processing serves solely to enforce the erasure or objection (Art. 17(1), Art. 21 GDPR); it is read for no other purpose.

A suppression can be lifted, for example if the same person consents again later. The action remains in the log with its time and the person who carried it out.

After termination the data remains available for export for 30 days and is then deleted — measurement data, campaigns, settings, the log, and the accounts that belong to no other tenant. The deletion runs automatically and leaves a record of when it happened and how many rows were removed; that record holds no content.

Backups expire on their own cycle; they are not searched selectively to remove individual records. What is kept is a number, not a duration: in production the last 14 daily backups, so around two weeks with one backup a day, and seven days of transaction log; in the development environment the last seven, without transaction log. These are the backups from which we can restore. Residual copies held by the cloud provider are a separate matter: it removes data we have deleted from its systems under its contract as soon as reasonably practicable and at the latest after 180 days; if a backup is restored, the erasures and objections since the time of the backup are carried out again before release. Statutory retention periods for accounting records are unaffected — what must be kept is blocked for every other use. Our invoices to you are among them; they are our own accounting records and not part of the data we process on your behalf.

Backups are not searched. That has a consequence we name rather than work around: restoring a backup also brings back what was deleted in the meantime. The suppression list lives in the same database and is then at the state of the backup too. So that an erasure stays an erasure, every erasure and objection request since the time of the backup is carried out again before a restored database is released; those requests are held outside the database. Only then does the service accept data again.

The analytics mirror for large-scale reporting is enabled per tenant and holds no direct identifiers, but it does hold keys through which records and journeys can be linked back; it is therefore not anonymous. Deletions reach it: whatever disappears from the database is recorded at deletion time and carried over to the mirror — including rows that were not deleted directly but hung from a deleted record.

Test data lives in its own environment, enters no report, and can be reset in full at any time under Setup.