Die neun Datenarten und ihre Standards
| Datenart | Standard | Warum so lang |
|---|---|---|
| events | 395 Tage | dreizehn Monate erlauben den Jahresvergleich mit einem Monat Überlappung |
| click_ids | 90 Tage | das längste gebräuchliche Attributionsfenster |
| consent_snapshots | 1.095 Tage | Nachweis rechtmäßiger Verarbeitung über die Verjährungsfrist, die die meisten Betreiber ansetzen |
| delivery_attempts | 90 Tage | ausreichend für Anbieter-Streitfälle und monatliche Abstimmung |
| audit_log | 730 Tage | Konfigurations- und Zugriffshistorie für zwei jährliche Prüfzyklen |
| chat_transcripts | 30 Tage | Gespräche mit dem KI-Assistenten sind operativ, keine Aufzeichnungen |
| raw_archive | 14 Tage | Replay-Puffer für Vorfälle; enthält unverarbeitete Payloads |
| dsar_records | 1.095 Tage | belegt, dass Anfragen bearbeitet wurden |
| ip_hashes | 30 Tage | nur Missbrauchserkennung; der Salt rotiert, ältere Hashes sind ohnehin unbrauchbar |
Jedes Fenster ist ein Standard, keine Empfehlung für jedes Unternehmen. Ein Händler mit 14-tägigem Rückgaberecht kann Zustellversuche auf 30 Tage kürzen; ein B2B-Unternehmen mit neunmonatigen Verkaufszyklen kann Click-IDs auf diese Länge verlängern, wenn die Fenster seiner Werbeplattformen tatsächlich so weit reichen. Ein Fenster über den Standard hinaus zu verlängern ist eine Entscheidung, die ins Verzeichnis der Verarbeitungstätigkeiten gehört; die Änderung selbst wird ins Audit-Log geschrieben.
Geltungsbereich und Vorrang
Die Aufbewahrung wird je Organisation festgelegt und kann für Events und Click-IDs je Site überschrieben werden; Zustellversuche, Audit-Log und Chat-Transkripte gelten organisationsweit. Das wirksame Fenster ist die Site-Überschreibung, falls vorhanden, sonst der Organisationswert, sonst der Standard. Verkürzungen wirken beim nächsten täglichen Lauf; Verlängerungen wirken nur auf noch nicht abgelaufene Datensätze — es gibt keine Wiederauferstehung.
Durchsetzung
- Ein Ablaufjob läuft einmal täglich. Für Events wendet er das wirksame Fenster je Site an und löscht ältere Zeilen; der Event-Speicher ist nach Monaten partitioniert, sodass der Ablauf meist ein Partition-Drop statt Zeilenlöschungen ist.
- Nach dem Click-ID-Fenster werden Click-IDs und Vendor-IDs aus ansonsten behaltenen Events entfernt, sodass eine dreizehnmonatige Eventhistorie nicht dreizehn Monate Attributionskennungen trägt.
- Zustellversuche, Audit-Log und Chat-Transkripte werden je Organisation mit deren Fenster gelöscht; Dedup-Schlüssel, Nonces und Attributions-Touchpoints laufen nach eigenen Zeitplänen ab.
- Jeder Lauf protokolliert die Zahl entfernter Zeilen je Datenart; das Worker-Log ist der Nachweis, dass der Ablauf gelaufen ist.
- Backups folgen denselben Fenstern plus Backup-Zyklus; die Sicherheitsseite nennt die Backup-Aufbewahrung, damit die Gesamtlebensdauer bekannt ist.
Was Aufbewahrung nicht ist
- Keine Anonymisierung. Aus Events berechnete Aggregate (tägliche Zählwerte, Health Scores, Funnel-Raten) werden über das Eventfenster hinaus behalten, weil sie keine personenbezogenen Daten enthalten; die Richtlinienseite benennt sie ausdrücklich.
- Keine Anbieter-Aufbewahrung. Was Meta oder Google behalten, folgt deren Bedingungen; die Subprozessoren-Seite verlinkt die Aufbewahrungsdokumentation jedes Anbieters.
- Kein Ersatz für Consent. Kurze Aufbewahrung von Daten, die ohne Rechtsgrundlage erhoben wurden, macht die Erhebung nicht rechtmäßig.
Einrichtung
- Öffne Datenschutz → Aufbewahrung und prüfe die Standards gegen deine tatsächlichen Reporting- und Attributionsbedürfnisse.
- Kürze alles, was du nicht begründen kannst; verlängere nur mit schriftlichem Grund.
- Bestätige die Site-Überschreibungen für Sites in anderen Rechtsräumen oder mit anderen Geschäftsmodellen.
- Prüfe die Statusseite nach dem ersten geplanten Lauf; die Jobeinträge sind dein Nachweis.