Ein Chat-Widget, das durch ein externes Support-System betrieben wird, baut beim Initialisieren eine Netzwerkverbindung zu diesem System auf. Diese Verbindung übermittelt die IP-Adresse des Besuchers, einen Browser-Fingerprint und möglicherweise Nachrichteninhalte an eine Drittanbieter-Infrastruktur. Unter der DSGVO und ähnlichen Regelungen ist das Laden eines solchen Widgets ohne ausdrückliche Zustimmung nicht zulässig — auch wenn das Widget rein funktionaler Natur ist.
Die einfache Lösung — "einfach trotzdem laden und in der Datenschutzerklärung erwähnen" — reicht nicht aus. Das Laden selbst stellt eine Datenübertragung dar, bevor eine Einwilligung erteilt wurde. Unser Ansatz besteht darin, das Chat-Widget-JavaScript vollständig von der Seite fernzuhalten, bis der Besucher ausdrücklich der entsprechenden Cookie-Kategorie zugestimmt hat. Bis dahin wird kein JavaScript heruntergeladen, keine Verbindung aufgebaut und keine Daten verlassen den Browser.
Das ist nicht nur ein Compliance-Haken. Es ist auch ein Leistungsvorteil: Das Chat-Widget und seine Abhängigkeiten sind nicht Teil des initialen Seitenbundles, sodass die First-Load-Performance durch das Chat-Widget unberührt bleibt.
Der Consent-Manager verfolgt, welche Cookie-Kategorien der Besucher akzeptiert hat. Wenn der Besucher Analytics- oder funktionale Cookies akzeptiert, aktualisiert der Consent-Manager seinen Zustand, und eine dafür zuständige Loader-Komponente reagiert auf diese Änderung, indem sie das Chat-Widget dynamisch nachlädt — ausschließlich im Browser, nie beim serverseitigen Rendering.
Dieses Nachladen bedeutet, dass das Widget nie auf dem Server ausgeführt wird und im Browser nur dann initialisiert wird, wenn es explizit ausgelöst wird — in diesem Fall durch die Änderung des Consent-Zustands. Bis dahin ist kein Chat-bezogenes JavaScript auf der Seite vorhanden. Sobald der Ladevorgang abgeschlossen ist, initialisiert sich das Chat-Widget und steht dem Besucher zur Verfügung.
Der Theme-Zustand (Hell-/Dunkel-Modus-Einstellung) wird unabhängig vom Cookie-Consent verwaltet. Die Hell-/Dunkel-Modus-Einstellung ist eine rein lokale Einstellung ohne externe Datenübertragung und erfordert daher keine Einwilligung. Beide Mechanismen werden lokal im Browser gespeichert, sind aber in Logik und Timing vollständig voneinander unabhängig.
Nicht jede Support-Anfrage benötigt eine Live-Chat-Antwort. Für Anfragen, die von einem nachverfolgten Workflow profitieren — Fehlermeldungen, Kontoprobleme, Fragen zur Abrechnung — ist das Ticket-Formular der richtige Kanal. Es ist immer verfügbar, unabhängig vom Consent-Status, und erfordert kein Drittanbieter-JavaScript.
Ticket-Einreichungen akzeptieren bis zu fünf Dateianhänge pro Einreichung. Unterstützte Dateitypen sind Bilder (JPEG, PNG, GIF, WebP), PDF, TXT, DOC und DOCX, mit einer Dateigrößenbegrenzung von 10 MB. Das Formular fragt nach E-Mail-Adresse, Kategorie, Priorität, Betreff und Beschreibung. Jede Ticket-Einreichung ist durch hCaptcha geschützt, um Spam zu verhindern.
Nach dem Absenden wird ein Ticket an das zuständige Support-Team weitergeleitet, löst die entsprechenden Benachrichtigungen aus, und der Lösungsstatus wird bis zum Abschluss der Anfrage nachverfolgt. Da diese Routing-Logik außerhalb der Homepage-Anwendung selbst liegt, kann sie angepasst werden, ohne dass eine Codeänderung oder ein erneutes Deployment nötig wäre.
Nachrichten und Ticket-Einreichungen von der Homepage werden über authentifizierte Server-zu-Server-Anfragen sicher an unser Support-System weitergeleitet — Besucher kommunizieren nie direkt mit diesem System, und Anfragen, die nicht korrekt authentifiziert sind, werden abgelehnt, bevor irgendein Support-Workflow ausgeführt wird. Das verhindert, dass Unbefugte Nachrichten in unsere Support-Kanäle einschleusen, selbst wenn sie die zugrunde liegenden Endpunkte entdecken sollten.
Sowohl die Chat- als auch die Ticket-Route sind zusätzlich gegen Missbrauch geschützt: Anfragen werden pro Besucher rate-limitiert, mit engeren Limits für Ticket-Einreichungen, da diese seltener vorkommen. Besucher, die das Limit überschreiten, sehen lediglich eine vorübergehende "Bitte etwas langsamer"-Antwort, anstatt das System überlasten zu können.
Chat und Tickets sind keine konkurrierenden Kanäle — sie bedienen unterschiedliche Interaktionsmuster. Chat ist synchron und konversationell: er ist die richtige Wahl für schnelle Fragen, Produktberatung und alles, wo gegenseitige Klärung hilft. Das Ticket-Formular ist asynchron und strukturiert: es erstellt einen nachverfolgbaren Datensatz, erlaubt Dateianhänge und fließt in einen Support-Workflow ein, an dem mehrere Teammitglieder beteiligt sein können.
Aus der Perspektive des Besuchers sind beide Kanäle von derselben Seite aus erreichbar. Chat erscheint, sobald die Einwilligung erteilt wird; das Ticket-Formular ist immer vorhanden. Die Designabsicht ist, dass ein Besucher, der keine Cookies akzeptieren möchte, trotzdem einen voll funktionsfähigen Support-Weg zur Verfügung hat — ohne eingeschränkte Erfahrung. Wir nutzen den Consent-Status nicht als Hebel, um Besucher zur Cookie-Akzeptanz zu drängen: Der Ticket-Weg funktioniert ohne sie genauso gut.
Artikel teilen:
