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
| Seitentyp | Tag einbauen in… |
|---|---|
| Reines HTML / Hugo / Jekyll | <head> deines Basis-Templates. |
| WordPress | Ein Header-Snippet-Plugin oder header.php. |
| Next.js / Nuxt / Astro | Das Head/Script-Primitive des Frameworks (Next.js: <Script strategy="afterInteractive"> in app/layout.tsx). |
| Single-Page-Apps | Die 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:
| Einstellung | Was 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 anlegen | Beim ersten Beacon wird automatisch eine Site angelegt. |
| Ignorieren | Wird 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.
- fastmon als Origin anlegen. Unter Backends in deiner
Organisation auf Origin hinzufügen klicken und ausfüllen:
Name
fastmon, Protokollhttps, Adressefastmon.site, Port443. - 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 Originfastmonauswä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
- Einbindung prüfen: ein Fünf-Sekunden-Check in den DevTools.
- Erfassung feinjustieren: Presets.
- Datenschutz: was wir nicht erheben, praktisch für die Rechtsabteilung.
- Deploys für Vorher/Nachher-Vergleiche markieren: Releases vergleichen.