Diese Dokumentation entsteht gerade: einzelne Seiten können noch unvollständig oder stellenweise ungenau sein.
fastmon Docs
Implementierung

Tracking-Code einbinden

fastmon mit einem einzigen Script-Tag einbinden. Fünf Minuten vom Signup bis zum ersten Datenpunkt.

Ein <script>-Tag im <head>, das ist die ganze Einrichtung. Das läuft überall, wo du ein Script einfügen kannst: statisches HTML, eine React- oder Vue-App, Hugo, Next.js, WordPress, ein Tag-Manager.

Zeit bis zum ersten Datenpunkt: etwa fünf Minuten. Du brauchst: Zugriff auf das HTML deiner Seite und einen fastmon-Account.

Dein Snippet

Aus der App geöffnet stehen hier die echten Werte deiner Application. Sonst trage sie hier ein, dann aktualisieren sich alle Snippets auf dieser Seite.

Beide Hashes findest du in der App unter Applications → ··· → IDs & Hashes.

Applications und Sites

Hast du diese Seite über den Einrichten-Button einer Application geöffnet, existiert die Application bereits und die Hashes oben sind ausgefüllt. Dann spring direkt zu Schritt 1.

Sonst leg zuerst eine an. Eine Application ist ein Tracking-Snippet. Ihr gehören die Erfassungseinstellungen und die beiden Hashes unten, und sie kann eine Domain bedienen oder zwanzig.

Öffne in fastmon Applications und klicke auf Add. Gib einen Namen und die Domain an, die du messen willst (nur der Hostname, ohne Protokoll: acme.com). Fastmon legt die Application und ihre erste Site für diese Domain in einem Schritt an und gibt dir das Snippet.

Damit hat die Application zwei kurze Hashes:

  • source_hash: kommt in die Script-URL.
  • collector_hash: dorthin sendet der Tracker die Daten. Er ist fest ins Script eingebaut, du fasst ihn normalerweise nie von Hand an.

Beide findest du auf der Karte der Application unter ··· → IDs & Hashes.

Mehrere Domains mit einem Snippet? Füge sie als weitere Sites derselben Application hinzu. Jede Site behält ihr eigenes Dashboard und ihren eigenen Traffic, aber sie teilen sich ein Snippet und eine Erfassungskonfiguration. Eine zweite Application brauchst du erst, wenn eine Domain wirklich andere Einstellungen benötigt.

1. Tracker-Tag einbauen

Dieses eine Tag ist die komplette Pflicht-Einrichtung. Füge es in den <head> jeder Seite ein, die du messen willst:

<script defer src="https://fastmon.site/s/{source_hash}.js"></script>

Das Tag nutzt defer: Es lädt parallel zum HTML-Parsing, blockiert den Parser nie und läuft in Quellreihenfolge, sobald das DOM geparst ist. async würde ebenfalls nicht blockieren, kann das Parsing aber unterbrechen, sobald der Download fertig ist, und die Reihenfolge mehrerer async-Scripts ist zufällig. Für Web Vitals wollen wir vorhersagbares Timing, also gewinnt defer.

(Die Reihenfolge der Attribute im Tag ist dem Browser egal: <script defer src="…"> und <script src="…" defer> verhalten sich identisch. Wir schreiben defer zuerst, damit es zu dem passt, was dir die App ausgibt.)

Die Platzierung ist nicht kritisch, aber <head> ist die bessere Wahl: So erwischt der Tracker den allerersten Paint.

Wohin damit

SeitentypTag einbauen in…
Reines HTML / Hugo / Jekyll<head> deines Basis-Templates.
WordPressEin Header-Snippet-Plugin oder header.php.
Next.js / Nuxt / AstroDas Head/Script-Primitive des Frameworks (Next.js: <Script strategy="afterInteractive"> in app/layout.tsx).
Single-Page-AppsDie statische index.html-Hülle, einmal reicht.

2. Deployen und eine Seite laden

Deploye in die Umgebung, die du messen willst, und öffne irgendeine Seite.

Der Tracker registriert PerformanceObserver für Web Vitals, puffert Events im Speicher und schickt gebündelte POSTs über den Lebenszyklus des Seitenaufrufs: beim Laden, bei visibilitychange → hidden, bei pagehide und in periodischen Flushes. Erwarte einige Requests pro Seitenaufruf, nicht genau einen. Beim Testen erzwingst du einen Flush am zuverlässigsten, indem du den Tab wechselst oder die Seite schließt.

Danach prüfen, ob die Daten angekommen sind: siehe Einbindung prüfen.

Wenn die Domain noch keine Site ist

Beacons werden anhand des Hostnamens der Seite einer Site zugeordnet. Hast du die Domain beim Anlegen der Application angegeben, bist du fertig, die Daten landen auf dieser Site.

Falls nicht (du hast eine leere Application angelegt oder das Snippet gerade auf eine zusätzliche Domain gesetzt), wird der erste Seitenaufruf nicht still verworfen: Der Hostname taucht an der Application als vorgeschlagene Domain auf, und du fügst ihn mit einem Klick als Site hinzu. Beacons von vor dem Hinzufügen werden nicht aufbewahrt, die Zahlen starten also ab dem Moment, in dem du sie hinzufügst.

Was davon passiert, steuert die Einstellung Unbekannte Domains der Application:

EinstellungWas bei einem Beacon von einer nicht registrierten Domain passiert
Vorschlagen (Standard)Wird als vorgeschlagene Domain zum Hinzufügen gelistet, der Beacon selbst wird verworfen.
Automatisch anlegenBeim ersten Beacon wird automatisch eine Site angelegt.
IgnorierenWird still verworfen, kein Vorschlag, keine Site.

Einwilligung: wann die Session-ID geschrieben wird

Wenn deine Application eine Session-ID speichert und die Einwilligungsstufe auf dem Standard (off) steht, schreibt der Tracker die Session-ID nicht, bis du ihm sagst, dass eingewilligt wurde. Ruf das im Accept-Handler deines Cookie-Banners auf, und bei jedem Seitenaufruf, solange die Einwilligung gilt:

// 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();

Ohne diesen Aufruf misst der Tracker weiterhin Web Vitals und Seitenaufrufe, er fügt sie nur nicht zu seitenübergreifenden Sessions zusammen. Wenn deine Application gar keine Session-ID speichert, fasst das ausgelieferte Bundle den Storage nie an und es gibt nichts zu steuern.

Was erhoben wird und was nicht, steht unter Datenschutz.

Optionale Ergänzungen

Beide brauchst du nicht, damit Daten fließen. Ergänze sie, wenn das Tracker-Tag steht und funktioniert.

Fehler abfangen, die vor dem Tracker auftreten

Ein deferred Script startet erst, wenn das DOM geparst ist. Ein JavaScript-Fehler beim frühen Parsing passiert also, bevor fastmon zuhört. Dieses kleine Inline-Snippet sammelt solche Fehler und übergibt sie, sobald der Tracker startet.

Das funktioniert nur über dem Tracker-Tag aus Schritt 1, es gehört also dorthin, ganz an den Anfang des <head>:

<script>  window.__fastmon = window.__fastmon || { q: [] };  (function (q) {    function h(k) {      return function (e) {        q.push([k, e, Date.now()]);      };    }    addEventListener("error", h("e"), true);    addEventListener("unhandledrejection", h("r"));  })(window.__fastmon.q);</script>

Lass es weg, wenn dir die ersten paar hundert Millisekunden Fehlerabdeckung egal sind.

Besucher ohne JavaScript zählen

Ein <noscript>-Pixel erfasst einen Seitenaufruf für Besucher mit deaktiviertem JavaScript. Es liefert keine Web Vitals (es gibt kein JS, das sie messen könnte), nur den Seitenaufruf. Es kann überall im <head> nach dem Tracker-Tag stehen:

<noscript><img src="https://fastmon.site/c/{collector_hash}.gif" alt="" width="1" height="1" referrerpolicy="no-referrer-when-downgrade" /></noscript>

Wohin die Beacons gehen

Die Collector-Einstellung der Application bestimmt den Host im Snippet oben.

fastmon (Standard)

Script und Beacons laden von fastmon.site. Nichts zu konfigurieren. Aus Sicht deiner Seite ist das Third-Party, ein strikter Content-Blocker kann es also blockieren.

Gleiche Origin (relativ)

Empfohlen, wenn du einen Reverse-Proxy vor deine Seite setzen kannst.

Das Snippet nutzt hostlose Pfade (/s/…, /c/…), Script und Beacons kommen also von deiner Domain. Sie sind First-Party und nicht von deinen eigenen Ressourcen zu unterscheiden, Content-Blocker entfernen sie also nicht und deine Besuchszahlen bleiben vollständig. Dafür proxyst du die beiden Pfad-Präfixe zu fastmon. Für nginx:

location ~ ^/(s|c)/ {    proxy_pass https://fastmon.site;    proxy_set_header Host fastmon.site;    proxy_set_header X-Forwarded-For $remote_addr;}

Jeder Reverse-Proxy oder CDN funktioniert genauso: /s/ und /c/ an https://fastmon.site weiterleiten und den Client-IP-Header beibehalten.

Smoxy

Läuft deine Site hinter Smoxy, sind es zwei Schritte im Dashboard, ganz ohne Config-Datei.

  1. fastmon als Origin anlegen. Unter Backends in deiner Organisation auf Origin hinzufügen klicken und ausfüllen: Name fastmon, Protokoll https, Adresse fastmon.site, Port 443.
  2. Die beiden Präfixe dorthin routen. Unter Regeln eine Conditional Rule anlegen, deren Bedingung URI Entspricht ^/(s|c)/ lautet, dann im Tab Einstellungen der Regel unter Routing den Origin fastmon auswählen.

Alles andere an der Zone behält seinen normalen Origin; nur /s/ und /c/ gehen zu fastmon. Passende Regeln stapeln sich, setz stop also nur, wenn du die nachfolgenden Regeln bewusst überspringen willst.

Eigene Domain

Derselbe First-Party-Vorteil, aber das Snippet zeigt auf einen Collector-Host, den du kontrollierst (metrics.example.com), statt auf relative Pfade. Praktisch, wenn eine Application mehrere Domains umfasst und du einen einzigen stabilen Collector-Host willst.

Wie es weitergeht

On this page