Privacy: was wir nicht sammeln

Mit fastmon sollst du Real-User-Performance messen können, ohne dafür ein Datenschutz-Minenfeld aufzumachen. Kurz: keine IPs auf der Platte, kein roher User-Agent, kein Fingerprinting, kein Cross-Site-Tracking, EU-Infrastruktur, null Cookies und ein speicherfreier Default. Auf dieser Seite steht die ausführliche Version: was die Zusagen in der Praxis heißen, was wir trotzdem sammeln, damit das Produkt funktioniert, und wie sich das je nach Tracker-Einstellungen der Site unterscheidet.

Was wir nie sammeln, egal wie eingestelltCopy Anchor Link

Diese Regeln gelten unabhängig davon, wie die Site konfiguriert ist:

Zu Cookies und StorageCopy Anchor Link

fastmon setzt überhaupt keine Cookies, in keiner Konfiguration. Das Einzige, was der Tracker auf das Gerät des Besuchers schreiben kann, ist ein einzelner sessionStorage-Eintrag (_fms), die Session-ID, und das nur, wenn collect_sessions an ist. Per Default schreibt er nichts: das Standard-Preset, mit dem neue Sites starten, speichert keine Session-ID, also keine Cookies, kein localStorage, kein sessionStorage, kein IndexedDB, keine Cache API.

Speicherfrei bezieht sich darauf, was auf dem Gerät liegt. Ob das Auslesen der Performance-APIs ein Zugriff im Sinne des TDDDG ist, steht unter Consent und TDDDG.

Wenn collect_sessions an ist, entscheidet der Schalter session_consent, ob die Session-ID beim Pageload geschrieben oder aufgeschoben wird, bis dein CMP Consent erteilt. Die ID liegt im sessionStorage und verschwindet beim Schließen des Tabs. Es gibt nirgends im Design einen persistenten Identifier oder ein seitenübergreifendes Cookie.

Was wir sammelnCopy Anchor Link

Genau das, was wir brauchen, um Web Vitals und Performance pro Seite auszurechnen. Die genaue Liste Feld für Feld steht unter Der RUM-Beacon; die Kategorien:

• Seiten-URL: Origin + Pathname, dazu die Query-Parameter-Namen, wenn collect_query_keys an ist (das Default-Preset Standard). Hash-Fragment und Query-Werte werden im Tracker verworfen; ein Wert bleibt nur für Schlüssel, die du allow-listest (collect_query_values_for).
• Referrer: im Tracker auf Origin + Pathname gekürzt (Query und Hash verworfen), serverseitig in eine Quelle und ein Medium klassifiziert. Der Rohwert wird vor jedem Logging-Pfad verworfen und persistiert nie, in keinem Modus.
• Web Vitals: LCP, INP, CLS, FCP, TTFB und verwandte Timings.
• Navigation-Timing: Nav-Typ, TTFB, Pageload-Timing.
• Resource-Timing: pro Kategorie aggregierte Byte-Größen und Counts (Script, CSS, Image, Font, Sonstige).
• Server-Timing: die Metriken, die dein eigenes Backend an seine Response anhängt (Phasen-Dauern, Cache-Status, Seitentyp, Origin-Host). Server-Selbstmessung, keine Besucherdaten; Namen und Werte werden beim Ingest formgeprüft, gegen eine Denylist geführt und von allem ID-Förmigen befreit. Das eine besuchernahe Feld ist das optionale Logged-in-Flag (fm-loggedin): ein einzelnes yes/no über den Render-Modus, nur vorhanden, wenn dein Server es sendet, und nie ein Identifikator. Siehe Server-Timing-Header.
• Fehler: Typ und Count immer. Die Fehler-Message zu behalten, ist Opt-in (collect_error_messages) und läuft auch dann durch einen immer aktiven Scrubber, der URLs, E-Mail-Adressen, numerische IDs und Strings in Anführungszeichen vor dem Versand durch * maskiert. Stack-Frame-Detail ist Opt-in (collect_error_frames); aus fallen Frames auf host-only zusammen, außer deinen eigenen First-Party-External-Scripts, die immer Pfad und Zeile/Spalte behalten, damit ein Bug im eigenen Code lokalisierbar bleibt. Diese Position ist für jeden betroffenen Besucher identisch: sie identifiziert den Fehler, nicht die Person.
• Umgebung: Browser-Familie, OS-Familie, Device-Klasse (mobile/tablet/desktop), Viewport-Klasse, effektiver Connection-Typ, Netzwerk-RTT- und Downlink-Schätzungen. navigator.deviceMemory, navigator.hardwareConcurrency, das saveData-Flag, prefers-color-scheme und prefers-reduced-motion lesen wir gar nicht.
• Geo und Netzwerk: das Land (zweistelliges ISO) und das Netzwerk des Besuchers als asn (etwa 3320) und isp (Deutsche Telekom AG). Beides leitet der Edge aus der IP ab und reicht es als Request-Header weiter; die IP selbst erreicht die Anwendung nie.
• Bot- und Rechenzentrums-Labels: drei am Edge abgeleitete Labels, die Netzwerk und Software des Clients beschreiben, nicht den Besucher: einen Cloud-/Hosting-Provider (etwa aws oder hetzner), einen benannten Crawler (etwa googlebot oder gptbot) und dessen Kategorie (etwa search-engine oder ai-crawler). Alle drei werden am Edge aus IP und User-Agent abgeleitet, bevor beide verworfen werden, stammen aus einer festen, geschlossenen Liste und werden auf einen kurzen Slug bereinigt; keine rohe IP und kein roher User-Agent bleiben. Siehe Bot- und Rechenzentrums-Labels.
• Kampagnen-Attribution: utm_source / utm_medium / utm_campaign / utm_term / utm_content und ein Ad-Plattform-Label click_id_param (z. B. "gclid"), aus der Seiten-URL extrahiert. Jedes Feld auf 64 Zeichen begrenzt. Der Click-ID-Wert (Cj0KCQabc...) wird bewusst verworfen; nur das Label, welche Plattform den Klick geschickt hat, wird gespeichert.
• LCP-Image-URL, LoAF-Script-Pfade, Third-Party-Domain-Map: in jeder Konfiguration erfasst, bei der Erfassung auf Origin + Pathname reduziert. Sie beschreiben die Seitenzusammensetzung des Kunden (siehe Site-Metadaten vs. Besucherdaten), nicht den Besucher.
• Page-Type-Tag: der content deines Tags <meta name="fm-page-type">, bis 32 Zeichen, in jeder Konfiguration.
• Fetch/XHR-Aggregate: Opt-in (collect_fetch_xhr). Aufruf-Counts, Dauern und Fehlercodes pro Endpunkt für deine eigenen APIs. Pfade werden strenger als Seiten-URLs bereinigt (Query, Fragment und ID-artige Segmente entfernt).
• Checkout-Stufe und Warenkorb-Interaktion: zwei serverseitig abgeleitete Labels, beim Ingest aus Werten berechnet, die schon auf dem Beacon stehen. Die Stufe (cart, checkout, success oder leer) entsteht durch Abgleich der bereinigten Seiten-URL mit URL-Mustern; der Warenkorb-Merker aus einem Fetch/XHR-POST an einen bekannten Warenkorb-Endpunkt. Keines von beiden fügt dem Beacon ein Feld hinzu oder liest etwas, das deine Einstellungen nicht schon erlaubt haben. Standardmäßig an, mit Opt-out (checkout_tracking). Siehe Checkout-Funnel.
• Session-ID: nur wenn collect_sessions an ist (das Preset Full, oder nachdem dein CMP grantConsent() aufruft). Liegt im sessionStorage, gruppiert Pageviews einer Session, stirbt mit dem Tab.

Mehr schickt der Beacon nicht, außer den Events, die dein Shop selbst sendet.

Bot- und Rechenzentrums-LabelsCopy Anchor Link

Jedes Beacon wird am Edge als Bot-, Crawler- oder Rechenzentrums-Traffic markiert, damit es sich von echten Besucherdaten trennen lässt. Drei unabhängige Prüfungen laufen am Edge, die ersten beiden gegen eine feste, kuratierte Liste, kein offenes Nachschlagen:

• Cloud-/Hosting-Provider, gesetzt, wenn die Client-IP in einem bekannten Rechenzentrums-Bereich liegt: einer von aws, azure, googlecloud, oracle, digitalocean, hetzner, ovhcloud, linode, vultr, alibaba, tencent.
• Crawler, gesetzt, wenn der User-Agent zu einem bekannten Bot passt: ein Name (googlebot, bingbot, gptbot, applebot, duckduckbot, amazonbot, perplexitybot, yandex, baidu, meta oder unknown für eine generische Bot-Heuristik) plus eine Kategorie wie search-engine, ai-crawler, seo oder monitoring.
• User-Agent-Anomalie, gesetzt, wenn der User-Agent den Low-Entropy Client Hints des Browsers (sec-ch-ua, sec-ch-ua-platform) widerspricht: headless, spoofed oder non-browser. Die Hints werden am Edge ausgewertet und mit dem Rest des rohen Requests verworfen; gespeichert wird nur das Verdikt.

Der am Edge abgeleitete stitch-IdentifierCopy Anchor Link

Für Unique-Visitor-Zahlen und per-Besucher-Performance-Debugging, ohne dass etwas auf dem Gerät liegt, kann der Edge einen kurzlebigen Join-Key unter einem rotierenden Salt berechnen, bevor IP und User-Agent zerstört werden:

stitch = HMAC-SHA256(rotierendes_Salt, IP | User-Agent | collector_hash)

abgeschnitten auf 128 Bit (32 Hex-Zeichen auf dem Wire). Er wird gespeichert, wann immer store_stitch an ist, was das Default-Preset Standard einschließt; das Preset Minimal ist das Opt-down, das die Zeile ganz ohne Besucher-Identifier lässt. Eigenschaften, wenn er an ist:

• Forward Secrecy by Construction. Das Salt ist ein 32-Byte-Wert aus crypto/rand, lebt ausschließlich im RAM des aktiven Edge und rotiert einmal täglich um 02:00 UTC. Es wird nie persistiert, nie verteilt, nie geloggt. Wer später Zugriff auf die Zeile bekommt, kann stitch nicht zurück auf (IP, UA) rechnen: das Salt, mit dem es produziert wurde, ist weg.
• Verknüpfbarkeit gedeckelt, höchstens ~24 h. Bei jeder Salt-Rotation bekommt derselbe Besucher einen neuen stitch-Wert. Cross-Pageview-Verknüpfung kann nicht über ein Salt-Fenster hinaus anwachsen.
• Auf eine Application begrenzt. Der collector_hash steckt im HMAC-Input, dieselbe (IP, UA) ergibt also pro Application einen anderen stitch, und nichts verknüpft einen Besucher mit der Seite eines anderen Betreibers. Innerhalb einer Application ist der Wert auf allen Domains gleich, die sie bedient. Genau das lässt einen org-weiten Tracker einen wiederkehrenden Besucher einmal zählen statt einmal pro Domain.
• Nichts, was die Seite behauptet, geht in den Input. Der Host aus dem Beacon-Body bleibt draußen.
• Das Salt ist das einzige Geheimnis. Die übrigen HMAC-Inputs sind öffentlich oder stehen in der gespeicherten Zeile selbst, und der Eingaberaum ist klein genug zum Durchprobieren; wer das lebende Salt hätte, könnte ein vermutetes (IP, UA)-Paar durch Nachrechnen bestätigen. Niemand hat es: es existiert nur im laufenden Edge-Prozess und ist nach der Rotation weg. Die Garantie ist operativ (RAM-only-Salt, tägliche Rotation), nicht mathematisch.

Ehrlich eingeordnet: solange das Salt lebt, ist stitch ein pseudonymer Besucher-Identifier und damit personenbezogenes Datum, verarbeitet nach Art. 6 Abs. 1 lit. f DSGVO mit dokumentierter Interessenabwägung. Weil er unter dem Default-Preset Standard an ist, benenne ihn in deiner Datenschutzerklärung. Wenn du lieber gar keinen Besucher-Identifier speicherst, hält store_stitch aus (das Preset Minimal) die Zeile echt anonym.

Identifier abschalten, oder aus lassenCopy Anchor Link

Zwei Schalter pro Site entscheiden, ob überhaupt ein Besucher-Identifier in die Speicherung gelangt. Unter dem Default-Preset Standard ist store_stitch an und collect_sessions aus; das Preset Minimal schaltet beide aus.

• store_stitch. An speichert den am Edge abgeleiteten stitch für Unique-Visitor-Zahlen und besucherbezogene Metriken (Bounce-Rate, Seiten pro Besuch, Verweildauer). Aus lässt die Zeile vollständig anonym.
• collect_sessions. An schreibt die tab-gebundene sessionStorage-Session-ID für seitenübergreifende Journeys und Funnels. Aus fasst das ausgelieferte Bundle sessionStorage gar nicht erst an.

NEL-ReportsCopy Anchor Link

Schickt eine Site die NEL-Header, entsteht für jeden fehlgeschlagenen Request, den ein Chromium-Browser meldet, eine Zeile. Die Header setzt du, und die Policy bleibt max_age Sekunden im Browser des Besuchers.

• Gespeichert: Fehlertyp, Phase, HTTP-Status, Dauer, Methode, Protokoll, die fehlgeschlagene URL, gekürzt wie eine Seiten-URL, und der Referrer nur, wenn er auf demselben Host liegt.
• Serveradresse: server_ip ist die Adresse deines Servers, nicht die des Besuchers. Gespeichert wird nur eine öffentliche, eine private, Loopback- oder Link-Local-Adresse bleibt leer.
• Besucher: der Edge-stitch unter store_stitch und dieselben Labels für Land, Gerät, Browser, OS und Bots wie bei einem Seitenaufruf.
• Verworfen: der User-Agent aus dem Report und jeder Referrer von einem anderen Host.

CSP-ReportsCopy Anchor Link

Nennt die Content Security Policy einer Site fastmon, entsteht für jeden unterschiedlichen Verstoß, den der Browser meldet, eine Zeile.

• Gespeichert: Disposition, Direktive, die blockierte und die auslösende URL als Schema, Host und Pfad, Zeile und Spalte, die Seiten-URL, gekürzt wie bei einem Seitenaufruf, der HTTP-Status der Seite und die Policy mit geleerten Nonces.
• Besucher: der Edge-stitch unter store_stitch und dieselben Labels für Land, Gerät, Browser, OS und Bots wie bei einem Seitenaufruf.
• Verworfen: das Code-Sample von 'report-sample', ungelesen und in jedem Modus, der Inhalt einer data:- oder blob:-URL, Reports, die Browser-Erweiterungen auslösen, und jeder Referrer von einem anderen Host.

Event-PropertiesCopy Anchor Link

Ein Shop kann eigene Events senden, jedes ein Name mit bis zu 30 Properties. Personenbezogene Daten gehören weder in Namen noch in Properties, und dafür bist du verantwortlich.

• Im Browser maskiert: Enthält ein Key user, customer, email, mail, phone, password oder token, geht sein Wert als [masked] raus, egal welche Einstellung ihn listet.
• Im Browser ersetzt: Eine E-Mail-Adresse in einem Wert wird zu [email]. Der Collector macht das noch einmal für Events aus anderen Quellen.
• Vom Collector verworfen: jeder Key mit einem Wort wie email, user, phone oder token und jeder Key mit einem @.
• Mitgespeichert: die Seiten-URL, gekürzt wie bei einem Seitenaufruf, und dieselben Besucher-Labels wie bei einem Seitenaufruf.

Suchbegriffe der Site-SucheCopy Anchor Link

Auf einer Seite vom Typ search behält die gespeicherte URL den Wert von q, search und searchparam, gekürzt auf 64 Zeichen. Eine Seite vom Typ category behält searchparam, das OXID für sein Filterformular nutzt. Das gilt in jedem Modus, auch in anonymous, ohne Opt-in und ohne Opt-out. Auf allen anderen Seiten fallen diese Werte weg.

Site-Metadaten vs. BesucherdatenCopy Anchor Link

Eine Handvoll Felder beschreibt die Site des Kunden, nicht den Besucher: welche Third-Party-Domains die Seite lädt, der Byte-Mix nach Script / Image / Font, die Origin des LCP-Bilds, die LoAF-Script-Pfade. Diese Werte sind über alle Besucher derselben Seite identisch.

Das macht sie zu Site-Konfiguration, nicht zu Besucherdaten, und die Consent- und Verknüpfbarkeits-Regler betreffen sie nicht.

Personenbezogene Daten: was ausgeschlossen ist, und was nichtCopy Anchor Link

• Keine personenbezogenen Daten, in jeder Konfiguration. Web Vitals und alle Timings, Resource-/LoAF-/Third-Party-Metadaten, Device-/Connection-/Viewport-Buckets, der zweistellige Ländercode sowie Fehlertyp + Count. Keine IP, kein roher User-Agent, kein Fingerprint wird je gespeichert. Auf dem Preset Minimal trägt die gespeicherte Zeile gar keinen Besucher-Identifier.
• Nicht vollständig auszuschließen; wir minimieren, der Rest liegt bei dir. Der am Edge abgeleitete stitch (unter dem Preset Standard an) ist konstruktionsbedingt pseudonymes personenbezogenes Datum. URL- und Fetch/XHR-Pfade werden bereinigt (Query, Fragment und Werte gestrippt), aber ein Segment, das du aus personenbezogenen Daten baust (/orders/jane-doe), übersteht das. Fehler-Messages (collect_error_messages) laufen durch einen Scrubber, der gemusterte PII maskiert, aber nicht jeden Freitext-Leak fängt. Und alles, was du aktiv einschaltest: ein allow-gelisteter collect_query_values_for-Wert oder die collect_sessions-ID. Für diese Fälle greifen deine Pflichten unten.

Was deine Einstellungen ändernCopy Anchor Link

Die Tracker-Einstellungen der Site entscheiden über Verknüpfbarkeit und Content-Tiefe, nicht über die Privacy-Untergrenze. Die Untergrenze oben (keine IP-Speicherung, kein roher User-Agent, keine Fingerprints, keine Cookies) gilt in jeder Konfiguration. Was die Einstellungen bewegen: ob Session-ID, Fehler-Message, Fehler-Frame-Detail, Query-Keys oder Fetch/XHR-Telemetrie vorhanden sind und ob der Edge-stitch gespeichert wird. Die Aufschlüsselung pro Einstellung steht unter Tracker-Einstellungen, die drei Ausgangspunkte unter Presets.

Consent und TDDDGCopy Anchor Link

Ob das Einbinden von fastmon eine Einwilligung erfordert, wer verantwortlich ist und die zwei Auslegungen sind vollständig unter Tracker-Einstellungen → Consent und TDDDG beschrieben.

Wo die Daten liegenCopy Anchor Link

• Nur EU, keine US-Jurisdiktion. Alle Daten werden ausschließlich in der EU verarbeitet und gespeichert, auf in Deutschland betriebener Infrastruktur. Jeder Anbieter im Datenpfad ist ein deutsches oder EU-Unternehmen: kein Cloudflare, kein AWS, kein GCP, kein Vercel, kein US-eigener Subprozessor.
• Verantwortlich. Verarbeitet wird von fastmon, der Firma hinter dem Produkt. Im AVV stehen alle Sub-Auftragsverarbeiter, den schicken wir auf Anfrage.
• Retention. Per Default 90 Tage. Einstellbar an der Application, für alle ihre Sites (data_retention_days). Was abläuft, wird weggeworfen, nicht archiviert.

VergleichCopy Anchor Link

Wenn du von einem US-Analytics-Produkt umsteigst, hier das relevante Delta:

Deine VerantwortungCopy Anchor Link

Der Tracker garantiert die Wire-Form. Diese Punkte bleiben bei dir:

• Keine PII in URL-Pfaden. Query-Strings und Hash-Fragmente werden entfernt, der Pathname bleibt erhalten. /orders/jane.doe@x.com würde die E-Mail in unsere Pipeline tragen. Nutze opake IDs (UUIDs, numerische DB-IDs) oder bring PII in Query-Parameter, die ohnehin gestrippt werden.
• Nenne Suchbegriffe in deiner Datenschutzerklärung. Besucher können personenbezogene Daten in ein Suchfeld tippen, und fastmon behält den Begriff.
• Keine PII in UTM-Parametern. UTM-Tags und Click-ID-Labels landen wortwörtlich aus den Outbound-URLs der Marketer in der Datenbank. Pack da keine Besucher-PII rein. Bau Kampagnen-URLs niemals als ?utm_term=jane@example.com&utm_content=user-12345 für Per-Empfänger-Tracking. Jedes Feld wird serverseitig auf 64 Zeichen gedeckelt, der Wert läuft aber nicht durch den Scrubber. Ad-Plattform-Click-ID-Werte verwirft der Tracker selbst, damit greift das Per-Empfänger-Join-Risiko nur bei den UTM-Feldern.
• Kein roher User-Input in throw. Der immer aktive Scrubber fängt gemusterte PII (URLs, E-Mails, IDs), aber freier Text (Namen, eigene Bezeichner) kann durchrutschen. Typisiere den Fehler: throw new EmailDeliveryError({ code: "..." }) statt throw new Error("Failed to send to " + email). Greift nur, wenn collect_error_messages an ist; sonst wird die Message ohnehin komplett verworfen.

Was das für dich heißtCopy Anchor Link

• Zwei Fragen, getrennt zu prüfen. Nach § 25 TDDDG hängt es am Preset: Minimal und Standard schreiben nichts auf das Gerät, Full schreibt eine Session-ID und braucht dafür eine Einwilligung. Nach DSGVO ist die Rechtsgrundlage die Interessenabwägung nach Art. 6 Abs. 1 lit. f, weil über den HTTP-Header eine IP-Adresse im Spiel ist. Die Bewertung für deinen Einsatz bleibt deine (siehe Consent und TDDDG).
• Deine Daten verlassen die EU nie. Es gibt gar keinen US-Transfer, über den man nachdenken müsste.
• Deinem Team kannst du eine Ein-Seiter-Antwort geben: Link auf diese Seite plus unseren AVV, fertig.
• Explizites Opt-In vor jeder Session-Verknüpfung? Schalte collect_sessions an und lass session_consent auf deferred, sodass die Session-ID erst geschrieben wird, nachdem dein CMP grantConsent() aufruft.

Nächste SchritteCopy Anchor Link

• Tracker-Einstellungen und Presets ansehen.
• Technische Details zum Beacon.
• AVV gewünscht? Mail an support@fastmon.eu.