Technischer Datenschutz und Speicherung

Diese Anleitung beschreibt den aktuellen Browser-Tracker. Lesen Sie die Datenschutzerklärung für die Richtlinien des Seean-Dienstes und konfigurieren Sie den Einwilligungsablauf Ihrer Website nach Ihren Anforderungen. Eine technische Installation ist keine rechtliche Konformitätsbewertung.

Browserspeicher

Der Standard-Tracker setzt keine Cookies und hält keine Besucher- oder Sitzungs-Messkennung in localStorage oder sessionStorage. Sein temporärer Navigationszustand lebt im Arbeitsspeicher. Die Browser-Opt-out-Einstellung seean_ignore kann im localStorage verbleiben.

Der Collector leitet einen pseudonymen Besucher-Hash aus einem Server-Secret, der Website, dem UTC-Datum, dem Domain-Bereich der Website, der IP-Adresse und dem User-Agent ab. Rohe IP-Adressen und User-Agents werden nicht in Analytics-Ereignisdatensätzen gespeichert. Der Hash ändert sich um Mitternacht UTC und unterscheidet sich zwischen Websites. Netzwerkwechsel oder gemeinsam genutzte Netzwerke können scheinbare Besucher aufteilen oder zusammenführen; diese Zahlen sind keine exakten Personenzahlen. Ist keine IP verfügbar, ersetzt sie die temporäre Nonce des Dokuments, sodass Kontinuität beim Neuladen nicht garantiert ist.

Sitzungen werden vom Collector zugewiesen. Aktivität desselben Tagesbesuchers setzt eine Sitzung fort, bis 30 Minuten Inaktivität, ein rückwärts laufender Zeitstempel oder eine geänderte getaggte Kampagne eintritt (UTM-Felder oder der Name eines Anzeigen-Klick-ID-Parameters; Klick-ID-Werte werden nie gelesen oder gespeichert). Ereignisdatensätze tragen außerdem den Seitentitel (200 Zeichen), die Bildschirmgröße und das erste Accept-Language-Tag des Browsers; der Query-String selbst wird nicht erfasst. Der Tracker entfernt veralteten _seean_v- und _seean_session-Speicher, wenn er normal initialisiert. Zuvor erfasste Kennungen, gespeicherte Berichte und Bestellungen bleiben unberührt; dieser Übergang re-identifiziert keine historischen Besucher.

Origins und Domains

Die konfigurierte Website-Domain und ihre Subdomains teilen die Tagesidentität, wenn sie dasselbe Token und dieselben Anfrage-Metadaten verwenden. Nicht verwandte Domains bleiben getrennt abgegrenzt. Die optionale domainübergreifende Übergabe verwendet ein zufälliges Token desselben Tages in Links und im sessionStorage; der Server hasht es für jede Website und jeden UTC-Tag separat. Sie ist aus, sofern sie nicht auf beiden Websites über das explizite Snippet oder die minimale Dashboard-Konfiguration aktiviert wird. Keine eingehende Übergabe wird übernommen, bevor diese Konfiguration erfolgreich ist. Das rohe Übergabe-Token wird nicht in Analytics-Datensätzen gespeichert.

Vom Tracker gesendete Daten

Erfassungs-Payloads enthalten das öffentliche Website-Token, eine temporäre Sitzungs-Nonce, die Browser-Zeitzone, wenn verfügbar, Hostname, Pfadname und die UTM-Werte source, medium, campaign, term und content. Die optionale domainübergreifende Erfassung sendet auch ihr Übergabe-Token. Der Collector gibt den täglichen Besucher-Hash für die optionale Checkout-Attribution zurück. Seitenaufrufe enthalten den Einstiegs-Referrer der Dokumentsitzung. Web Vitals senden Messwerte und IDs; benutzerdefinierte Ereignisse können die von Ihrer Anwendung gelieferten Eigenschaften enthalten.

Das Seitenfeld verwendet location.pathname, nicht die vollständige URL. UTM-Werte werden jedoch separat gelesen, und der Einstiegs-Referrer kann URL-Informationen enthalten, die die Referrer-Richtlinie des Browsers erlaubt. Legen Sie keine Passwörter, privaten Tokens oder persönlichen Angaben in Pfade, Kampagnen oder Eigenschaften benutzerdefinierter Ereignisse. Das Weglassen der vollständigen Seiten-URL bereinigt diese Felder nicht automatisch.

Der Erfassungsserver empfängt außerdem normale Anfrage-Metadaten. Diese Liste der Browserfelder ist keine Behauptung, dass Netzwerkanfragen die IP des Absenders vor der Hosting-Infrastruktur verbergen.

Browser-Präsenz

Solange eine erfasste Seite sichtbar ist, sendet ein Präsenzsignal alle 30 Sekunden dieselben website-bezogenen Tagesidentitäts-Eingaben, den Pfadnamen und den Einstiegs-Referrer, die der Tracker verwendet. Es untersucht keinen Seiteninhalt, zeichnet keine Klicks auf und identifiziert kein Konto. Die Präsenz respektiert dieselben Datenschutzsignale, Ausschlüsse und die Erfassungsverfügbarkeit. Sie fügt keine Seitenaufrufe, benutzerdefinierten Ereignisse oder Verbrauch hinzu und verlängert keine Analytics-Sitzungen.

Der Collector behält nur den letzten Präsenzzustand pro Website und Tagesbesucher, mit ungefähren Standort-/Gerätemetadaten für Echtzeit. Er ist vom Rohereignisverlauf getrennt. Ein Zustand fällt nach zwei Minuten aus dem Online-Fenster; eine begrenzte Bereinigung läuft alle fünf Minuten. Zurücksetzen und Website-Löschung leeren ihn ebenfalls. Bestehende verschlüsselte Wiederherstellungskopien folgen der Backup-Aufbewahrungsrichtlinie.

Datenschutzsignale und Opt-out

Der Tracker unterdrückt die Erfassung bei Global Privacy Control (true), unterstützten Do-Not-Track-Werten (1 oder yes), Browser-Automatisierung (navigator.webdriver === true) oder localStorage seean_ignore mit dem Wert true. Er prüft dies vor der Initialisierung des Besucherzustands und vor dem Senden späterer Aktivität. Vorhandener Speicher wird bei einer geänderten Einstellung nicht automatisch gelöscht.

Eine anfänglich ignorierte Seite stellt wirkungslose Tracker-Methoden bereit; die Existenz von window.seean beweist keine Erfassung. Wird ein anfängliches Opt-out entfernt, laden Sie die Seite neu, um das Tracking zu initialisieren. Ein bereits aktiver Tracker prüft spätere Opt-out-Änderungen, bevor er weitere Daten sendet. Siehe Ausschlüsse für die Browser-Steuerung und serverseitige Pfad-/Hostnamen-Regeln.

Einwilligung und Verifizierung

Seean stellt kein Einwilligungsbanner und keine allgemeine Consent-Management-API bereit. Wenn Ihre Website vor Analytics eine Erlaubnis benötigt, muss Ihr Einwilligungssystem steuern, wann das Skript geladen wird und was bei einer geänderten Erlaubnis geschieht. data-local aktiviert nur lokale Tests; es übergeht keine Datenschutzeinstellungen. Ein Tag-Manager-Trigger ist selbst keine Besuchererlaubnis.

Prüfen Sie die Einwilligungszustände, die Ihre Website unterstützt, einschließlich Ablehnung und späterer Zustimmung, zusammen mit den Installationsprüfungen. Interpretieren Sie einen erfolgreichen Skript-Download oder eine leere 204-Antwort nicht als Beweis, dass ein Ereignis gespeichert wurde.

Identifizierte Nutzer (Opt-in)

Ein Website-Eigentümer kann Identify users (Nutzer identifizieren) unter Settings → Installation aktivieren und seean.identify(id) für angemeldete Nutzer seiner Website aufrufen. Der Collector speichert diese vom Kunden gelieferte Kennung dann als uid-Spalte in den Ereignisdatensätzen der Website; solange die Option aus ist, wird jede ID in einer Payload vor der Speicherung verworfen. Seean leitet diese Kennung nie ab oder rät sie, und der tägliche Besucher-Hash bleibt davon unverändert. Die ID wird nur für die offene Seite im Arbeitsspeicher des Trackers gehalten, nie in Cookies oder im Browserspeicher. Identifizierte Datensätze folgen derselben dreijährigen Aufbewahrung, erscheinen im Ereignis-CSV des Eigentümers, können pro Person aus dem Dashboard gelöscht werden und sind nie in geteilten Dashboards, eingebetteten Widgets, der öffentlichen Demo oder der Analytics-API enthalten. Siehe Personen und Retention.

Entfernung

Entfernen Sie das Skript von jedem Installationsort und veröffentlichen Sie die Änderung, um die künftige Erfassung auf neu geladenen Seiten zu stoppen. Eine bereits offene Seite kann das geladene Skript behalten, bis sie neu geladen oder geschlossen wird. Das Entfernen des Skripts löscht weder Browserspeicher noch zuvor erfasste Berichte. Sehen Sie in der Website-Verwaltung nach verfügbaren Datenverwaltungsaktionen.

Serverspeicherung und Wiederholungen

Rohereignisse und Web Vitals verwenden den Analytics-Speicher. Angenommene Datensätze bleiben bei einem temporären Fehler der Speicherübertragung in der Warteschlange und werden automatisch erneut versucht. Speicherwiederholungen behalten die Identität eines angenommenen Datensatzes: Das Kopieren desselben Datensatzes zwischen den Speichern von Seean fügt keinen weiteren Besuch oder keine weitere Web-Vitals-Stichprobe hinzu. Ein später angenommener Wert für dieselbe Web-Vitals-Metrik-ID aktualisiert diese Stichprobe, auch wenn ein älterer Tracker seine Aktualisierungsfolge weglässt. Separate eingehende Seitenaufruf-Anfragen sind weiterhin separate Ereignisse; dies ist keine Garantie, dass Ihre Integration beliebige Erfassungsanfragen erneut senden kann, ohne sie erneut zu zählen.

Bei einer Rohspeicher-Warteschlange muss eine unbekannte oder abgelaufene Web-Vitals-Identität geprüft werden, bevor eine Stichprobe angenommen wird. Diese Prüfung wartet nicht auf unabhängige Ereignisse in der Warteschlange oder einen Wiederherstellungs-Snapshot. Jede bekannte Messung hält ihren zuletzt angenommenen Wert verfügbar, bis genau diese Aktualisierung den Analytics-Speicher erreicht hat; eine abgelaufene, vollständig übertragene Identität kann unabhängig vom Traffic anderer Websites bereinigt werden. Ist der Analytics-Speicher selbst nicht verfügbar, gibt eine kalte Identitätsprüfung 503 zurück, ohne die Stichprobe hinzuzufügen oder ihr Kontingent zu belasten. Seitenaufrufe und Aktualisierungen, deren Identität bereits bekannt ist, können weiterhin in die Warteschlange aufgenommen werden. Nach einem Website-Reset berücksichtigt die Identitätssuche nur Messungen ab dieser Reset-Grenze. Der Browser-Tracker garantiert keine Wiederholung abgelehnter Anfragen; fehlende Messungen sind keine Nullwerte.

Eine kleine Aktivitätszusammenfassung pro Website speichert die erste und letzte vorbereitete Ereigniszeit sowie die letzte Seitenaufruf-Zeit für Wartezustände und den Einrichtungsstatus. Sie enthält keine Ereigniseigenschaften oder Besucherkennungen und folgt Website-Reset und -Löschung.

Die Erfassung läuft auch während Wiederherstellungs-Snapshots weiter. Neu angenommene Datensätze können kurz in der Übertragungswarteschlange warten, sodass ein Bericht in seinem Vorbereitungszustand bleiben kann, bis diese Datensätze verfügbar sind; Leser, die sie benötigen, fordern die Übertragung sofort an, und nur ein laufender Wiederherstellungs-Snapshot verschiebt sie.

Seitenaufrufe, Ereignisse, Web Vitals und Bestellungen folgen der rollierenden Aufbewahrungsrichtlinie von drei Kalenderjahren. Die Bereinigung verwendet einen UTC-Kalender-Stichtag mit Millisekundengenauigkeit. Das Zurücksetzen oder Löschen einer Website gilt auch für Datensätze, die auf die Speicherübertragung warten; eine verzögerte interne Wiederholung kann sie nicht in Berichte zurückbringen. Verschlüsselte Wiederherstellungskopien folgen der separaten Backup-Aufbewahrungsrichtlinie.

Die Rohbereinigung läuft in begrenzten Hintergrund-Batches. Löschmarkierungen behalten nur die Schlüssel, die nötig sind, damit eine ältere interne Wiederholung einen entfernten Datensatz nicht neu anlegt; Ereigniseigenschaften, Pfade und Messwerte werden aus der aktiven Version entfernt. Ersetzte Speicherteile und verschlüsselte Wiederherstellungskopien werden nach ihren eigenen Speicherzeitplänen freigegeben. Dies ist keine sofortige sichere Löschung jeder physischen Kopie.

Wenn die Quellaufbewahrung Datensätze entfernt, die eine ältere On-Demand-Aufschlüsselung der Übersicht benötigt, aktualisieren Sie die Analyse, bevor Sie diese Liste öffnen. Gespeicherte Berichtsergebnisse bleiben unverändert; das System mischt keine aufbewahrten Summen mit neu berechneten Details aus einem anderen Datensatz.

Etwas unklar? Support kontaktieren.