Live-Chat-Einwilligung widerrufen: Was muss danach im Shop passieren?

Jemand widerruft die Live-Chat-Einwilligung in deinem Shop. Der Einstellungsdialog zeigt den neuen Status – aber das geöffnete Widget nimmt weiter Eingaben an. Oder es verschwindet, während im Hintergrund noch Anfragen laufen. Beides lässt sich nur klären, wenn du den Widerruf als Zustandswechsel testest: Was startet künftig nicht mehr, was geschieht auf der geöffneten Seite und was passiert mit einer laufenden Unterhaltung?

Was der Widerruf ändern soll – und was nicht automatisch folgt

Hier geht es um den Fall, dass dein Shop das Widget über einen widerrufbaren Consent-Zweck lädt. Wie du den Einbau und den Zustand vor einer Einwilligung prüfst, steht im Artikel Live-Chat-Cookie-Einwilligung und Widget im Shop prüfen. Für den Widerruf musst du vier Bereiche auseinanderhalten:

Bereich	Prüffrage	Entscheidung
Künftiger Start	Kann das Chat-Skript auf einer weiteren Seite starten?	Der widerrufene Zweck darf den Ladepfad nicht mehr freigeben.
Bereits geladener Code	Sendet oder speichert das Widget nach dem Widerruf weiter?	Laufende Verarbeitung prüfen und für den widerrufenen Zweck beenden; bloßes Ausblenden genügt nicht.
Offene Unterhaltung	Kann die Person noch schreiben, und weiß sie, ob ihre Nachricht ankam?	Unterbrechung und Kontaktalternative verständlich anzeigen.
Gespeicherter Verlauf	Was geschieht mit bereits übermittelten Nachrichten?	Zweck, Rechtsgrundlage und Aufbewahrung gesondert beurteilen.

Entscheidungsregel: Trenne den künftigen Start des Widgets, die laufende Kommunikation und bereits gespeicherte Chat-Daten. Das Sperren eines Skriptstarts macht bereits ausgeführten Code nicht rückgängig. Der Widerruf bedeutet umgekehrt nicht automatisch, dass sämtliche schon übermittelten Nachrichten sofort zu löschen sind. Prüfe die Speicherdauer von Chatverläufen gesondert mit deiner Datenschutzverantwortlichen oder deinem Datenschutzverantwortlichen.

Den Widerruf im Consent-Tool als Zustandswechsel abbilden

Bitte deine Web-Entwicklung, den Weg von der Consent-Einstellung bis zum Skriptstart zu skizzieren. Das Live-Chat-Widget von askVela wird beispielsweise über ein Skript-Snippet eingebaut. Daraus folgt weder eine Anbindung an dein Consent-Tool noch eine bestimmte Reaktion auf den Widerruf: Entscheidend ist die Steuerung in deinem Shop.

1. Zweck und Zugang festhalten: Welcher Consent-Zweck steuert das Widget? Von welchen Shop-Seiten lassen sich die Einstellungen erneut öffnen? Notiere Zweckbezeichnung und Einstiegspunkt, damit du denselben Weg später reproduzierst.
2. Statuswechsel nachweisen: Widerrufe den Zweck und prüfe den gespeicherten Status. Das Schließen des Einstellungsdialogs ist kein Nachweis. Lass dir außerdem zeigen, ob und wie das Consent-Tool die Änderung an den Shop meldet.
3. Alle Startpunkte suchen: Sperrt das Consent-Tool das Skript selbst, oder prüft der Shop den Status vor dem Einfügen? Suche auch nach Startpunkten im Theme, Tag-Manager und nachladendem Code. Jeder Startpunkt muss den aktuellen Status berücksichtigen.
4. Bereits laufenden Code zuordnen: Halte fest, welche Logik bei einem Widerruf auf einer geöffneten Seite reagiert. Die Sperre beim nächsten Seitenaufruf beantwortet diese Frage nicht.

Als Arbeitsauftrag genügt ein konkreter Satz: „Zeig mir den gespeicherten Status, alle Stellen, die den Chat laden, und die Reaktion auf einen Widerruf, während die Seite geöffnet bleibt.“

Was mit einem bereits geladenen Chat-Widget passieren muss

Teste Anzeige und Hintergrundaktivität getrennt. Ein ausgeblendetes Fenster kann weiter Anfragen auslösen; eine noch sichtbare Oberfläche kann bereits keine Verbindung mehr haben. Welche Abschaltmöglichkeit besteht, hängt vom eingesetzten Widget und dessen Einbau ab.

Ein Seitenwechsel ist nur ein tauglicher Fallback, wenn das Widget auf der Zielseite ausbleibt. Veranlasse ihn nicht unbemerkt mitten in einer Eingabe. Wenn weder das Beenden im laufenden Dokument noch ein kontrollierter Wechsel verlässlich funktioniert, dokumentiere die Grenze und kläre mit Entwicklung und Datenschutzverantwortlichen einen anderen Einbau oder Ablauf. Eine CSS-Regel, die lediglich das Widget versteckt, löst das Problem nicht.

Widerruf während einer offenen Unterhaltung: einen klaren Ablauf festlegen

Hier sind zwei Nachrichtenstände wichtig. Ein noch nicht abgeschickter Entwurf darf nicht als zugestellt erscheinen. Für bereits gesendete Nachrichten muss der Support erkennen können, ob das Anliegen eingegangen ist; über ihre weitere Speicherung entscheidet die gesondert geprüfte Regel. Teste beide Zustände, statt aus der sichtbaren Chat-Oberfläche auf die Zustellung zu schließen.

Lege mit Support und Entwicklung fest, wo eine Unterbrechungsmeldung erscheint. Entfernt die Shop-Logik das Widget sofort, kann eine Meldung im Widget zu spät kommen. Eine vom Shop angezeigte Meldung außerhalb des Widgets ist dann eine Option. Sie darf nicht davon abhängen, dass die widerrufene Chat-Verarbeitung weiterläuft.

Verwende „ist jetzt beendet“ erst, wenn der Test das bestätigt. Andernfalls darf die Meldung keinen abgeschlossenen technischen Vorgang behaupten; der Ablauf muss vor der Freigabe geklärt werden. Prüfe den Platzhalter ebenfalls: Ist das Kontaktformular ohne Chat erreichbar, und kann die Person dort ihr Anliegen ohne Bezug auf einen möglicherweise verlorenen Entwurf schildern?

Internes Entscheidungsschema: Chat noch nicht geöffnet? Künftigen Start sperren. Widget geöffnet, keine Nachricht gesendet? Weitere Übertragung verhindern, Entwurf nicht als zugestellt darstellen und Kontaktweg anbieten. Nachricht bereits gesendet? Zustellung anhand des Testfalls prüfen, weitere Kommunikation gemäß dem festgelegten Ablauf unterbrechen und gespeicherte Daten separat beurteilen. Unterstelle keine stillschweigende Fortsetzung des Chats.

Den Widerruf selbst testen: vom Klick bis zum Neuladen

Nutze eine Testumgebung oder einen Test-Browser, in dem du den Consent-Status für jeden Durchlauf auf denselben Ausgangswert setzen kannst. Öffne die Entwicklertools vor dem Laden der Testseite. Halte im Netzwerkprotokoll fest, wann Skripte und Anfragen starten; beobachte zusätzlich Verbindungen und Browser-Speicher. Ein Blick erst nach dem Widerruf zeigt nicht, was vorher bereits geladen war.

Spiele drei Ausgangslagen durch: Widget unbenutzt, Widget geöffnet ohne gesendete Nachricht und Nachricht gesendet. Im letzten Fall verwende eine eindeutig erkennbare Testnachricht und gleiche ihren Eingang mit dem Support ab. Prüfe nach jedem Widerruf die noch offene Seite, wechsle dann auf eine weitere Shop-Seite und lade erneut. Erteile dabei keine neue Einwilligung. Für den nächsten Durchlauf stelle den Ausgangsstatus bewusst wieder her.

Die Speicheransicht zeigt vorhandene Einträge, aber nicht automatisch jeden Lesezugriff. Wenn du einen Zugriff damit nicht belegen oder ausschließen kannst, lass die betreffenden Codestellen beziehungsweise eine geeignete technische Protokollierung prüfen. Trage bis dahin „nicht geklärt“ statt „bestanden“ ein.

Fehlerbilder und Freigabe für den Shop-Alltag

• Status widerrufen, Widget bleibt benutzbar: Erreicht das Änderungsereignis die Logik für den laufenden Chat? Prüfe nach der Korrektur erneut Eingabe und Zustellung.
• Widget weg, Anfragen laufen weiter: Wurde nur die Oberfläche entfernt? Prüfe erneut im Netzwerkprotokoll, ob nach dem Widerruf weitere Chat-Vorgänge ausgelöst werden.
• Widget startet auf der nächsten Seite erneut: Prüfe den gespeicherten Status und jeden Skript-Startpunkt, besonders beim neuen Seitenaufbau.
• Mitten im Chat fehlt die Meldung: Wird das Widget vor der Anzeige entfernt? Verlege die Meldung gegebenenfalls in eine Shop-Oberfläche, die ohne Chat funktioniert.

Erteile die Freigabe erst, wenn Consent-Einstellung und beobachtetes Verhalten in allen vorgesehenen Ausgangslagen übereinstimmen. Als Produktkontext kannst du dir die Datenschutz-Funktionen von askVela ansehen. Ob der Widerruf in deinem Shop tatsächlich den Lade- und Sitzungsablauf steuert, zeigt nur der Test deines konkreten Einbaus.