Live-Chat-Einwilligung protokollieren: Vorlage für einen nachvollziehbaren Nachweis

Wenn du eine Live-Chat-Einwilligung protokollieren willst, reicht ein gespeichertes „zugestimmt“ nicht aus. Du musst die Entscheidung dem betroffenen Zweck und der damals angezeigten Oberfläche zuordnen können. Dazu gehören eine auffindbare Textfassung und ein eigener Eintrag für einen späteren Widerruf. Ob dein konkretes Widget überhaupt eine Einwilligung benötigt, ist eine vorgelagerte Frage: Prüfe zuerst dein Live-Chat-Widget und die Cookie-Einwilligung. Die folgende Vorlage hilft dir, eine Entscheidung zu dokumentieren, die dein Shop tatsächlich einholt; sie ersetzt diese Prüfung nicht.

Zuerst klären: Welche Entscheidung soll das Protokoll belegen?

Schreib vor dem Anlegen der Felder einen Satz auf, der die Entscheidung beschreibt: „Die Person entscheidet, ob das Chat-Widget auf Shop-Seiten geladen werden darf.“ Falls dein Setup stattdessen oder zusätzlich eine Entscheidung über das Speichern oder Auslesen von Informationen auf dem Endgerät einholt, benenne diesen Zweck gesondert. Fasse solche Entscheidungen nicht mit Angaben zusammen, die jemand später freiwillig in eine Chat-Nachricht schreibt. Ein Status namens „Chat erlaubt“ wäre dafür zu ungenau.

Das Live-Chat-Widget von askVela lässt sich per Skript-Snippet einbinden. Prüfe in deinem Consent- und Shop-Setup, wie Entscheidungen erfasst und für den Nachweis gespeichert werden.

Welche Angaben gehören in einen nachvollziehbaren Eintrag?

Ein Eintrag sollte erkennen lassen, was entschieden wurde, wann die Handlung stattfand, welcher Text angezeigt wurde und wie du zusammengehörige Entscheidungen findest. Trenne dafür Ereignistyp und Status nach dem Ereignis: „Widerruf“ bezeichnet die Handlung, „widerrufen“ den Status danach.

Angabe	Praktische Festlegung
Ereignis-ID und Zeitpunkt	Vergib für jede Handlung eine eigene Kennung. Speichere den Zeitpunkt mit Zeitzone und lege fest, welche Komponente die Zeit setzt.
Ereignistyp und Status danach	Nutze fest definierte Werte für Zustimmung, Ablehnung und Widerruf. Ein leerer Wert ist keine Ablehnung.
Zweck-ID	Hinterlege eine auffindbare Zweckbeschreibung. Ändere ihre Bedeutung nicht stillschweigend unter derselben Kennung.
Textversion	Verknüpfe die Kennung mit einer archivierten Fassung von Erklärung, Zweck und Schaltflächenbeschriftungen – einschließlich der ausgespielten Sprache.
Widget-Konfiguration	Notiere eine Kennung für Einbindung und Shop-Umgebung, damit ein Testeintrag nicht als Entscheidung im Liveshop erscheint.
Zuordnungsmerkmal	Verwende ein im Consent-Setup vorhandenes, möglichst datensparsames Merkmal. Erfasse nicht allein für den Nachweis zusätzlich Klarname, IP-Adresse oder Chatverlauf.
Erfassungsquelle	Unterscheide etwa Banner und Einstellungsansicht. Eine technische Korrektur darf nicht wie ein Klick der betroffenen Person aussehen.

Vereinbare außerdem mit Technik- und Datenschutzverantwortlichen, wer Protokolle und archivierte Texte lesen darf, wie Änderungen an gespeicherten Fassungen verhindert oder erkennbar gemacht werden und nach welchen Regeln die Daten gelöscht werden. Die Vorlage legt keine allgemeingültige Aufbewahrungsfrist fest.

Vorlage: Einwilligungsprotokoll zum Ausfüllen

Kopiere die Vorlage für jedes Ereignis. Die Felder unter „Kern des Eintrags“ dienen dem hier beschriebenen Abgleich. Bedingte Felder füllst du nur aus, wenn sie zum Ereignis passen; Diagnosefelder erfasst du nur, wenn du sie benötigst. Bewahre die Textkopien getrennt vom Ereignisprotokoll auf, aber verknüpfe beides über eine eindeutige Versionskennung.

Prüfe beim Archivieren nicht nur den Fließtext. Wenn die Einstellungsansicht einen anderen Wortlaut oder andere Schaltflächen als das Banner zeigt, muss erkennbar sein, welche Oberfläche zur gespeicherten Entscheidung gehört. Dasselbe gilt für Sprachfassungen. Eine Versionskennung hilft nicht, wenn hinter ihr später nur noch der zuletzt bearbeitete Text liegt.

So sieht die Ereignisfolge bei Einwilligung und Widerruf aus

Im folgenden fiktiven Beispiel betreffen alle Handlungen denselben Zweck und dasselbe Zuordnungsmerkmal im Liveshop. Die Angaben zeigen nur die Reihenfolge; in einem echten Protokoll trägst du Datum, Uhrzeit und Zeitzone ein. Die genannten Textfassungen sind als lesbare Kopien archiviert.

Reihenfolge	Eigenes Ereignis	Gespeicherter Bezug und Status danach
Zuerst	Ereignis „Zustimmung A“: Die Person stimmt im Banner zu.	Zweck „Widget laden“, Textfassung „Banner DE A“, Konfiguration „Liveshop A“; Status: zugestimmt.
Später	Ereignis „Widerruf B“: Die Person widerruft in der Einstellungsansicht.	Gleiches Zuordnungsmerkmal und gleicher Zweck, Verweis auf „Zustimmung A“, angezeigte Fassung „Einstellungen DE A“; Status: widerrufen.
Nach dem Widerruf	Ereignis „Zustimmung C“: Die Person entscheidet sich erneut dafür.	Neue Ereignis-ID, tatsächlich angezeigte Fassung „Banner DE B“; Status: zugestimmt.

Überschreibe „Zustimmung A“ beim Widerruf nicht: Sonst ist nicht mehr nachvollziehbar, dass zuvor eine Zustimmung vorlag und welcher Text damals angezeigt wurde. Gib den früheren Eintrag aber auch nicht als aktuellen Status aus. Für den aktuellen Stand betrachtest du die Ereignisse zu demselben Zweck und Zuordnungsmerkmal in ihrer zeitlichen Folge.

Entscheidungsregel für Ablehnung: Wenn dein Konzept Ablehnungen protokolliert, speichere die ausdrückliche Ablehnung als eigenes Ereignis mit der tatsächlich sichtbaren Textversion. Ein fehlender Eintrag ist nicht gleichbedeutend mit „abgelehnt“. Wird später erneut gefragt, bekommt die neue Handlung eine neue Ereignis-ID; ein geschlossener Banner oder ein Seitenaufruf wird dadurch nicht zur Zustimmung. Kann ein Widerruf keiner früheren Zustimmung zuverlässig zugeordnet werden, erfinde keinen Bezug: Dokumentiere die Zuordnungslücke und prüfe, wie dein Setup den aktuellen Status für den betroffenen Kontext behandelt.

Wie prüfst du, ob Textversion und Protokoll zusammenpassen?

Führe den Abgleich bei der Einrichtung und nach Änderungen an Text, Sprache, Zweck oder Einbindung durch. Kennzeichne Testereignisse und halte sie von echten Entscheidungen unterscheidbar.

1. Testkontext vorbereiten: Nutze eine kontrollierte Shop-Umgebung ohne bereits gespeicherte Entscheidung. Notiere Sprache, Zweck-ID und Konfigurationskennung. Sonst kann eine alte Auswahl die Oberfläche verdecken.
2. Sichtbare Fassung festhalten: Lies vor dem Klick Erklärung, Zweck und Beschriftungen der Entscheidungsflächen. Vergleiche die Ansicht mit der archivierten Fassung. Prüfe Banner und Einstellungsansicht jeweils dort, wo eine Handlung möglich ist.
3. Zustimmung abgleichen: Stimme im Testkontext zu und suche den Eintrag über das Test-Zuordnungsmerkmal. Stimmen Ereignistyp, Status, Zeitpunkt samt Zeitzone, Quelle, Zweck, Textversion und Konfiguration? Öffne die archivierte Fassung über den gespeicherten Verweis.
4. Ablehnung getrennt prüfen: Stelle einen neuen Ausgangszustand her, lehne ausdrücklich ab und kontrolliere den vorgesehenen Status. Falls dein Konzept die Ablehnung protokollieren soll, ist ein fehlender Eintrag ein Fehler – kein Ablehnungsnachweis.
5. Widerruf prüfen: Stimme in einem weiteren Testkontext zu und widerrufe über den vorgesehenen Weg. Suche beide Einträge. Der Widerruf muss als neue Handlung mit passender Quelle sichtbar sein; prüfe den Bezug zur früheren Zustimmung.
6. Änderungstest durchführen: Ändere testweise eine freigegebene Formulierung oder relevante Konfiguration. Eine neue Entscheidung muss auf die passende neue Fassung zeigen. Öffne anschließend auch die alte Fassung über einen früheren Eintrag.

Entscheidungsregel bei einem Protokollfehler: Erscheint eine Handlung auf der Oberfläche erfolgreich, aber es gibt keinen zugehörigen Eintrag, behaupte keinen erfolgreichen Nachweis. Halte Testkontext, sichtbare Reaktion und Fehlermeldung fest. Prüfe den Weg von der Consent-Oberfläche bis zum Protokoll und wiederhole den Test nach der Korrektur. Lege mit der Technikverantwortung ausdrücklich fest und teste, was dein Shop bei einem Speicherfehler mit der angeforderten Widget-Aktivierung macht. Ein fehlender Eintrag darf nicht stillschweigend als Zustimmung interpretiert werden.

Was das Protokoll nicht automatisch beweist

Ein Ereignisverlauf zeigt, was dein Setup gespeichert und welcher Textfassung es die Handlung zugeordnet hat. Er beweist für sich genommen weder, dass ein Widget vor einer erforderlichen Entscheidung inaktiv war, noch, dass ein Widerruf die Aktivierung technisch beendet hat.

Zum Abschluss sollte eine verantwortliche Person von einem Testeintrag aus die damals angezeigte Fassung öffnen, die Handlung benennen und einen späteren Widerruf davon unterscheiden können. Scheitert einer dieser Schritte, korrigiere zuerst Textarchiv, Versionsvergabe oder Ereignisverknüpfung – bevor du das Protokoll als Nachweis heranziehst.