Einwilligung, Exporte und Datenlebenszyklus

Pseudonym bedeutet nicht anonym

Der Tracker verwendet eine zufällige Browser-Besucherkennung im Sitzungsspeicher, deren Nutzung eine Einwilligung voraussetzt. Er erstellt keinen Geräte-Fingerprint und liest weder Formularwerte noch Seitentext automatisch aus. Eine Besucherkennung ist dennoch ein pseudonymes Datum: Eine Website kann sie einem Checkout zuordnen. Beschreibe individuelle Besucherpfade nicht als anonym.

Ausdrückliche Seitenbezeichnungen, Quellkampagnen, Ereignisnamen und Enum-Werte dürfen keine personenbezogenen Daten oder Geheimnisse enthalten. Syntaxprüfungen und Enum-Zulassungslisten verringern versehentliche Erfassung, beweisen aber nicht, dass eine Bezeichnung anonym ist. Der Projektinhaber kontrolliert diese Bezeichnungen. Land und Personenidentität werden nicht abgeleitet.

Einwilligung bewusst erteilen und widerrufen

Rufe reylin.consent(true) erst auf, wenn dein eigener Einwilligungsprozess diese Erfassung erlaubt. Der Tracker trifft diese Entscheidung niemals für dich. Einwilligung wird weder aus einem Klick noch aus einer Kontoanmeldung oder einem Kauf abgeleitet. Tracking-Warteschlangen vor dem Laden oder bei verweigerter Einwilligung werden verworfen, statt für eine spätere Wiedergabe gespeichert zu werden.

Der Aufruf reylin.consent(false) trennt Sichtbarkeitsbeobachter, löscht die Browser-Besucher-ID und bricht ausstehende Anfragen ab, soweit unterstützt. Eine bereits beim Server eingegangene Anfrage lässt sich durch Abbruch der Browser-Anfrage nicht zurückholen. Ein Widerruf stoppt künftiges Tracking in diesem Browser; er löscht weder bestehende Serverdatensätze noch bereits angenommene E-Mails.

// Connect these calls to your own consent manager.
reylin.consent(true);  // only after permission
reylin.consent(false); // withdrawal: stops future collection

Was der Projektexport enthält

Der JSON-Projektexport exportiert Analytics-Datensätze: Erfassungseinstellungen des Projekts, mit Einwilligung erfasste Ereignisse, Datensätze des Zahlungsjournals und Erstattungen. Er enthält ein ausdrückliches Manifest seines Umfangs. Er ist kein vollständiger Kontoexport und enthält weder Passwörter noch Sitzungszugangsdaten, geheime API-Tokens oder verschlüsselte Anbieterzugangsdaten.

Notizen im Begleitspeicher, gespeicherte Berichte, Benachrichtigungszustellungen, Anbieter-Eingangs- und Wiederholungsverlauf, zwischengespeicherte Google-Zeilen und Empfangs-Tombstones gehören nicht zu diesem Export. Ein Viewer mit Projektzugriff kann Projektanalysen exportieren; nur ein Inhaber kann Erfassungseinstellungen löschen oder ändern. Halte heruntergeladene Exporte privat und entferne nicht mehr benötigte Kopien.

Kontoexport Abschnitt für Abschnitt

Der Bereich Data export erfasst lokal gespeicherte Konto- und Begleitabschnitte getrennt. Unterstützte Abschnitte lassen sich in begrenzten JSON-Seiten exportieren, darunter private Arbeitsbereichskonfiguration, Berichtszustellungen, zwischengespeicherte Suchzeilen, Abonnement-Snapshots und ausgewählte Integrationsmetadaten. Nur der angemeldete Inhaber kann diese Kontoroute verwenden; Viewer-Rollen und schreibgeschützte API-Tokens können das nicht.

Jede Seite enthält Angaben zur Abdeckung und eine ausdrückliche Ausschlussliste. Eine fehlende oder schemaunverträgliche Datenbank ist nicht verfügbar und wird nicht stillschweigend als leerer Abschnitt gemeldet. Passwörter, Zugangsdaten-Hashes, Token-Geheimnisse, verschlüsselte Anbieterzugangsdaten, Worker-Interna und physische Backups sind ausgeschlossen. Selbst verfasste Notizen und Bezeichnungen können personenbezogene Informationen enthalten; schütze deshalb heruntergeladene Dateien.

Dies ist ein lokaler Export mit begrenztem Umfang, keine Bescheinigung universeller rechtlicher Vollständigkeit. Die Seiten entstehen getrennt, während Schreibvorgänge weiterlaufen können, nicht als atomarer Snapshot über mehrere Datenbanken. Lade jede Seite herunter, bewahre Abdeckungsangaben und Zeitstempel auf und verwende den Offline-Backup-Prozess nur, wenn ein Betreiber einen wiederherstellbaren Systemsnapshot benötigt.

Aufbewahrung und Löschung sind verschiedene Vorgänge

Tarifabhängige Aufbewahrung und die manuelle Aufbewahrungsaktion entfernen altes Ereignis-JSON. Sie entfernen weder Finanzjournal-Datensätze noch jeden Empfangsbeleg: Ereignis-IDs, Empfangszeitpunkte und Inhalts-Hashes können bleiben, um Idempotenz zu erhalten und doppelten Verbrauch zu verhindern. Damit wird nicht zugesagt, dass alle pseudonymen Daten an der Aufbewahrungsgrenze für Ereignisse verfallen.

Die Projektlöschung entfernt lokale Projektdatensätze und integrierte Begleitdaten nach Prüfungen auf aktive Worker. Kontolöschung erfordert Passwortprüfung und erfüllte Voraussetzungen für Anbieter- und Abrechnungsbereinigung. Anbieterseitige Daten, heruntergeladene Exporte, bereits angenommene E-Mails und Backups müssen gesondert bereinigt werden. Ein separater, nur Inhabern zugänglicher Besucherbereinigungsablauf koordiniert begrenzte lokale Speicher; ersetze ihn nicht durch Einwilligungswiderruf und verstehe seinen Abschluss nicht als physische oder universelle Löschung.

Koordinierte lokale Besucherbereinigung

Ein verifizierter Projektinhaber kann die Bereinigung einer einzelnen exakten pseudonymen Besucher-ID anfordern. Die Anfrage identifiziert keine Person. Sie speichert einen projektgebundenen SHA-256-Sperrhash, nicht die rohe Ziel-ID, um erneute Verarbeitung der bekannten ID und erneute Zahlungszuordnung zu verhindern. Der Hash bleibt ein pseudonymes Datum und ist weder Verschlüsselung noch Anonymisierung; wer mögliche IDs kennt, kann Vermutungen testen.

Das Projekt pausiert vorübergehend neue Erfassung und Finanzabgleich. Transaktionslokale Sperrgrenzen lassen bestehende Worker auslaufen, bevor begrenzte Stapel passende Ereignisse und verknüpfte Empfangs-/Stream-Datensätze entfernen, Besucher-Verknüpfungen von Zahlungen löschen, normalisierte Besucherfelder im Anbieter-Eingang bereinigen und ausstehende Projektbenachrichtigungen abbrechen. Geldbeträge, Währungen, Finanz-IDs, Zeitstempel, aggregierter Kontingentverbrauch und festgeschriebene Zuordnungsbezeichnungen bleiben erhalten.

Die Bereinigung kann nach Unterbrechungen fortgesetzt werden. Ein Auftrag kann auf einen aktiven oder ungewissen E-Mail-Versand warten; angenommene Nachrichten lassen sich nicht zurückholen. Verwaiste ungewisse Versandvorgänge erfordern kontrollierte Betreiberprüfung statt automatischem Neuversand. Andere Projekte können weiterarbeiten.

Der Abschluss beschreibt nur diesen festgelegten lokalen Umfang. Bereits bereinigte ältere Empfangsbelege ohne Besucherindex können erhalten bleiben. Vom Inhaber verfasste Notizen, versehentlich in Zuordnungsbezeichnungen gespeicherte persönliche Informationen, anbieterseitige Kopien, heruntergeladene Exporte, freie SQLite-Seiten/WAL und Backups müssen gesondert geprüft werden. Neue Browser-Kennungen lassen sich ohne Identitätstracking nicht derselben Person zuordnen; dieser Ablauf fügt ein solches Tracking nicht hinzu.

E-Mail-Berichte und externe Anbieter

Berichte gehen ausschließlich an die verifizierte E-Mail-Adresse des Inhabers. Der Versand ist standardmäßig unabhängig deaktiviert, auch wenn ein E-Mail-Adapter existiert. Die Oberfläche unterscheidet wartende und vom Anbieter angenommene Nachrichten; eine Annahme beweist keine Zustellung im Posteingang. Das Deaktivieren von Berichten bricht wartende Arbeit ab, kann aber keine bereits vom Anbieter angenommene Nachricht zurückholen. Noch nie versuchte Berichte verfallen nach 24 Stunden. Abgeschlossene Warteschlangendatensätze können nach 30 Tagen in begrenzten Hintergrundstapeln logisch bereinigt werden; Reservierungen für Zustelllimits verfallen nach 32 Tagen. Ein angehaltener oder überlasteter Scheduler kann die physische Zeilenlöschung verzögern, veraltete Berichte können aber nicht neu gesendet werden.

Stripe-Zahlungsverarbeitung und Reylins eigene SaaS-Abonnementabrechnung sind getrennte Integrationen und Datenflüsse. Das Trennen einer Integration verhindert künftige lokale Lesezugriffe, beweist aber keine Löschung beim Anbieter. Google Search Console verwendet eine ausdrücklich autorisierte Property und meldet Suchdaten des Anbieters, nicht beobachtete Einnahmen je Suchbegriff.

Vor der Erfassung echter Kundendaten

Veröffentliche einen zutreffenden Datenschutzhinweis des Betreibers und einen Einwilligungsablauf für die tatsächliche Bereitstellung. Benenne Betreiber, Kontaktweg, Zwecke, relevante Anbieter, Aufbewahrung und Verfahren zur Bearbeitung von Anfragen. Hier wurden weder Betreiberidentität noch Rechtsraum, Rechtsgrundlage oder Supportkontakt erfunden. Diese technische Anleitung ist keine rechtlich geprüfte Datenschutzerklärung und keine Compliance-Zertifizierung.

Prüfe produktive Zugriffskontrollen, bereitgestellte Anbietereinstellungen, Backup-Aufbewahrung, Wiederherstellungsverhalten und Löschverfahren. Logische SQLite-Löschung belegt keine physische Löschung aus WAL-Dateien, freien Seiten, Snapshots oder externen Systemen. Der Betreiber der Bereitstellung muss diese Lebenszykluskontrollen einrichten und testen.