Tracker-Einstellungen

Jede Application hat eigene Tracker-Einstellungen: Sie legen fest, was das Beacon im Browser des Besuchers tut und was gespeichert wird. Jedes Verhalten ist ein einzelner Schalter, und ein Preset setzt diese Schalter auf einen sinnvollen Ausgangspunkt.

Die Einstellungen liegen an der Application und sind jederzeit umschaltbar. Der Script-Cache wird automatisch invalidiert; du deployst deine Website nicht neu und fasst das <script>-Tag nicht an. Eine ganz neue Application startet auf dem Preset Standard: Unique-Visitor-Analytics über den am Edge abgeleiteten stitch, Fetch/XHR- und Query-Key-Telemetrie und volle Fehler-Frames, und dabei nichts auf das Gerät des Besuchers geschrieben.

Diese Seite ist die Referenz, auf die das Dashboard verlinkt: jede Einstellung hat einen eigenen Abschnitt und einen stabilen Anker. Jeder Abschnitt endet mit einer PII-Zeile, einer kurzen Einschätzung, was die Einstellung für personenbezogene Daten nach DSGVO und TDDDG bedeutet. Das rechtliche Gesamtbild steht unter Consent und TDDDG und auf der Privacy-Seite.

Presets

Ein Preset ist ein Ausgangspunkt, den du beim Anlegen einer Application wählst. Es setzt alle Datenschalter auf einmal; danach ist jeder Schalter unabhängig, und sobald du einen davon änderst, gilt sie als Custom. Neue Applications starten auf Standard. (Legst du eine Application direkt über die API ohne Preset an, greifen die nackten Feld-Defaults, die Minimal entsprechen.)

• Minimal erhebt nur Core-RUM: Web Vitals, Fehlertyp und -Count, Device- und Connection-Klasse. Keine Identifier, kein Content, kein Fetch/XHR. Nichts wird auf das Gerät des Besuchers geschrieben. Das ist die schlankste Position, das Opt-down, wenn du gar keinen Besucher-Identifier willst.
• Standard schaltet alles ein, was keine personenbezogenen Daten enthalten kann: das am Edge abgeleitete stitch-Besuchersignal, Fetch/XHR-Aggregate, Query-Schlüsselnamen und volle Fehler-Stack-Frames. Weiterhin kein Fehlermessage-Text, keine Query-Werte, keine geschriebene Session-ID. Immer noch nichts auf dem Gerät. Darauf startet eine neue Application, denn diese Daten (eindeutige Besucher, Fetch/XHR- und Fehler-Diagnose) bringen einen erheblichen analytischen Mehrwert.
• Full schaltet alles ein: eine beim Load geschriebene Session-ID, Fehlermessages und volle Frames, Query-Keys. Es ist das einzige Preset, das auf das Gerät schreibt (sessionStorage._fms), setzt also voraus, dass du Consent geklärt hast.

collect_query_values_for sowie die Routing-, Retention- und Verwaltungseinstellungen gehören zu keinem Preset; sie haben eigene Defaults und werden an der Application gesetzt.

Consent und TDDDG

Egal was eine Application erhebt: das Beacon greift auf dem Gerät des Besuchers lesend auf mehrere Browser-Schnittstellen zu:

• die Performance API (Navigation, Paint, Layout-Shift, Event- und Long-Animation-Frame-Timings) für Web Vitals und Timing,
• die Network Information API (navigator.connection) für die Connection-Klasse,
• die Viewport-Breite (window.innerWidth),
• die Error- und Unhandled-Rejection-Handler (Fehlertyp und -Count, in jeder Konfiguration erhoben).

fastmon setzt keine Cookies, in keiner Konfiguration. In der Standard-Konfiguration schreibt es nichts auf das Gerät des Besuchers; nur wenn collect_sessions an ist, schreibt es einen einzigen, tab-gebundenen sessionStorage-Eintrag (die Session-ID). Es speichert keinen langlebigen, seiten- oder geräteübergreifenden Identifikator; die Aggregation erfolgt am Edge.

Welche gespeicherten Felder personenbezogen sind und welche nicht, und wo sich ein Rest nicht vollständig ausschließen lässt, steht unter Privacy → Personenbezogene Daten.

Das Auslesen solcher Schnittstellen kann nach § 25 TDDDG und der ePrivacy-Richtlinie einwilligungsrelevant sein. Die Auslegungen reichen von großzügig (manche RUM-Anbieter halten das Auslesen dieser APIs für gar kein „Zugreifen auf Informationen" auf dem Endgerät, also keine Einwilligung) bis streng (Analyse und Performance-Monitoring sind nicht „unbedingt erforderlich", also einwilligungspflichtig). Deutschland und der EDPB (Leitlinien 2/2023) tendieren zur strengen Auslegung, strenger als die meisten anderen EU- und Nicht-EU-Länder, und im Zweifel gilt die strenge.

fastmon ist ein deutscher Anbieter, also gehen wir von der strengen Auslegung aus und bauen und dokumentieren konservativ. Die Einschätzung für deine Site ist aber nicht unsere: ob das Einbinden von fastmon eine Einwilligung erfordert, entscheidest du, am besten mit deinem Datenschutzbeauftragten oder deiner Rechtsberatung. Am besten betreibst du fastmon ohnehin unter deiner eigenen Domain (First-Party/1P); siehe collector_mode. Wenn du es hinter Consent legst, kategorisiere fastmon in deinem CMP als Analyse / Performance-Messung, nicht als „unbedingt erforderlich". Beachte: § 25 TDDDG (der Gerätezugriff) und die DSGVO (die anschließende Verarbeitung) werden parallel geprüft; die vertragliche Aufteilung steht in unserem AVV (§ 4) und den AGB (§ 7).

Wenn eine Application eine Session-ID schreibt (collect_sessions an), schaltet dein CMP den Gerät-Schreibvorgang nach Consent mit einem einzelnen Call frei:

// In your cookie banner's "Accept" callback, and on every page load
// while consent is granted (most consent managers do this for you):
window.fastmon && window.fastmon.grantConsent && window.fastmon.grantConsent();

grantConsent() vergibt die sessionStorage._fms-Session-ID und schaltet ab da die seitenübergreifende Verknüpfung frei. Ruf ihn bei jedem Seitenload auf, solange Consent besteht (die meisten Consent-Management-Plattformen tun das für dich). Die &&-Guards sind wichtig, weil das Beacon asynchron lädt: bei einer schnellen Navigation kann dein Consent-Code vor dem Skript laufen, wenn window.fastmon noch gar nicht existiert. Geguarded ist dieser frühe Aufruf ein harmloses No-op, und der Schreibvorgang passiert, sobald der Tracker geladen ist; ohne Guard würde der bare Aufruf einen TypeError werfen. Ob der Schreibvorgang auf diesen Call wartet oder beim Load passiert, entscheidet der Schalter session_consent. Es gibt keinen Widerruf mitten in der Session: die Session-ID liegt im sessionStorage und stirbt mit dem Tab, Ablehnen heißt also schlicht, dass der Schreibvorgang nie passiert.

Session und seitenübergreifende Verknüpfung

collect_sessions

Schreibt eine Session-ID (_fms) in den sessionStorage des Besuchers, sodass Pageviews desselben Besuchs verknüpfbar werden: seitenübergreifende Journeys, Funnels, Einstiegs- und Ausstiegsseiten, Wiederkehr innerhalb der Session. Die ID liegt im sessionStorage und stirbt beim Schließen des Tabs. Sie ist das Einzige, was das Beacon je auf das Gerät schreibt; aus rührt das ausgelieferte Bundle den sessionStorage gar nicht erst an (der Schreibschritt wird herauskompiliert, nicht nur serverseitig verworfen), und der Collector erzwingt zur Absicherung eine leere Session-ID. Aus auf dem Standard-Preset, mit dem neue Applications starten; das Preset Full schaltet sie an.

PII: die Session-ID ist ein Besucher-Identifier, und ihr Schreiben ist der eine § 25 Abs. 1 TDDDG Speichervorgang, den das Beacon ausführt, also einwilligungsrelevant. Für die schlankste Position aus lassen, oder mit session_consent kombinieren, um erst nach Opt-In zu schreiben. Aus getragen enthält eine Zeile keinen Identifier auf dem Gerät.

session_consent

Entscheidet, wann die Session-ID geschrieben wird, und ist nur relevant, wenn collect_sessions an ist. Auf deferred (das Dashboard zeigt das als Session-ID erst nach Consent schreiben) wird der Schreibvorgang aufgeschoben, bis dein CMP window.fastmon.grantConsent() aufruft; bis dahin fließen Beacons weiter, nur ohne Session-ID. Auf immediate wird die ID beim Pageload geschrieben. Reads, Observer und Beacons laufen in beiden Fällen: dieser Schalter gatet nur den Gerät-Schreibvorgang, nie die Erhebung. Default deferred.

PII: das ändert Zeitpunkt und Consent-Posture des Session-Schreibens, nicht die erhobenen Datenkategorien. deferred ist der sichere Default (kein Gerät-Schreiben vor Consent); immediate schreibt beim Load und setzt voraus, dass du dafür eine Rechtsgrundlage hast.

store_stitch

Behält das am Edge abgeleitete stitch-Signal auf der gespeicherten Zeile. stitch ist ein HMAC-SHA256 aus IP, User-Agent, dem Collector-Hash der Application und der Domain, am Edge berechnet unter einem Salt, das alle 24 Stunden rotiert und den Edge-Speicher nie verlässt. Es liefert dir Unique-Visitor-Counts und besucherbezogene Metriken (Bounce Rate, Seiten pro Besuch, Verweildauer), ohne dass etwas auf dem Gerät liegt. Aus erzwingt der Collector stitch beim Insert leer, sodass die Zeile gar keinen Besucher-Identifier trägt. Per-Domain-Default: Eine Site erbt den Wert der Application, solange sie keinen eigenen setzt. An per Default: das Standard-Preset, mit dem neue Applications starten, speichert es. Die vollständige Konstruktion (Forward Secrecy, ≤24 h Verknüpfbarkeit, Scope pro Application) steht unter Privacy → der am Edge abgeleitete stitch.

PII: stitch ist ein pseudonymer Besucher-Identifier und damit personenbezogenes Datum, verarbeitet nach Art. 6 Abs. 1 lit. f DSGVO mit dokumentierter Interessenabwägung; die Verknüpfbarkeit ist auf rund 24 Stunden begrenzt und nach Salt-Rotation forward-secret. Ihn in deiner Datenschutzerklärung zu benennen, ist Sache des Betreibers.

count_visitors_by

Wählt, nach welchem Identifier das Dashboard eindeutige Besucher zählt, stitch oder session. Reine Reporting-Vorgabe, getrennt von den Erhebungsschaltern, und der Query-Resolver klemmt sie auf das, was die Site tatsächlich speichert (ein Override pro Query ist immer möglich). Default stitch. Per-Domain-Default; eine Site kann ihn überschreiben.

PII: keine eigene. Sie wählt zwischen bereits über store_stitch und collect_sessions erhobenen Identifiern; sie erhebt und speichert nichts Neues.

URLs und Query-Parameter

collect_query_keys

Behält die Namen der Query-Parameter der Seiten-URL (etwa ?page, ?variant), sodass du Analytics nach parametrisierten Routen aufschlüsseln kannst. Parameter-Werte werden bei der Erhebung immer verworfen, unabhängig von diesem Schalter. Aus verwirft die Query-Strings komplett und speichert nur Origin plus Pfad. An per Default (Teil des Standard-Presets).

PII: gering. Nur Schlüsselnamen bleiben, und die tragen selten besucherspezifische Daten; jeder Wert wird gestrippt, bevor die URL den Browser verlässt. Um einen konkreten Wert zu behalten, musst du ihn explizit über collect_query_values_for freigeben. Ein fester Satz an Ad-Attribution- und Click-ID-Parametern (gclid, gbraid, wbraid, msclkid, fbclid sowie die utm_*- und gad_*-Familien) wird unabhängig von diesem Schalter immer verworfen, Schlüssel und Wert, auf Seiten-URLs wie auf Fetch/XHR-Pfaden: Sie tragen kein Routing-Signal, und ihr Schlüsselsatz ändert sich pro eingehendem Link. Nennst du einen davon in collect_query_values_for, überschreibt das die Regel und der Parameter bleibt.

collect_query_values_for

Eine Opt-in-Allow-List (max. 20 Einträge) von Parameternamen, deren Wert zusätzlich behalten wird, längenbegrenzt. Alles, was nicht auf der Liste steht, verliert seinen Wert weiterhin. Setzt collect_query_keys voraus. Typische Einträge sind nicht-personenbezogene Routing- oder Kampagnenparameter wie page, variant, utm_campaign. Default leer. Nicht Teil eines Presets.

PII: die trägst du. Ein Wert wird nur für exakt die Schlüssel gespeichert, die du auflistest, und nie „alle Werte". Wenn du einen Parameter auflistest, der personenbezogene Daten trägt (eine E-Mail, eine User-ID, ein Token), hast du dich entschieden, ihn zu speichern, halte die Liste also auf nicht-personenbezogene Schlüssel.

Fehler

collect_error_messages

Behält den freien Fehlermessage-Text (Cannot read property 'x' of undefined) statt nur Fehlertyp und -Count. Aus wird die Message serverseitig verworfen, und Dashboards sehen Aggregate wie „5 TypeErrors, 2 ReferenceErrors" plus Stack-Positionen. Aus per Default, auch auf Standard; das Preset Full schaltet es an.

PII: der höchste Freitext-Vektor für personenbezogene Daten im Beacon, weil Messages Nutzereingaben enthalten können. Einwilligungsrelevant (ein „consent-only"-Feld). Ein stets aktiver Scrubber ersetzt URLs, E-Mails, numerische IDs und Strings in Anführungszeichen durch * vor dem Versand, auch wenn die Message behalten wird, aber das ist Defense-in-Depth: die Betreiberpflicht, keine rohen Nutzereingaben in geworfene Fehler zu geben, bleibt bestehen. Nur dort einschalten, wo du Consent geklärt hast.

collect_error_frames

Behält volles Stack-Frame-Detail (Script-Pfad plus Zeile und Spalte) für jeden Frame. Aus fallen Frames auf host-only zusammen, außer deine eigenen First-Party-External-Scripts behalten immer Pfad und Zeile/Spalte, damit Bugs im eigenen Code fixbar bleiben. An per Default (das Preset Standard schaltet es an).

PII: eine Code-Position identifiziert den Bug, nicht den Besucher, und sie ist für alle identisch, die ihn treffen, also gilt First-Party-Eigencode-Detail als immer sendbar (sanitisiert auf Origin plus Pfad, ohne Query oder Hash). Volles Detail für Inline- und Third-Party-Frames ist einwilligungsrelevant, weil Zeilennummern in serverseitig personalisiertem HTML sich prinzipiell pro Besucher verschieben könnten, die bleiben also gegatet. Pfade darf der Betreiber nicht mit Identifikatoren bestücken, genau wie Seiten-URLs.

Fetch und XHR

collect_fetch_xhr

Erfasst aggregierte Fetch/XHR-Telemetrie: Aufruf-Counts pro Endpunkt, Dauern, Fehler-Statuscodes und die langsamsten Ausreißer, sodass du siehst, welche deiner eigenen APIs langsam sind oder fehlschlagen. Wird beim Rendern ins ausgelieferte Bundle gebacken. Aus unterdrückt die Fetch/XHR-Erhebung komplett, inklusive des Wrappers. An per Default (das Preset Standard schaltet es an).

PII: Endpunkt-Pfade werden genau wie die Seiten-URL sanitisiert (Query, Fragment und Matrix-Params gestrippt; ID-artige Segmente auf :id templatisiert), und zwar strenger als Seiten-URLs. Zusätzlich zu den Seiten-URL-Regeln templatisiert der Collector Fetch/XHR-Pfade serverseitig nach, damit das Aggregat lesbar bleibt: Lange Content-Slugs klappen auf :slug, opake Tokens auf :id, Soft-Navigation-Dokument-Fetches auf /:page, und ein Third-Party-Host behält seine Endpoint-Zeile, verliert aber die Query komplett. Die Zähler sind aggregierte Zahlen, und der Ziel-Host ist Site-Metadaten (welche deiner APIs, nicht wer sie aufgerufen hat). Das eine Restrisiko ist ein alphabetisches Pfadsegment wie /users/jane-doe, das die Templatisierung übersteht, dieselbe Betreiberpflicht wie bei Seiten-URLs: keine personenbezogenen Daten in Pfade.

Page-Type

pagetype_ruleset

Ordnet jeden Pageview in einen Page-Type ein (Product, Category, Cart, Checkout und so weiter), für Shop-Systeme, indem die Body-Controller-Klasse des Shop-Frameworks gelesen wird. Standardmäßig aus (""), dann wird nichts aus dem DOM gelesen. Setz es auf eine eingebaute Ruleset (shopware6, shopware5, oxid, magento, woocommerce), und der Tracker extrahiert nur den Page-Controller-Token des Frameworks (etwa is-ctl-product), den der Collector auf die Page-Type-Kategorie mappt. Ein Server-Timing: pageType-Header hat, falls du einen sendest, immer Vorrang. Pro Site, und auch auf org-weiten Trackern verfügbar. Siehe Server-Timing → Page-Type.

PII: das Einzige, was aus dem DOM gelesen wird, ist ein einzelner Framework-Klassen-Token, gematcht über ein ruleset-spezifisches Muster; nie das volle class-Attribut, nie Seiteninhalt oder Formularwerte, und die rohe Klasse verlässt den Browser nie. Aus ist der Default, eine Site entscheidet sich also bewusst für diesen einen DOM-Read.

Was jede Ruleset erkennt

Jede Ruleset mappt den Page-Controller-Token des Frameworks auf einen aus einem festen Satz von Page-Types (home, product, category, cart, checkout, search, account). Tokens außerhalb dieser Tabelle mappen auf nichts, und der Pageview behält einen leeren Page-Type. Das Mapping liegt im Collector, verbessert sich also ohne erneutes Ausrollen des browser-gecachten Trackers.

¹ Das Shopware-5-Markup ist vorläufig und wird noch gegen Produktiv-Shops verifiziert. ² WooCommerce nutzt für Home- und Suchseiten generische WordPress-Klassen, die zu breit sind, um sie zuverlässig zu typisieren, also bleiben sie untypisiert. ³ Shopware teilt sich einen Controller-Token über Warenkorb- und Bestätigungsschritt, daher melden beide das gröbere cart statt eines geratenen checkout.

Ingest und Routing

site_policy

Entscheidet, was passiert, wenn ein Beacon von einem Hostnamen kommt, der keine registrierte Site dieser Application ist. open (der Default) verwirft das Beacon, vermerkt den Hostnamen aber als vorgeschlagene Domain, die du mit einem Klick adoptierst; auto legt dafür eine Site an und behält ihren Traffic ab dann; strict verwirft ohne Vorschlag und ohne Auto-Provisioning, sodass nur exakt registrierte Domains bedient werden. Wird an der Application gesetzt.

Das ersetzt die frühere allowed_origins-Allow-List und den per-Site-Schalter enforce_domain_match, die es beide nicht mehr gibt: Abgeglichen wird jetzt der gemeldete Seiten-URL-Host statt des Origin-Headers, den sendBeacon oft weglässt. Mit strict nagelst du den Ingest auf explizit registrierte Domains fest.

PII: keine. Das ist Ingest-Härtung, kein Datenerhebungsschalter.

collector_mode

Wohin das Beacon seine Daten POSTet: default (fastmons geteilter Collector), custom (ein expliziter Endpunkt, den du hostest oder routest, gesetzt in collector_endpoint) oder relative (ein host-loses same-origin /c/<hash>, natürlich, wenn du den Collector von deiner eigenen Domain ausliefern lässt). Default default.

PII: für sich keine. Es ist eine Routing-Wahl. Beachte, dass ein Same-Origin- oder Custom-Endpunkt den Netzwerkpfad des Requests ändert, was für deinen eigenen Consent und die First-Party-Einordnung relevant sein kann, aber es ändert nicht, was das Beacon erhebt.

collector_endpoint

Die absolute Collector-Basis-URL, nur genutzt, wenn collector_mode custom ist (etwa metrics.example.com). Muss für custom gesetzt und sonst leer sein. Default leer.

PII: keine. Nur Endpunkt-Konfiguration.

data_retention_days

Wie lange rohe Beacon-Zeilen gehalten werden, bevor die Speicherschicht sie verwirft: 30, 60, 90, 180 oder 365 Tage. Default 90. Aggregate, die im Fenster berechnet wurden, bleiben; die rohen Zeilen werden bei Ablauf automatisch gelöscht.

PII: das ist dein Hebel zur Speicherbegrenzung. Kürzere Retention ist strenger; wähle das kürzeste Fenster, das dir noch den Vergleich über deine Deploy-Zyklen erlaubt.

Site-Verwaltung

tags

Freie Labels (max. 10) zum Gruppieren verwandter Sites, etwa env:production oder team:growth. Heute nur Labels; ein seitenübergreifender Analytics-Scope, der über jede Site mit einem Tag zusammen berichtet, ist geplant. Siehe Sites → Tags.

PII: keine. Site-Konfiguration, keine Besucherdaten.

is_active

Aus werden Beacons weiterhin angenommen, aber nicht in die Analytics-Tabellen geschrieben, sodass du die Historie der Site behältst, während du neuen Ingest pausierst. Für Pausen nutzen, nicht zum Kürzen der Retention. Default an.

PII: keine. Es gatet Schreibvorgänge, nicht Datenkategorien.

environment

Markiert die Application als prod oder dev. Default prod. Nutze dev, um Staging-, Preview- oder Wegwerf-Applications klar von deinem Produktions-Traffic zu trennen.

PII: keine. Es beschriftet die Application und erhebt nichts.

source_version

Pinnt die Beacon-Template-Version, die die Application ausliefert (v1 ist aktuell). Auf der aktuellen Version lassen, außer du hältst eine Application während eines Beacon-Upgrades bewusst zurück.

PII: keine. Es wählt, welcher Tracker-Build ausgeliefert wird.

Applications und Sites

Diese Einstellungen liegen an der Application, also am Tracking-Embed selbst, nicht an einer einzelnen Domain. Eine Application besitzt das ausgelieferte Bundle, die zwei Hashes und jeden Schalter auf dieser Seite, und sie bedient eine Domain oder zwanzig: Jede Domain ist eine Site mit eigenem Dashboard und eigenem Traffic. Einen separaten „org-weiten Tracker" gibt es nicht mehr; eine Application mit mehreren Sites ist genau das. Siehe Applications.

Drei Einstellungen sind Per-Domain-Defaults statt fester Application-Werte: data_retention_days, store_stitch und count_visitors_by. Eine Site erbt den Wert der Application, solange sie keinen eigenen setzt.

Einstellungen ändern

Site in fastmon öffnen, auf Einstellungen, ändern, was du brauchst, und speichern. Die Änderung greift, sobald der Script-Cache rolliert: für aktive Besucher meist binnen Minuten, für neue Sessions sofort. Du deployst deine Website nicht neu und änderst das <script>-Tag nicht.

Nächste Schritte

• Applications: der Embed, an dem diese Einstellungen liegen, und wie er zu Sites steht.
• Privacy: Was wir nicht sammeln: die Datenschutz-Untergrenze, die unter jeder Einstellung gilt.
• Der RUM-Beacon: was das Beacon genau schickt.
• Sites: die Domains unter einer Application und ihre Per-Domain-Overrides.