Dokumentation

Im Browser des Besuchers wird nichts gespeichert

Keine Cookies, kein localStorage, kein sessionStorage. Auf der Seite des Besuchers überdauert nichts den Wechsel von einer Seite zur nächsten. Jede Anfrage geht mit credentials: 'omit' hinaus, was dem Browser sagt, keine vorhandenen Cookies anzuhängen. Es gibt eine Ausnahme, und sie betrifft nicht Ihre Besucher. Der Element Picker – das Werkzeug, mit dem Sie das Tracking einrichten – legt seinen eigenen Zustand in sessionStorage ab. Das geschieht nur, solange er offen ist, und erst, nachdem jemand mit einem Konto ihn eingeschaltet hat. Einzelheiten dazu stehen in unserer Datenschutzerklärung.

Kein Fingerprinting

Fingerprinting heißt, ein Gerät an seinen Eigenheiten wiederzuerkennen: welche Schriften es hat, wie es ein Bild zeichnet, wie groß sein Bildschirm genau ist. So wird Tracking ohne Cookies üblicherweise gemacht. Wir machen nichts davon. Keine Canvas-Hashes – der Trick, Browser an winzigen Unterschieden darin zu unterscheiden, wie jeder dasselbe Bild zeichnet –, keine Schriftartenlisten, kein Geräteprofil in irgendeiner Form.

Wie ein Besucher wiedererkannt wird – und wie lange

Statt den Besucher zu markieren, ermittelt der Server eine Identität aus der Anfrage, die ohnehin bei ihm ankommt. Dafür nimmt er drei Dinge: die IP-Adresse, die User-Agent-Kennung des Browsers und die ID Ihres Projekts. Die gehen durch eine Einwegfunktion mit Schlüssel – einen HMAC –, deren geheimer Schlüssel um Mitternacht in der Zeitzone Ihres Projekts ausgetauscht wird. „Einweg“ heißt: Aus dem Ergebnis lässt sich keine IP-Adresse zurückgewinnen. IP und User-Agent dienen nur dieser Berechnung und werden danach verworfen; sie werden nie in die Datenbank geschrieben und nie protokolliert. Ein Besucher bleibt damit für den Rest dieses Tages wiedererkennbar – über Neuladen, Tabs und einzelne Seiten hinweg. Am nächsten Tag ist er es nicht mehr, weil es den Schlüssel, der den Wert erzeugt hat, nicht mehr gibt. Cookies, localStorage und sessionStorage sind daran nicht beteiligt.

Formularfeldwerte werden nie gelesen

Bei einem Klick erfasst der Tracker drei Dinge: das Tag des Elements, seinen sichtbaren Text und eine Beschreibung, wo es in der Seite sitzt. Diese Beschreibung entsteht aus Tag-Namen, Eingabetypen und ARIA-Rollen. Die id eines Elements und seine CSS-Klassen erfasst er nie. Was jemand eingetippt hat, erfasst er nie. Dafür gibt es keine Einstellung und keine Voreinstellung, die man ändern könnte. Der Code, der ein abgeschicktes Formular erfasst, schaut die Felder gar nicht erst an – er hält fest, dass das Formular abgeschickt wurde, um welches es sich handelt, und nichts von seinem Inhalt. Sensible Elemente gehen noch einen Schritt weiter und werden vollständig übersprungen. Ein Passwortfeld, ein verstecktes Feld oder eine Kreditkarteneingabe wird nicht einmal als Klickziel erfasst, ganz gleich, was Ihre Klick-Einstellungen sagen. Erkannt werden sie an type="password", type="hidden" und autocomplete="cc-*".

Es gibt kein Opt-in – aber Sie können ein Element benennen

Andere Analyse-Werkzeuge bieten einen Schalter an, der das Mitschneiden von Eingaben einschaltet. Hier gibt es nichts einzuschalten. Sie können einem Element allerdings einen Namen geben. Setzen Sie ein data-track-Attribut an einen Button, einen Link, ein Formular oder ein einzelnes Feld, dann werden die Interaktionen damit unter diesem Namen erfasst statt unter einem CSS-Selektor. Genau das macht sie in Ihren Berichten auffindbar. Mit data-track-*-Attributen hängen Sie eigene Angaben daneben:

<button data-track="signup-cta" data-track-plan="pro">
  Start free trial
</button>

Das fügt einen Namen und Ihre eigenen Angaben hinzu, sonst nichts – der Inhalt des Feldes wird weiterhin nie gelesen. Sensible Felder bleiben ausgeschlossen, auch wenn sie ein data-track-Attribut tragen.

Persönliche Daten in Adressen werden entfernt

Adressen verraten mehr, als man erwartet: ein Link zum Zurücksetzen des Passworts, eine E-Mail-Adresse, die in den URL-Parametern hängen geblieben ist – dem Teil der Adresse nach dem ?. Der Tracker entfernt die Parameter, die am ehesten etwas Persönliches tragen – zu Beginn email, token, key, password und secret. Eigene Namen und die Pfadabschnitte, die verschwinden sollen, ergänzen Sie unter Datenschutz & Sicherheit. Jede Adresse verlässt den Browser nach den Regeln Ihres Projekts bereinigt, auch die des ersten Seitenaufrufs. Bereinigt wird, während ein Stapel zusammengestellt wird, also nachdem diese Regeln geladen sind, und nicht im Moment des Events.

Kein Consent-Banner erforderlich

Cookie-Banner gibt es, weil Tracking normalerweise etwas auf dem Gerät des Besuchers zurücklässt. Dieses Werkzeug lässt nichts zurück, vermisst nichts am Gerät und erfasst keine personenbezogenen Daten. In vielen Ländern ist deshalb kein Banner nötig, um es zu verwenden. Das ist eine allgemeine Aussage und keine Rechtsberatung. Was für Sie gilt, hängt davon ab, wo Sie und Ihre Besucher sind und was Sie sonst noch auf Ihrer Website eingebaut haben. Lassen Sie es von Ihrer Rechtsberatung prüfen.

DSGVO und Datenschutz

Die Einhaltung folgt aus der Bauweise, sie ist nicht nachträglich angebaut:

• Der Tracker erfasst und speichert von sich aus keine personenbezogenen Daten.
• Keine Cookies, kein Browser-Speicher, nichts Dauerhaftes, das auf dem Gerät zurückbleibt.
• Besucher-Identitäten stammen aus einer Einwegfunktion, deren Schlüssel täglich wechselt. Sie lassen sich weder zurückrechnen noch über Tage hinweg zusammenführen.
• IP-Adressen dienen allein dieser Berechnung, im Arbeitsspeicher, und werden nie gespeichert.
• Ihre Daten werden nicht verkauft und nicht an Dritte weitergegeben. Gespeichert werden sie auf Servern in der EU.
• Ausgeschlossene Adressen und entfernte URL-Parameter erlauben es Ihnen, eine Erfassung, die Sie nie wollten, von vornherein zu verhindern.
• Die Liste erlaubter Domains sorgt dafür, dass Events nur von Websites angenommen werden, die Sie benannt haben.