Hotjar Heatmap und Session Recording Cookie-Einwilligung: Integrationsleitfaden und Playbook 2026 für Publisher
Hotjar nimmt einen einzigartigen Platz im Tooling-Stack ein. Es ist keine Web-Analytics-Plattform wie Google Analytics, keine Produkt-Analytics-Plattform wie Amplitude oder Mixpanel und auch kein Tag-Manager. Es ist ein User-Experience-Forschungswerkzeug, das ausdrücklich dazu dient, aufzuzeichnen, was einzelne Nutzer auf einer Seite tun — wo sie die Maus bewegen, was sie anklicken, wo sie scrollen, wo sie zögern und im Fall der Sitzungsaufzeichnung genau das, was sie getippt und auf dem Bildschirm gerendert gesehen haben. Diese Granularität ist das Produkt. Sie ist auch der Grund, warum Regulatoren die Sitzungswiedergabe als eine der risikoreichsten Kategorien der Verhaltensverarbeitung eingestuft haben und warum eine nachlässige Hotjar-Implementierung einer der einfachsten Wege für eine ansonsten konforme Website ist, aus der Compliance herauszufallen. Die CNIL, der Garante und die EDPB haben alle Leitlinien veröffentlicht, die sich speziell gegen das Verhalten bei der Sitzungswiedergabe richten, und die EDPB-Cookie-Banner-Task-Force 2026 behandelt dies als Prioritätskategorie. Die gute Nachricht ist, dass Hotjar eines der technisch besser gestalteten Werkzeuge in dieser Kategorie für Consent-first-Deployments ist — vorausgesetzt, der Publisher verwendet tatsächlich die vorhandenen Steuerungsmöglichkeiten.
Warum Hotjar eine ausdrückliche Einwilligung erfordert
Hotjars Erfassungsprofil ist das, was Einwilligungspflichten in allen relevanten Rechtsrahmen auslöst. Bei einer Standardinitialisierung schreibt das Hotjar-Tracking-Skript innerhalb von Millisekunden nach dem Seitenaufruf mindestens drei Erstanbieter-Cookies — _hjSessionUser_{siteId}, _hjSession_{siteId} und eine Reihe von Unterdrückungs- und Eingangsquellen-Cookies — in den Browser. Das Skript beginnt dann, einen kontinuierlichen Datenstrom aus Cursor-Koordinaten, Klick-Koordinaten, Scroll-Position, Viewport-Größe und, wenn die Sitzungsaufzeichnung aktiviert ist, dem vollständig gerenderten DOM im Vergleich zu einem Ausgangszustand zu streamen.
Gemäß Artikel 5 Absatz 3 der ePrivacy-Richtlinie ist jedes dieser Cookies ein Speicher- und Zugriffsvorgang, der im EWR, im Vereinigten Königreich, in der Schweiz und in jeder Jurisdiktion, die denselben Standard übernommen hat, eine vorherige, freiwillige, spezifische, informierte und eindeutige Einwilligung erfordert. Unter der DSGVO stellt der Verhaltensdatenstrom eine Verarbeitung personenbezogener Daten dar, da die Kombination aus Cursor-Spur, IP-Adresse, Geräte-Fingerabdruck und Sitzungskennung ausreicht, um eine Person zu identifizieren. Unter dem CCPA und dem CPRA gilt dieselbe Erhebung als Verkauf oder Weitergabe, es sei denn, der Publisher hat den entsprechenden Dienstleister-Vertrag mit Hotjar — den Hotjar über sein CCPA-konformes DPA anbietet, der jedoch erst dann wirksam wird, wenn die Integration korrekt konfiguriert ist. Gemäß der EDPB-Leitlinie zur Sitzungswiedergabe liegt die Messlatte noch höher: Die Wiedergabe muss an einen spezifischen, legitimen UX-Forschungszweck gebunden sein, die Aufbewahrungsfrist muss auf das notwendige Minimum beschränkt sein, und die betroffene Person muss nicht nur darüber informiert werden, dass Aufzeichnungen existieren, sondern auch darüber, dass ihre eigene Sitzung von einem Analysten wiedergegeben werden kann.
Was Hotjar vor der Einwilligung erfasst — und was unterdrückt werden muss
Der häufigste Implementierungsfehler ist derjenige, der mit dem eigenen Schnellstart von Hotjar geliefert wird: das Tracking-Skript direkt in den <head> der Seite einzufügen. Das funktioniert, lädt Hotjar jedoch, bevor das Cookie-Banner überhaupt gerendert wurde, was bedeutet, dass Cookies gesetzt werden und die Verhaltensaufzeichnung beim allerersten Seitenaufruf beginnt — unabhängig davon, was der Nutzer später entscheidet. Jeder EU-Regulator, der über dieses Muster geurteilt hat, hat gleich entschieden: Vor der Einwilligung gesetzte Cookies sind rechtswidrig, und der Publisher haftet dafür.
Eine konforme Integration muss daher verhindern, dass das Hotjar-Skript überhaupt geladen wird, bis die entsprechende Einwilligungskategorie erteilt wurde. Der sauberste Weg, dies zu erreichen, besteht darin, das Hotjar-Snippet in ein einwilligungsgesteuertes <script>-Tag zu verpacken, das der CMP erst nach der Zustimmung des Nutzers zur Analyse- oder Produktforschungskategorie injiziert. Wird das Skript über einen Tag-Manager geladen, besteht die entsprechende Maßnahme darin, den Auslöser auf ein Einwilligungs-Erteilt-Ereignis anstatt auf All Pages einzustellen. Hotjars eigene Dokumentation empfiehlt dieses Muster mittlerweile ausdrücklich, und die Plattform stellt eine hj('consent', 'grant')-API für Fälle bereit, in denen das Skript vorhanden sein muss, aber bis zur Registrierung der Einwilligung inaktiv bleiben soll.
Von Hotjar geschriebene Cookies und Speicher
Hotjar Tracking Code 6.x schreibt die folgenden Kennungen, die alle nicht wesentlich sind und eine Einwilligung erfordern: _hjSessionUser_{siteId} mit einer Ablaufzeit von 365 Tagen, das die Nutzerkennung enthält, _hjSession_{siteId} mit einer Ablaufzeit von 30 Minuten, das die Sitzungskennung enthält, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress und eine Reihe von Kampagnen-Attributions-Cookies, wenn Umfragen oder Feedback-Widgets aktiv sind. Die Sitzungsaufzeichnungen selbst werden auf Hotjars Servern gespeichert und sind an die Sitzungskennung geknüpft — das Widerrufen der Einwilligung muss daher auch über die Hotjar-API oder den produktinternen Nutzer-Löschprozess eine Löschanfrage signalisieren.
Zuordnung von Hotjar zu Einwilligungsrahmen
Hotjar integriert sich nicht nativ in IAB TCF oder die IAB Global Privacy Platform. Es ist kein Ad-Tech-Anbieter und war nie dazu gedacht, einer zu sein. Es integriert sich jedoch über das Signal analytics_storage in den Google Consent Mode v2 und stellt seine eigene native Einwilligungs-API bereit, an die jeder CMP angebunden werden kann. Das Muster, das einer Regulatorenprüfung standhält, behandelt jede Hotjar-Fähigkeit als separates Einwilligungsgate.
- Heatmaps und Klickmaps sind an den Analyse- oder Produktforschungszweck gebunden. In TCF-Begriffen ist dies am häufigsten Zweck 8 (Messung der Content-Performance) kombiniert mit Zweck 1 (Informationen speichern und/oder abrufen). Für den Consent Mode ist dies analytics_storage.
- Sitzungsaufzeichnung sollte hinter einem strengeren, separaten Signal liegen. Die Aufzeichnung erfasst das gerenderte DOM und alle nicht maskierten Felder, und ein explizites Opt-in auf Präferenzebene — keine pauschale Analyse-Einwilligung — ist die verteidigbare Haltung gemäß der EDPB-Leitlinie zur Sitzungswiedergabe.
- Umfragen und Feedback-Widgets können unter demselben Einwilligungsgate wie die Sitzungsaufzeichnung betrieben werden, wenn sie Freitext-Eingaben erfassen, oder unter dem Analyse-Gate, wenn sie nur Bewertungsdaten erfassen.
- Funnels und Conversion-Tracking sind an das Analyse-Gate gebunden; wird eine Nutzerkennung an ein CRM oder eine Werbeplattform weitergegeben, gilt auch das Marketing-Gate.
Das Integrationsmuster, das funktioniert
Die Referenz-Implementierung besteht aus vier Teilen: einem CMP, der ein Echtzeit-Einwilligungsänderungsereignis bereitstellt, einem verzögerten Skript-Loader, der das Hotjar-Snippet nur nach dem Auslösen der Analyse-Einwilligung injiziert, einer Sitzungsaufzeichnungs-Unterdrückungsschicht, die die Aufzeichnung standardmäßig auf „Aus“ setzt, bis ein separates Gate geöffnet wird, und einer Eingabe-Maskierungs-Konfiguration, die jedes Feld, das ein Regulator als sensibel einstufen würde, auch bei erteilter Einwilligung strikt unterdrückt. Der vierte Punkt wird häufig übersehen: Eingabe-Maskierung ist kein Ersatz für Einwilligung, aber ein Ersatz für eine Katastrophe, wenn Einwilligung für legitime Forschung erteilt wurde und ein Nutzer zufällig sensible Daten in ein Freitext-Feld einfügt.
Web-Implementierung
Im Web ist das sauberste Muster, das Einwilligungsänderungsereignis des CMP zu abonnieren und das Hotjar-Snippet dann bedingt zu injizieren, wenn der Analyse-Zweck von false auf true wechselt. Verwenden Sie document.createElement('script'), um den Tracking-Code mit gesetztem async-Attribut zu injizieren, und fügen Sie einen onload-Handler hinzu, der hj('identify', userId, properties) nur aufruft, wenn eine serverseitig validierte Nutzerkennung vorhanden ist. Wenn die Einwilligung widerrufen wird, rufen Sie hj('consent', 'revoke') auf, lassen Sie alle _hj-Cookies über document.cookie ablaufen und senden Sie über die Hotjar Data API eine Löschanfrage für die früheren Sitzungsaufzeichnungen des Nutzers. Initialisieren Sie Hotjar nicht lazy im selben Render-Pass wie das Banner — das Skript muss auf eine explizite Erteilung warten, und die Erteilung muss mit einem Zeitstempel und einem Einwilligungs-String aufgezeichnet werden, bevor das Skript jemals ausgeführt wird.
Eingabe-Maskierung und Unterdrückung sensibler Daten
Hotjars Sitzungsrekorder wird mit drei Maskierungsmodi geliefert: Suppress mode, der Standard für Passwortfelder und alle Elemente, die mit dem Attribut data-hj-suppress versehen sind; Whitelist mode, bei dem nur explizit opt-in-geschaltete Eingaben aufgezeichnet werden; und Mask mode, bei dem Tastenanschläge als Sternchen aufgezeichnet werden. Gemäß den Sonderkategorieregeln der DSGVO und der CCPA-Definition sensibler personenbezogener Daten muss jedes Feld, das Gesundheitsinformationen, Finanzdaten, staatliche Kennungen, biometrische Daten, genaue Geolokalisation oder Inhalte privater Kommunikation erfassen könnte, Suppress mode verwenden, unabhängig vom Einwilligungsstatus des Nutzers. Das Setzen von data-hj-suppress auf Formularebene statt auf Feldebene ist das sicherste Muster — es unterdrückt das gesamte Formular, auch wenn ein Entwickler später ein neues Feld hinzufügt, das er vergisst, individuell zu markieren.
Single-Page-Applikationen und Routenwechsel
Bei SPAs (React, Vue, Angular, Svelte) bindet das Hotjar-Snippet standardmäßig nur an das initiale Laden der Seite. Um virtuelle Seitenübergänge zu verfolgen, muss der Bootstrap bei jedem Routenwechsel hj('stateChange', newPath) aufrufen. Dieser Aufruf respektiert den Einwilligungsstatus, den Hotjar zu diesem Zeitpunkt hält, sodass die CMP-Gating-Logik nicht dupliziert werden muss — aber der Routenwechsel selbst darf kein neues Skript-Laden auslösen, wenn die Einwilligung zwischen Seitenaufrufen widerrufen wurde.
Validierung der Integration
Der Validierungsschritt ist das, was Regulatoren prüfen und Publisher am häufigsten überspringen. Eine korrekt integrierte Hotjar-Implementierung muss vier Tests der Reihe nach bestehen. Erstens sollte eine neue Browser-Sitzung mit angezeigtem Banner, aber ohne getroffene Auswahl null Anfragen an static.hotjar.com, script.hotjar.com oder vars.hotjar.com und null _hj-Cookies in document.cookie erzeugen. Zweitens sollte das Ablehnen von Analytics diesen Zustand beibehalten — kein Skript-Laden, keine Aufzeichnung, keine Cookies. Drittens sollte das Akzeptieren von Analytics ein Skript-Laden und die erwarteten _hjSessionUser- und _hjSession-Cookies mit korrekten SameSite-Attributen erzeugen, und eine Heatmap-Aufzeichnung sollte innerhalb von fünf Minuten im Hotjar-Dashboard erscheinen. Viertens sollte ein nachträglicher Widerruf der Einwilligung die weitere Aufzeichnung sofort stoppen, die Cookies ablaufen lassen und eine Löschanfrage auslösen — eine verzögerte Bereinigung ist ein Verstoß.
Der Prüfpfad ist separat wichtig. Regulatoren erwarten, dass der Publisher für jede Aufzeichnung im Hotjar-Konto nachweisen kann, dass der Nutzer, der sie generiert hat, zum Zeitpunkt der Erfassung eine gültige Einwilligung erteilt hatte. Das Standardmuster besteht darin, die Einwilligungsversion und den Zeitstempel über hj('identify', userId, { consent_version: 'v3', consent_ts: ts }) als benutzerdefiniertes Attribut im Hotjar-Nutzerdatensatz einzubetten. Dadurch lässt sich jede spezifische Aufzeichnung auf einen bestimmten Eintrag im Einwilligungsprotokoll zurückverfolgen — das ist der Standard, den die EDPB gesetzt hat, und den Publisher unabhängig von ihrem Tätigkeitsort übernehmen sollten. Eine korrekt gesteuerte Implementierung, kombiniert mit Eingabe-Maskierung, die standardmäßig unterdrückt, und einem Löschpfad, der beim Widerruf aktiviert wird, macht Hotjar zu einem verteidigbaren Teil eines Forschungs-Stacks und nicht zu einer Compliance-Haftung.