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; the shares of a renewal derived from the first order of the same subscription, for as long as that order exists: if it ceases to exist through erasure, objection, withdrawal or expiry of its retention period, the renewal is recalculated immediately and remains unattributed
• 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): used at most until 24 hours after the order, on the browser’s events at most until 24 hours after they arrive, then deleted from the active data in the maintenance cycle; immediately once attributed; in backups until they expire (section 5)
• consent states per browser: until 13 months after the browser’s last change or last visit, whichever is later; the state after a completed withdrawal as proof until the end of the third calendar year after the withdrawal; at the latest with the website or the tenant
• outgoing webhooks: the content of a delivery until it is delivered or abandoned, at most 24 hours; the log without content 30 days; a recipient trail without content (destination, time, checksum of the order or lead identifier) like the raw data, so that recipients can still be named later
• ad spend, also per ad, and costs from further sources and spreadsheets, with the names and IDs of campaigns, ad groups and ads and the addresses of preview images: until the tenant is deleted; names and small numbers can relate to persons
• metrics from the client’s email platforms: until the connection is removed, at the latest with the tenant
• metrics from Google Search Console and ad preview images: not stored, held in memory for no more than one hour; metrics of a disconnected Search Console are no longer returned and are discarded
• credentials for the client’s services, including the address of a spreadsheet: until the connection is removed or the spreadsheet is removed, then deleted immediately; at the latest with the tenant
• recipients of monthly reports: until the client removes them, at the latest with the client account; after unsubscription the entry is deleted immediately and only a block record per client account remains (HMAC of the normalised address, without address, name and unsubscribe token); it is deleted with the client or agency account, as soon as the agency no longer manages the client account, and 30 days after sending to named recipients has been switched off for the agency. During an invitation to resubscribe (at most one every 30 days, valid for seven days), address, name and a hash of the invitation token are held with the block record; afterwards they are cleared
• 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 kept for all tenants of an environment, separated 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.