Euer CRM-Setup hat ein Double-Opt-in. Der Abmeldelink sitzt in jeder Mail. Das Legal-Team hat das Setup abgenommen. Dann meldet sich ein Nutzer bei eurem Support und fragt, wann genau er dem Erhalt von Push-Notifications zugestimmt hat. Und niemand kann es nachweisen. Nicht weil der Prozess fehlt, sondern weil das CRM-Tool den Consent als aktuellen Status speichert, nicht als nachvollziehbares Ereignis.
Das ist kein Randfall. In den meisten Instanzen, die wir prüfen, sehen wir dasselbe Muster: Das Setup wirkt konform, die technische Umsetzung ist es nicht.
Das grüne Häkchen, das nichts beweist
Double-Opt-in ist der Goldstandard im deutschen E-Mail-Marketing. Zurecht. Aber Consent-Management hört nicht beim Opt-in auf. Die DSGVO verlangt in Art. 7, dass ihr nachweisen könnt, dass eine Einwilligung erteilt wurde, wann sie erteilt wurde, wofür sie galt und über welchen Weg sie reinkam.
In Klaviyo wird der Consent-Status als Feld am Profil gespeichert. Bei jedem Status-Wechsel wird das Feld aktualisiert, der vorherige Wert verschwindet. Wer gestern opted-in war und heute opted-out ist, hat keinen dokumentierten Übergang. Braze speichert Subscription States (opted-in, subscribed, unsubscribed), aber ohne nativen Audit-Trail. Brevo führt ein Event-Log, das die letzten Änderungen zeigt, aber ältere Einträge werden nach einer Weile schwer auffindbar, je nach Konfiguration.
Das Problem: Bei einer Anfrage durch eine Aufsichtsbehörde oder einem Auskunftsersuchen nach Art. 15 müsst ihr den Nachweis erbringen. Ein aktueller Status reicht nicht. Ihr braucht den Zeitpunkt, den Kanal, die Quelle und den Umfang der Einwilligung.
Fünf technische Consent-Fehler, die wir ständig sehen
1. Consent-Timestamp fehlt oder wird überschrieben. Das offensichtlichste Problem. Viele Teams verlassen sich auf das Feld “subscribed: true” und haben keinen separaten Timestamp für die initiale Einwilligung. Bei einem Profilupdate wird der Status aktualisiert, der Timestamp zeigt das letzte Update, nicht die ursprüngliche Einwilligung. Lösung: Ein dediziertes Custom Property für den initialen Consent-Zeitpunkt, das bei späteren Änderungen nicht überschrieben wird.
2. Channel-Consent wird zusammengeworfen. Ein Opt-in für den Newsletter wird als Opt-in für alles behandelt: E-Mail, SMS, Push, In-App. Das passiert, wenn nur eine Subscription Group für alle Kanäle existiert. In Brevo ist das Default-Verhalten so konfiguriert, dass ein Formular-Subscribed-Status alle Kanäle einschließt, sofern die Gruppen nicht manuell getrennt werden. Die DSGVO verlangt Granularität: Wer dem Newsletter zustimmt, stimmt nicht automatisch Push-Benachrichtigungen zu.
3. Consent-Quelle wird nicht erfasst.
Woher kam das Opt-in? Website-Footer, Checkout-Checkbox, App-Onboarding, Gewinnspiel-Landing-Page, manueller Import aus dem alten System? Wir sehen regelmäßig Instanzen, in denen ein Custom Property wie consent_source existiert, aber bei 40 bis 60% der Kontakte leer ist. Besonders bei Migrationen aus Legacy-Systemen fehlt die Quelle fast immer. Ohne Quelle könnt ihr bei einer Prüfung nicht belegen, wo die Einwilligung eingeholt wurde.
4. Suppression Lists werden durch Imports überschrieben. Ein Nutzer meldet sich ab. Sechs Wochen später importiert jemand eine aktualisierte Kontaktliste per CSV. Der abgemeldete Nutzer ist in der Liste, Status: subscribed. Klaviyo erlaubt das, wenn der Import-Parameter entsprechend gesetzt ist. Braze überschreibt den Subscription-Status, wenn das Feld im API-Payload mitkommt. Ergebnis: Der Nutzer erhält wieder Mails, obwohl er sich abgemeldet hat. Das ist kein Graubereich, das ist ein Verstoß.
5. Preference Center ohne Audit-Trail. Euer Preference Center lässt Nutzer ihre Kanäle verwalten. Aber was es im Hintergrund schreibt, ist nur der aktuelle Status. Kein Log darüber, was der Nutzer wann geändert hat. Und es deckt typischerweise nicht alle Kanäle ab: Push-Consent wird über das Betriebssystem gesteuert und lebt außerhalb des Preference Centers. In-App-Messages haben in Braze und Klaviyo keinen eigenen Consent-Layer. Das Preference Center simuliert Kontrolle, liefert aber keinen Nachweis.
Was eine Aufsichtsbehörde sehen will
Bei einem Auskunftsersuchen oder einer Prüfung muss klar dokumentiert sein: Wann hat dieser Kontakt eingewilligt? Für welchen Kanal? Über welchen Touchpoint? Wie sah die Einwilligungserklärung zu diesem Zeitpunkt aus? Und gibt es eine lückenlose Historie aller Änderungen?
Die meisten CRM-Instanzen können davon bestenfalls den aktuellen Status liefern. Keinen Zeitpunkt, keine Quelle, keine Historie.
Der Grund ist selten böser Wille. Die Tools machen es einfach nicht leicht. Consent-Tracking auf dem Niveau, das die DSGVO verlangt, erfordert bewusste Konfigurationsarbeit: Custom Properties für Timestamps und Quellen, separate Subscription Groups pro Kanal, Import-Workflows mit Suppression-Check, Event-Logging für jede Status-Änderung. Nichts davon ist Standard.
Was ihr daraus mitnehmt
Sechs Prüfpunkte für euer nächstes Consent-Audit:
Consent-Timestamp vorhanden? Nicht das Profil-Update-Datum. Ein eigenes Feld, das den Zeitpunkt der initialen Einwilligung speichert und bei späteren Änderungen nicht überschrieben wird.
Kanal-granulare Subscription Groups? Separate Gruppen für E-Mail, SMS, Push und weitere Kanäle. Kein Sammelbecken, in dem ein Opt-in alles abdeckt.
Consent-Quelle je Kontakt? Ein Feld, das dokumentiert, über welchen Touchpoint die Einwilligung kam. Bei Importen: die Quelle aus dem Ursprungssystem mitführen.
Import-Prozess mit Suppression-Check? Jeder Import muss gegen die aktuelle Suppression List geprüft werden, bevor er Status-Felder überschreibt. Kein CSV-Upload ohne Schutzmechanismus.
Audit-Trail für Status-Änderungen? Jede Änderung am Consent-Status muss als Event geloggt werden, nicht nur als Feld-Update. Braze Custom Events, Klaviyo Metrics oder ein externes Log.
Push-Consent separat dokumentiert? Push-Consent lebt im Betriebssystem. Euer CRM muss trotzdem dokumentieren, wann und worüber der Nutzer zugestimmt hat.
Der blinde Fleck bei Consent-Management ist nicht das fehlende Opt-in. Der blinde Fleck ist die Annahme, dass ein Double-Opt-in und ein Abmeldelink ausreichen, um nachweisbar konform zu sein. Die Lücke liegt in der technischen Konfiguration: wie euer CRM-Tool Consent speichert, historisiert und bei Importen schützt. Das sieht euer Legal-Team nicht, weil es das Dashboard prüft, nicht die Datenstruktur.
