Dokumentation

Attribute am Skript-Tag

Alles Folgende steht am Skript-Tag selbst, als data--Attribut. Alle Attribute sind optional außer data-api-key. Was Sie weglassen, behält den Wert aus den Tracker-Einstellungen Ihres Projekts; was Sie hier setzen, hat Vorrang – aber nur für diese Seite. Deshalb steht in den meisten Zeilen unten kein Wert: Ohne das Attribut gilt das, was in Ihrem Projekt eingestellt ist.

Funktionen auf der Seite

interface TrackerInitConfig {
  apiKey?: string;
  apiHost?: string;
  flushIntervalMs?: number;
  maxQueueSize?: number;
  walkDepth?: number;
  maxTextLength?: number;
  autocapturePageviews?: boolean;
  autocapture?: boolean;
  autocaptureElements?: string[];
  piiUrlParams?: string[];
  normalizePathIds?: boolean;
  piiPathPatterns?: string[];
  excludedUrls?: string[];
  samplingRate?: number;
  traits?: string[];
}

Die Werte, mit denen das Skript startet

Diese Werte bringt das Skript selbst mit, und sie haben genau eine Aufgabe: Sie sind die Regeln, die zwischen dem Start des Skripts und dem Eintreffen der Tracker-Einstellungen Ihres Projekts gelten, damit ein in dieser Spanne entstandenes Event überhaupt bereinigt werden kann. Ein Grund zu senden sind sie nie. Treffen die Einstellungen gar nicht ein, erfasst dieser Seitenaufruf nichts, statt unter Regeln zu erfassen, die nicht die Ihres Projekts sind – eingebaut ist etwa überhaupt keine Bereinigung von Pfaden.

Wie Events gesendet werden

Events warten im Arbeitsspeicher des Browsers und gehen im Stapel hinaus – entweder wenn das Sende-Intervall abgelaufen ist oder sobald die Warteschlange max_queue_size erreicht, je nachdem, was zuerst eintritt. Ein Stapel ist eine Browser-Anfrage – ein fetch mit gesetztem keepalive –, und genau diese Einstellung lässt sie zu Ende laufen, auch wenn die Seite, die sie gestartet hat, längst weg ist. Derselbe Aufruf sendet den Rest, sobald die Seite ausgeblendet oder geschlossen wird. Alle drei Momente warten darauf, dass die Tracker-Einstellungen Ihres Projekts eingetroffen sind, auch der Versand beim Ausblenden oder Schließen – ein Tab, der eine Sekunde nach dem Öffnen geschlossen wird, kann also nichts senden, bevor die Einstellungen da sind. Im Browser des Besuchers wird dabei zu keinem Zeitpunkt etwas abgelegt.

Ein fehlgeschlagener Versand wird nicht immer wiederholt. Bei einem Netzwerk- oder Serverfehler wandern die Events wieder an den Anfang der Warteschlange und gehen beim nächsten Versuch mit. Eine Ablehnung nicht. Ein ungültiger Schlüssel, eine Website, die nicht in den erlaubten Domains des Projekts steht, oder ein Projekt über seinem Monatskontingent schaltet das Tracking für den Rest dieses Seitenaufrufs ab und schreibt in die Browser-Konsole, welcher der drei Fälle es war. Ein erneuter Versuch hilft nicht, und Schweigen würde Ihnen nichts lassen, wonach Sie suchen könnten.

Die Warteschlange fasst höchstens 100 Events. Darüber hinaus werden neue verworfen, damit eine Seite ohne funktionierenden Schlüssel keine endlose Warteschlange aufbaut.

Für die Anfrage, die die Einstellungen Ihres Projekts holt, gilt dieselbe Regel – und sie wiegt schwerer, denn vorher wird nichts gesendet. Ein Netzwerkfehler oder ein Timeout wird über einige Sekunden ein paar Mal wiederholt. Eine Ablehnung stoppt sie sofort: Ein falscher Schlüssel oder eine Website außerhalb der erlaubten Domains antwortet beim zweiten Mal nicht anders. Gelingt sie nie, sendet dieser Seitenaufruf nichts, und eine Zeile in der Konsole sagt, dass es so ist und warum.

Datenschutz auf einen Blick

Der Tracker ist auf Datenschutz hin gebaut: keine Cookies, kein localStorage, kein Fingerprinting, keine personenbezogenen Daten. Formularfeldwerte werden nie gelesen – es gibt keine Einstellung, die das einschaltet. URL-Parameter, die erfahrungsgemäß persönliche Daten enthalten, werden entfernt, bevor etwas gesendet wird. Das ganze Bild steht in der Datenschutz-Dokumentation.