Changelog

Die Fehlerrate hieß „Anteil der Pageviews mit mindestens einem Fehler" und zählte jedes fehlgeschlagene Bild, Skript und Stylesheet mit hinein. Der Server konnte nur die Hosts abziehen, die er aus einer Liste von rund 50 Trackern kannte, und Ad-Block-Listen tragen Zehntausende, also sahen Shops mit gesundem JavaScript Fehlerraten um 60 Prozent. Der Tracker zählt die beiden Populationen jetzt getrennt.

• Die Fehlerrate sind nur noch JavaScript-Fehler: der Anteil der Pageviews mit mindestens einer nicht abgefangenen Exception oder unbehandelten Rejection.
• Fehlgeschlagene Ressourcen sind ein eigenes Signal, mit eigener Rate (failed_resource_rate), eigener Kurve neben der Fehlerrate, eigenem Block am Ende der Fehlerseite und eigener Liste unter POST /analytics/failed-resources. Jede Zeile sagt, wessen Host es war, deiner oder ein fremder. Der MCP-Server hat get_failed_resources bekommen. Der Fehlertypen-Endpoint weist error_type: ["ResourceLoadError"] jetzt mit einem 400 ab, der dorthin verweist, denn eine leere Liste würde sich wie „du hast keine" lesen.
• Das Beacon schickt zwei sortierte Listen. Bis zu fünf JavaScript-Fehler, danach bis zu drei fehlgeschlagene Ressourcen, jeweils innerhalb des eigenen Kanals sortiert. So kann eine Seite voller kaputter Bilder keine echte Exception vom Draht drängen. Zwei Zähler, errc und frc, erfassen jedes Vorkommen und nicht nur die Einträge, die Platz finden.
• Eigene Subdomains zählen als eigene. First Party hieß bisher: exakt der Host der Seite. Ein Shop, der sein Bundle von cdn.shop.example ausliefert, bekam seine eigenen Fehler also einem Dritten zugeschrieben und hatte keinen Dateipfad zum Nachsehen. Die Regel ist jetzt die registrierbare Domain, an einer Stelle, für Fehlerrate, Fehler-Herkunft, Fetch/XHR-Split und Ressourcen-Liste gleichermaßen.
• Die Fetch/XHR-Fehlerrate folgt derselben Regel. Sie zählt Fehler auf deinen eigenen Hosts und weist Fehler auf fremden Hosts als eigene Zahl daneben aus. Bisher verließ ein geblockter Tracker-Aufruf die Rate nur, wenn sein Host zufällig auf unserer Liste stand.
• Drei Zahlen ändern am Deploy-Tag ihre Bedeutung. Die Fehlerrate, weil sie keine Ressourcen-Fehler mehr zählt. Die Fehler-Herkunft, weil ein eigener Frame irgendwo im Pageview ihn jetzt zu deinem macht, während ein Fehler, dessen Herkunft gar nicht bestimmbar ist, unzugeordnet bleibt statt gegen einen Dritten zu zählen. Und das First-Party-Flag an jedem Fehler, wegen der Subdomain-Regel. Ein Vergleich über diesen Tag hinweg vergleicht zwei Definitionen.
• Kein Backfill. Alte Beacons tragen Ressourcen-Fehler innerhalb des Fehlerzählers und höchstens fünf Fehler-Einträge, der Split lässt sich daraus also nicht rekonstruieren.

Doku: Analytics → Fehlgeschlagene Ressourcen, Tracker → Was als Fehler zählt.

Eine nicht abgefangene Exception in einem Skript aus einem anderen Origin, geladen ohne CORS-Opt-in, meldet der Browser als wortwörtliches Script error., ohne Dateiname, Zeile oder Error-Objekt. Der Tracker führte das als namenlosen Error mit einem leeren Frame, wo es einen Fingerprint mit jedem anderen Fehler ohne Frames teilte und nicht auseinanderzuhalten war. Über Produktions-Sites gemessen war das ein Sechstel aller JavaScript-Fehler.

• Es kommt als Typ ScriptError an. Bestehende Zeilen behalten ihren alten Fingerprint, der neue Name gilt also ab dem nächsten Tracker-Load, und ein Vergleich über den Rollout hinweg vergleicht zwei Gruppierungen.
• Auflösen lässt sich die Gruppe, indem du das Skript mit crossorigin="anonymous" von einem Host lädst, der Access-Control-Allow-Origin sendet. Dann meldet der Browser den echten Fehler. Setz das Attribut nicht auf einem Host ohne diesen Header, denn dann führt der Browser das Skript nicht aus.
• Das Breakdown nennt die Hosts, bei denen du nachsehen musst. Wo ScriptError-Zeilen vorkommen, listet POST /analytics/error-types zusätzlich own_subdomain_hosts: Hosts auf deiner eigenen Domain, außer dem Host der Seite, die im selben Zeitraum Skripte oder langsame Ressourcen ausgeliefert haben. Ein Hinweis aus den Hosts, die die Beacons zufällig gesehen haben, keine vollständige Liste.
• Die Fehlerrate zählt sie weiterhin mit, denn sie zählt per Definition jeden JavaScript-Fehler.

Doku: Tracker → Was als Fehler zählt.

Die Befehlspalette (Cmd/Ctrl+K) konnte nur die Sites der gerade gewählten Organisation anbieten. Eine Domain in einer anderen zu erreichen hieß: wissen, in welcher Organisation sie liegt, und vorher dorthin wechseln. Eine Agentur hatte keine Möglichkeit, eine Domain zu tippen und dort zu landen.

• Eine Suche über alles, was du erreichst: eigene Mitgliedschaften, die Kunden-Organisationen jeder Agentur, zu der du gehörst, und die Applikationen und Domains darin. Jeder Treffer trägt die Organisation, in der er liegt, und was du dort bist, ein Klick navigiert also direkt hin.
• Applikationen stehen zuerst, und eine Auswahl setzt den Applikations-Filter auf der Seite, auf der du bist, so wie eine Seite es schon immer getan hat. Bisher landete jede Auswahl in den Einstellungen der Applikation, egal wovon aus.
• Inaktive Sites und Applikationen werden gelistet und gekennzeichnet. Eine wieder zu aktivieren fängt damit an, sie zu finden. Inaktive Organisationen erscheinen nie.
• Dieselbe Suche für Skripte: GET /search, mit q (Teilstring, ohne Rücksicht auf Groß- und Kleinschreibung), kinds zum Einschränken und limit (maximal 50 pro Art). Ergebnisse kommen nach Art gruppiert, bester Treffer zuerst: exakter Name, dann Präfix, dann Teilstring, dann alphabetisch. Ein Key ist auf die Organisationen beschnitten, für die er ausgestellt wurde, und auf seine Scopes: ein Key ohne site:read bekommt keine Sites, welche Rolle sein Besitzer auch hat.

Doku: API → Search, Analytics → Navigieren mit dem Befehlsmenü.

Ein Durchgang über die ganze Seite, gezielt auf die Panels, die eine Zahl zeigten, ohne zu sagen, was sie zählt und wo es weitergeht.

• Zwei neue Panels. „Aktive Stunden" stellt Stunde des Tages gegen Wochentag, damit sichtbar wird, wann auf der Seite wirklich etwas passiert. „Engagement" zeigt den Anteil der Besucher mit nur einer Seite, darunter die Verteilung der Seiten pro Besucher mit Median. Bewusst keine Bounce-Rate: ob jemand danach gegangen ist, steht nicht in den Daten.
• Das Checkout-Panel ist ein Funnel statt vier Zahlen nebeneinander: eine Leiste je Stufe an gemeinsamer Kante, dazu der Anteil an der Stufe davor. Wo Leute abbrechen, war vorher nicht zu sehen.
• Jedes Breakdown-Panel erklärt sich selbst. Der Titel sagt, was es zählt, die Fußzeile sagt, wie viele Werte hinter den acht angezeigten Zeilen stecken, und „Alle anzeigen" führt in den Explorer und nimmt die Filter der Seite mit, samt Ausschlüssen, Metrik-Bereichen und Bot-Schaltern. Einzelne Zeilen öffnen sich dort ebenfalls, und ein Klick auf eine Zeile ergänzt ihren Wert in den Filtern statt die anderen zu verwerfen.
• Die Chart-Legende steht jetzt über dem Chart und schaltet Serien einzeln ein und aus. Bei ausgewählten Checkouts liegt der Warenkorb eine Größenordnung über den abgeschlossenen Käufen und hat die kleinere Serie in der gemeinsamen Skala verschwinden lassen. Jede Serie trägt jetzt ihren eigenen Vorperioden-Wert und ihren eigenen Schalter dafür.
• Neue Tabs: „Hosts" bei den Seiten, „Viewport" bei den Geräten, „Kampagne", „Ad-Plattform" und „UTM Medium" bei den Quellen. Die UTM-Tabs sagen außerdem, welcher Anteil der Pageviews den Parameter überhaupt trägt, denn eine Top-Liste des getaggten Traffics sagt nichts darüber, wie groß dieser Teil ist.
• Der Live-Streifen klappt auf. „Letzte 5 Minuten" zeigt geöffnet, welche Seiten gerade angesehen werden und über welche Quellen die Besucher kommen.
• Die Traffic-Qualität liest sich als Aufteilung, zuerst als eine Leiste, dann als klickbare Zeilen, auf dem Dashboard ebenso. Die Metriken „Bots" und „Datacenter" sind aus dem Chart-Umschalter verschwunden: keine Abfrage füllte sie, und sie zeichneten eine Nulllinie.
• KPI-Kacheln erklären auf Klick, was sie zählen, und Karte, Filter-Chips, Explorer und Geräte-Legende tragen jetzt dieselben Symbole je Quelle, Kanal, Plattform, Seitentyp, Gerät, Browser und Betriebssystem.
• Das Beta-Kennzeichen an der Seitenüberschrift ist weg.

Doku: Analytics.

• Die Karte rahmt die Länder, die den Traffic tragen, statt eines festen Ausschnitts. Ein Shop, der in die DACH-Region verkauft, öffnet auf Europa und nicht auf einem Ausschnitt von Amerika bis China. Der Rahmen folgt den Pageviews und nicht der Länderzahl: ein einzelner Besuch von der anderen Seite der Welt zieht ihn also nicht zurück auf den Globus, ein Markt mit einem Fünftel des Traffics dagegen schon.
• Die Karte ist in beiden Themes lesbar. Länder ohne Daten waren schwarz gefüllt, weil die Füllfarbe ungültiges CSS war und SVG eine ungültige Füllung schwarz zeichnet. Die Traffic-Abstufung hat jetzt fünf klar getrennte Stufen mit einer Legende, die Zahlen daran schreibt, getrennt für hell und dunkel gewählt, und die Grenzen folgen dem Theme statt einem festen Schwarz. Die Karte hat außerdem eine Maximalbreite und ein festes Zwei-zu-eins-Format, eine Karte über die ganze Breite schiebt also nicht mehr alles darunter aus dem Bild.
• Der Bucket, der noch gefüllt wird, sieht in jedem Chart gleich aus: eine gestrichelte Linie, deren Striche vorwärts wandern, damit sie sich wie eine Linie liest, die noch gezeichnet wird. Sieben Charts zeichneten sie stillstehend, darunter Fehlerrate und Request-Trend, und die Perzentil-Charts (LCP, TTFB, die Fetch/XHR-Trends, der Synthetic-Trend) zeichneten überhaupt keinen gestrichelten Bucket und ließen den unfertigen Wert am rechten Rand auf den Boden fallen.
• Das Traffic-Chart fällt am rechten Rand nicht mehr auf den Boden. Die Nullfüllung reichte in die noch laufende Stunde, eine fünf Minuten alte Stunde kam also als harte Null an. Ein Bucket, der den aktuellen Moment enthält, wird nicht mehr erfunden: er wird gestrichelt gezeichnet, wenn das Backend ihn hat, und sonst dem schraffierten Band überlassen.
• Der Explorer lädt als CSV herunter, neben „Als Markdown kopieren": dieselben Zeilen in derselben Reihenfolge, Werte unformatiert, die Einheit im Header, damit eine Tabellenkalkulation damit rechnen kann. Ein Bot-Filter übersteht jetzt außerdem den Sprung in den Explorer.
• Das Raster der aktiven Stunden zeigt nur die Wochentage, die der gewählte Zeitraum wirklich erreicht hat, statt einer ganzen Woche mit fünf leeren Zeilen, die sich wie „am Mittwoch ist nichts passiert" lesen.

Eine Domain zu löschen entfernt ihre Zeile jetzt sofort, statt sie bis zum Neuladen der Seite stehen zu lassen. Die Zeilen werden über den Query-Cache gelesen, und das Löschen aktualisierte nur die Site-Liste der Seitenleiste, die Seite zeigte also weiter, was sie hatte. Eine erkannte Domain zu übernehmen aktualisiert jetzt dieselben Abfragen, damit auch die Domain-Anzahl an der Applikation mitläuft.

Self-Service-Billing. Ein Kunde wählt einen Plan, checkt aus und zahlt eine feste monatliche oder jährliche Grundgebühr per Karte oder Banküberweisung.

• Abgerechnet wird die Applikation, und nur eine Production-Applikation. Eine Development-Applikation ist kostenlos und unbegrenzt, und die Umgebung ist im Anlegen-Formular und in den Einstellungen der Applikation umschaltbar. Ein Plan enthält eine Anzahl Production-Plätze; eine darüber hinaus anzulegen oder hochzustufen wird mit 402 app_limit_reached abgewiesen, und das Anlegen-Formular warnt am Umgebungs-Schalter vor dem Klick und bietet stattdessen eine Development-Applikation oder einen zusätzlichen Platz an.
• Eine neue Organisation hat keinen Plan. plan startet auf none und verlässt das über genau drei Wege: eine Freigabe startet die Testphase, ein Checkout kauft einen Plan, oder ein Partner richtet sie ein. Bisher setzte das Anlegen einer Organisation einen Tarif fest, den niemand gewählt hatte. Die Wire-Werte sind none, beta, light, standard, partner und enterprise; pro heißt jetzt standard und starter heißt light.
• Kapazität wird im Voraus gekauft und nie nach einem Ausschlag abgerechnet. Pageview-Volumen kommt in dauerhaften Blöcken, in den Schritten, die der Plan verkauft, und zusätzliche Production-Plätze sind ein eigenes Add-on. Plan, Blöcke und Plätze gehen in dieselbe erste Zahlung und in den wiederkehrenden Betrag. Ein monatlicher Job schreibt pro Periode einen Nutzungs-Snapshot je Site, damit Quota-Anzeige und Verbrauch pro Applikation Zahlen haben.
• Jeder Preis wird netto und brutto gezeigt, mit dem Steuersatz, und Reverse Charge wird benannt, wo es greift. Rechnungen listen zeilenweise, was gebucht wurde (Plan, Pageview-Blöcke mit ihrer Menge, Applikations-Plätze), mit Steueraufschlüsselung und PDF-Download.
• Verkauft wird vorerst innerhalb der EU. Ein Billing-Profil mit Sitz außerhalb der EU wird beim Speichern abgewiesen, mit dem Fehlercode billing_country_not_supported. Land, Postleitzahl und USt-IdNr. werden beim Speichern gegeneinander geprüft, statt später still etwas zu kosten.
• Billing hat seine eigenen zwei Berechtigungen. billing:read öffnet Rechnungen, Adresse und USt-IdNr. und ist eine Member-Berechtigung, bewusst außerhalb des Viewer-Bündels: ein Nur-Lese-Platz sieht den Billing-Tab gar nicht, statt ihn auf eine Reihe von 403ern zu öffnen. billing:manage bewegt das Geld und bleibt beim Owner. Eine Agentur, die die Rechnungen ihres Kunden liest, ist dort Member, und das ist genau Lesen ohne Verwalten.
• Drei Oberflächen statt eines dichten Tabs, geschnitten nach der Frage: „Plan & Nutzung" dafür, worauf die Organisation läuft und wie viel davon verbraucht ist, „Billing" dafür, wer wie bezahlt, und eine eigene Plan-Seite fürs Auswählen, weil die Feature-Listen den Platz brauchen.
• Testphasen starten, wenn eine Organisation freigegeben wird, mit den verbleibenden Tagen im Header-Banner und im Billing-Tab.
• Das hinterlegte Zahlungsmittel ist sichtbar und austauschbar, mit Marke, letzten vier Stellen und Ablauf. Es wird 30 Tage vor Ablauf gekennzeichnet und danach als abgelaufen benannt.
• Jede gesperrte Aktion nennt ihren Grund: ein Tooltip beim Überfahren und ein sichtbarer Hinweis pro Seite, mit Sprunglink zu dem, was fehlt. Eine Organisation ohne Plan wird zur Planauswahl geschickt und nicht in einen Checkout für den günstigsten Plan.

Doku: Organisationen → Pläne, Errors → Entitlement.

Der Cache-Status sagt, ob der Besucher ein Cache-Objekt bekommen hat. Zwei neue Server-Timing-Keys sagen, wie alt es war, und das ist die andere Hälfte der Frage: ein Shop mit 95 Prozent Trefferquote, dessen Objekte im Schnitt vier Stunden alt sind, liefert schnell und veraltet aus.

• fm-cdn-age;desc=42 füllt cdn_age, fm-origin-age;desc=312 füllt origin_age, beide in Sekunden. Sende sie nur auf einem Cache-Treffer, denn auf einem Miss ist das Alter 0 und zieht jedes Perzentil nach unten. Der Wert reitet auf desc, nicht auf dur: dur ist in Millisekunden spezifiziert, und die DevTools zeichnen es als Balken in der Timing-Ansicht des Dokument-Requests, ein Alter dort erschiene also als Backend-Phase, die es nie gegeben hat. Werte über einem Jahr werden verworfen und nicht gekappt, denn eine so große Zahl ist ein Timestamp.
• Zwei Spalten, nicht eine. Ein Shop hinter einem CDN hat beide Alter im selben Pageview. Der Header des Origins friert im CDN-Objekt ein: auf einem CDN-Treffer ist der Origin-Wert das Alter zum Zeitpunkt, an dem das CDN geholt hat, und erst die Summe ist das Alter, das der Besucher gesehen hat. Das Server-Timing-Panel weist drei Zeilen aus, cdn, origin und content (die Summe auf einem CDN-Treffer), serverseitig berechnet, denn das p75 einer Summe ist nicht die Summe der p75.
• Beide sind Metriken mit den üblichen avg und p50 bis p99, Felder auf den Beacon-Zeilen und im Pageview-Detail neben dem Cache-Status, den sie qualifizieren, und über get_server_timing des MCP-Servers abrufbar.
• fm-fpc heißt jetzt fm-origin-cache, und der alte Name wird nicht mehr erkannt. Es war der einzige First-Party-Key, der die Origin-Ebene anders nannte als origin, und hätte neben fm-origin-age zwei Wörter für eine Ebene in einem Header bedeutet. Ein Header, der weiterhin fm-fpc sendet, erscheint in der Top-Keys-Liste des Panels, statt stillschweigend nichts zu füllen. fm-cdn funktioniert weiterhin, fm-cdn-cache ist die dokumentierte Schreibweise.

Doku: Server-Timing → Cache-Alter.

api_keys.kind hat kein oauth_app mehr, und oauth_client_id fällt mit weg, es bleiben also zwei Arten: personal und org. Der Consent-Flow einer App endete früher in einem langlebigen Key, der dem gehörte, der auf „verbinden" geklickt hatte; seit verbundene Apps OAuth-Verbindungen der Organisation sind, endet er in einem OAuth-Grant, und die alte Form wurde in Produktion nie ausgestellt.

• Einträge von GET /account/api-keys tragen keine oauth_client_id mehr. Verbundene Apps waren nie dafür gedacht, aus dieser Liste gelesen zu werden; sie stehen unter /account/connections und bei den Verbindungen der Organisation.
• Jeder Key wird jetzt als api_key.issued und api_key.revoked auditiert. Die app_token.*-Einträge gehören allein zu Grants, was sie auf der Leseseite ohnehin schon immer beschrieben haben.

Doku: API → Authentication.

Zwei Runden Rückmeldung von MCP-Clients, die den Katalog gegen eine echte Organisation durchgearbeitet haben. Alles hier antwortete plausibel, statt zu scheitern, und genau das macht es zur Notiz wert: nichts in der Antwort sagte, dass die Frage nicht so gestellt worden war, wie der Aufrufer sie gemeint hatte.

• Jedes p75 trägt jetzt die Anzahl der Messungen mit, auf der es steht. get_overview hat einen samples-Block bekommen, compare_periods und detect_changes einen pro Periode. Das ist nicht die Zahl der Pageviews: die Vitals-Spalten sind nullable, ein Client zitierte also ein LCP-p75 aus sieben Pageviews, ohne dass ihn etwas gewarnt hätte. Damit wird auch ein null lesbar, denn inp_p75_ms: null neben samples.inp: 0 heißt „hier wurde nichts gemessen" und nicht „das Feature ist aus".
• Ein url-Filter als Pfad geschrieben matcht den Pfad. Jede Tool-Beschreibung bietet /checkout* als Beispiel, und die Spalte speichert die absolute URL: auf jeder Site traf das nichts und antwortete eine saubere Null.
• Filterwerte matchen ohne Rücksicht auf Groß- und Kleinschreibung, und zwar in jedem Textfeld. browser: ["chrome"], device_type: ["Desktop"] und utm_source: "Google" antworteten je Null auf Daten, die genau das enthielten, was gefragt war, weil gespeichert Chrome steht, aber desktop. country weist einen Namen ab und repariert die Codes, die ISO nicht vergibt (UK und EN zu GB, EL zu GR).
• get_breakdown nennt die angewandte Mindestzahl und flooret keine Zähler mehr. min_samples verwarf Zeilen unsichtbar, und ein leeres Ergebnis unter einer Schwelle von 50 ist ein anderer Befund als eine leere Dimension. Es traf außerdem pageviews, wo der Wert selbst die Zahl der Messungen ist: „Top-Seiten nach Traffic" gab auf einer kleinen Site eine Zeile zurück und verwarf neun.
• get_error_detail erfindet keine Signatur mehr. Ein Aggregat über null Zeilen gab Typ Error mit Zeitstempeln vom 01.01.1970 zurück; Antworten tragen jetzt found, und bei false wird die Signatur genullt. Ein Tag, das keine Site trägt, wird abgewiesen, statt als Scope über null Sites beantwortet zu werden.
• Die Server-Anweisungen sagen jetzt, dass es keine Zeitzone pro Site gibt, denn ein Zeitraum ohne Offset wird als UTC gelesen, und ein Client hatte +02:00 geraten.

Doku: MCP-Server → Was das Modell lesen kann.

Die Real-User-Daten einer Organisation lassen sich jetzt aus einem KI-Client lesen, den du selbst betreibst (Claude Desktop, Claude.ai, Cursor), über das Model Context Protocol: 19 rein lesende Tools mit denselben Zahlen, die auch das Dashboard zeigt.

• Aus, bis ein Owner es einschaltet, unter Organisationseinstellungen → MCP-Server. Solange es aus ist, kann niemand eine Verbindung zu dieser Organisation genehmigen, und ein früher genehmigtes Token wird mit 403 mcp_disabled abgelehnt. Es ist eine eigene Consent-Entscheidung mit eigenem Audit-Eintrag, denn das Modell hinter deinem Client läuft bei einem Anbieter, den wir weder aussuchen noch unter Vertrag haben.
• Eine Adresse für alle: https://api.fastmon.eu/mcp, mit Kopier-Button, sobald der Schalter an ist. Trag sie in deinem Client als Remote-MCP-Server oder Connector ein; er schickt dich hierher zurück, zum Anmelden und Bestätigen. Kein Key zum Einfügen, kein Secret, das irgendwo liegen bleibt.
• Die Organisation wählst du beim Genehmigen, nicht in der Adresse. Eine Verbindung liest genau die gewählte, wer in zweien arbeitet, verbindet also zweimal. Der Consent-Screen sagt, dass es eine MCP-Verbindung ist, und eine Organisation mit ausgeschaltetem Server lässt sich dafür nicht genehmigen.
• Die Verbindung gehört dir, nicht der Organisation. Was sie darf, wird bei jedem Request neu aus deiner aktuellen Rolle abgeleitet: Sie wird enger, wenn du herabgestuft wirst, und endet mit deiner Mitgliedschaft. Verwaltet wird sie unter Account → Zugriff.
• Nichts schreibt. Traffic und Web Vitals, Breakdowns und Zeitreihen, Fehler, LoAF- und Ressourcen-Attribution, Server-Timing-Phasen, Lighthouse-Ergebnisse. Zeiträume sind auf 90 Tage begrenzt, Breakdowns auf 50 Zeilen, Requests auf 120 pro Minute und Person. Die drei Lighthouse-Tools brauchen zusätzlich synthetic:read und das Synthetic-Monitoring-Opt-In der Organisation.
• MCP auszuschalten nimmt niemandem den Zugriff. Es schließt den MCP-Endpunkt; eine bereits genehmigte Verbindung liest weiter über die normale API, mehr hat sie nie verlangt. Beenden kann sie das Mitglied selbst, oder das Offboarding.
• Agenturen verbinden persönlich. Eine Partner-Organisation kann eine Kunden-Organisation verbinden, und der Zugriff endet mit der Partnerschaft. Der Schalter selbst bleibt beim Kunden, dessen Onboarding also einen Klick kostet.

Doku: MCP-Server.

Mehrere Änderungen daran, wie eine Integration sich verbindet. Alle schränken ein, was eine Verbindung am Ende trägt.

• /auth/app/authorize nimmt scope. Ein Client kann weniger anfragen, als er bei der Registrierung deklariert hat, und der Consent-Screen zeigt genau das. Ohne den Parameter bietet der Screen wie bisher die volle Deklaration an. Scope-Namen, die wir nicht implementieren (openid, offline_access), werden verworfen; bleibt nichts übrig, kommt invalid_scope zurück.
• Eine Registrierung ohne scope deklariert analytics:read statt des vollen Rechtekatalogs. Bestehende Registrierungen behalten, was sie haben. Lies das scope in der Antwort, um zu sehen, was du bekommen hast.
• Eine Registrierung ohne credential_owner bekommt eine persönliche Verbindung, bisher war es eine der Organisation. Deklariere organization ausdrücklich, wo die Verbindung die Person überleben muss; ein Shop-Plugin tut das bereits.
• Ein Token kann den Endpunkt nennen, für den es gilt (resource, RFC 8707), im Authorization-Request und noch einmal im Token-Request. Der Consent-Screen liest den Wert, zeigt an, welche Art Verbindung daraus wird, und gibt ihn unverändert zurück; der Endpunkt lehnt danach ein Token ab, das woanders hin adressiert ist, und ebenso eines ohne Adresse. Grants von vor dieser Änderung lassen sich erst adressieren, wenn sie neu genehmigt wurden.
• Behoben: Eine Agentur sah auf dem Consent-Screen nur die eigene Organisation. Die Kunden-Organisationen einer Partnerschaft stehen jetzt zur Auswahl, und die Mitgliedschaft in zwei Agentur-Organisationen endet den Screen nicht mehr im Fehler.

Doku: API → OAuth apps (nur auf Englisch).

Die Spaltenüberschriften sollten stehen bleiben, während die Zeilen darunter laufen, und taten es nicht. Jetzt gehört das vertikale Scrollen der Tabelle, der Header bleibt also stehen, ohne dass die Tabelle aus ihrer Karte läuft.

• Ein Scrollbereich auf der Seite. Ab Tablet-Breite scrollt die Seite selbst nicht mehr und gibt die verbleibende Höhe an die Tabelle. Darunter ändert sich nichts, weil es keine Höhe zu verteilen gibt.
• Maximieren sitzt am rechten Ende der Zeile über dem Ergebnis und tauscht Seiten-Chrome gegen Zeilen: Überschrift, Hits-Leiste und Drill-down-Hinweis klappen weg, Query-Panel und Ergebnisfilter bleiben. Die Wahl wird pro Person gemerkt statt in die URL geschrieben, denn sie gehört dazu, wie jemand die Seite liest, und nicht zur Query, um die es in einem geteilten Link geht.

„Filter“ auf einer Spaltenüberschrift brachte das kleine Formular auf den Schirm und nahm es sofort wieder weg, aus dem Trichter in der aggregierten Tabelle ebenso wie aus dem „...“-Menü über der rohen Pageview-Liste. Jeder Weg dorthin übergibt den Fokus von außen, und genau das las das Popover als Abbruch. Es wertet einen Fokuswechsel jetzt gar nicht mehr so; ein Klick daneben, Escape und die eigenen Buttons schließen es weiterhin.

Die beiden Dimensionen aus fm-host und fm-loggedin haben jetzt ein Dashboard, in dem man sie lesen kann. Beide sind Group-by, Filter und Spalte überall dort, wo die anderen kategorialen Dimensionen es sind, und beide stehen auf der Beacon-Zeile und in der Visitor-Journey.

• Der Weg des Requests wird auf einen Blick zweifach zerlegt. Der Cache-Status sagt, wo ein Request stehen geblieben ist, der Login-Zustand sagt, warum dort. Beides steht als eigene Aufteilung auf der Karte, nebeneinander, wo die Breite reicht, mit der Pageview-Zahl neben jedem Anteil.
• Ein Cluster bekommt ein Urteil, nicht nur eine Tabelle. Ein Panel benennt den Host, der mindestens die Hälfte über dem Median seiner Nachbarn liegt, samt der Zahlen dahinter, und schweigt, wenn die Streuung normal ist. Unter drei Hosts bleibt es still, und es nennt den Anteil der Pageviews, die gar keinen Host gemeldet haben.
• Der Phasen-Trend lässt sich nach Host oder Login aufteilen. Derselbe Chart, eine Linie pro Wert statt pro Phase. Eine Kiste, die sich von ihren Nachbarn löst, tut das hier mit dem Tag, an dem es anfing. Welcher Schnitt zu sehen ist, steht in der URL.
• „Nicht gemeldet“ ist eine Gruppe mit Namen. Auf einem halb instrumentierten Cluster ist das eine Gruppe, die man sehen können muss, und keine fehlenden Daten. Ein eigener dritter Zustand (b2b) wird gezeigt, wie er gespeichert ist, statt auf yes oder no gebogen zu werden.

Doku: Server-Timing → Origin-Host und Logged-in.

Zwei neue Server-Timing-Dimensionen, beide opt-in über den First-Party-Key fm-* (keine Vendor-Aliase, weil ein bloßes host oder user aus einem unbekannten Framework alles bedeuten könnte). Beide sind filterbar und gruppierbar und stehen auf der Beacon-Zeile und in der Visitor-Journey.

• fm-host;desc=web-03 wird origin_host: der Origin-Knoten, der den Pageview gerendert hat. Läuft ein Knoten von fünf heiß, zeigt die aggregierte Backend-Zeit nur ein verschobenes p95; die Aufteilung pro Knoten benennt die Kiste. Sende den kurzen, stabilen Hostnamen: Werte über 32 Zeichen werden verworfen, nicht gekürzt (ein abgeschnittener Hostname wäre ein falscher Knotenname).
• fm-loggedin;desc=no wird logged_in: ob der Render personalisiert war. Authentifizierte Requests umgehen den Full-Page-Cache per Definition; ohne das Flag stehen sie im selben Mittelwert wie der cachebare Traffic, und jede Cache-Hit-Rate ist still verfälscht. Werte werden auf yes/no normalisiert; ein eigener dritter Zustand in Slug-Form (b2b) wird durchgereicht.
• Nur das grobe Flag: keine Kundennummer, Gruppen-ID, Rolle oder Benutzername in fm-loggedin, und keine Request- oder Session-Kennungen in fm-host. Der Collector erzwingt die Form; die Absicht ist dein Teil des Vertrags.
• Nebenbei behoben: Ein reservierter Key mit numerischem Label (fm-loggedin;desc=1, pagetype;desc=404) wurde als Dauer fehlgedeutet und leerte genau die Dimension, für die er gesendet wurde.

Doku: Server-Timing → Origin-Host und Logged-in.

Bisher gehörte jeder Key der Person, die ihn angelegt hat; der Key einer Pipeline starb also mit dem Account, aus dem er kam. Eine Organisation kann jetzt eigene Keys haben.

• Erstellen unter Organisationseinstellungen → Zugriff oder mit POST /v1/organizations/{org_id}/api-keys, hinter der neuen Berechtigung org_key:manage (Member und Owner, nicht Viewer, nie Partner-Zugriff). Das Secret beginnt mit fmo_ und wird einmal angezeigt.
• Die Scopes sind die ganze Autorität. Ein Organisations-Key hat keinen Besitzer, dessen Rolle ihn beschneiden könnte; er darf genau das, wofür er ausgestellt wurde. Die Obergrenze beim Erstellen ist, was die ausstellende Person in dieser Organisation hält; org_key:manage kann kein Key tragen.
• Offboarding ändert nichts. Der Key gilt weiter, wenn die Person geht, die ihn angelegt hat. Widerrufen darf jeder mit org_key:manage, ohne erneute Anmeldung.
• Agenturen bekommen einen Key für alle Kunden. Eine Partner-Organisation kann einen Key mit audience: "clients" ausstellen: Er gilt in den Organisationen, die gerade ihre Clients sind, pro Request aufgelöst und auf das Member-Bündel begrenzt.
• Das Audit-Log nennt den Handelnden. Ausstellen und Widerrufen verzeichnen die Person, die geklickt hat; was ein Key oder eine verbundene App später tut, steht unter ihrem eigenen Namen.

Doku: API → Authentication (nur auf Englisch).

Eine verbundene App hielt bisher einen API-Key, ausgestellt auf die Person, die auf „Verbinden" geklickt hat. Jetzt hält sie eine OAuth-Verbindung, die der Organisation gehört und jeden Account überlebt.

• Kurzlebige Tokens statt Key. Die App authentifiziert sich mit einem Access-Token, das 15 Minuten gilt, und erneuert es mit einem rotierenden Refresh-Token. Jedes Refresh-Token funktioniert genau einmal; ein wiederverwendetes trennt die App, eine gestohlene Kopie bleibt also nicht unbemerkt.
• Der Consent-Screen sagt, was genehmigt wird: welcher Account zustimmt (mit der Option zu wechseln), an welche Organisation die Verbindung gebunden wird (nur echte Mitgliedschaften) und welche Berechtigungen die App bekommt, mit Beschreibung und vor der Zustimmung einschränkbar.
• Trennen unter Organisationseinstellungen → Zugriff oder mit DELETE /v1/organizations/{org_id}/connections/{id}. Bereits ausgestellte Access-Tokens laufen binnen Minuten von selbst ab. Dieselbe App erneut zu genehmigen aktualisiert die bestehende Verbindung, statt eine zweite anzulegen.
• Eine Verbindung kann stattdessen einer Person gehören, wenn die Integration das deklariert (etwa ein Assistent, der in deinem Namen liest). Ihre Autorität folgt bei jedem Request deiner aktuellen Rolle, und sie endet mit deiner Mitgliedschaft; verwaltet wird sie unter Account → Zugriff.
• Für App-Entwickler: Selbst-Registrierung, Authorization Code mit PKCE, Discovery unter /.well-known/oauth-authorization-server. Verbindungen von vor dieser Änderung behalten ihren Key, bis du sie neu verbindest.

Doku: API → OAuth apps (nur auf Englisch).

Einen Key um eine Berechtigung zu erweitern hieß bisher: neues Secret in jeder Pipeline, die ihn benutzt. Keys ändern sich jetzt an Ort und Stelle, persönliche wie Organisations-Keys.

• Bearbeiten von Name, Scopes und Ablaufdatum mit PATCH. Dein Passwort wird nur abgefragt, wenn die Änderung den Key erweitert (neuer Scope, späterer Ablauf); Einschränken und Umbenennen kommen ohne aus.
• Rotieren (POST …/rotate) stellt einen Nachfolger mit demselben Namen, denselben Scopes und Organisationen und frischem Secret aus. Ein optionales Übergangsfenster (bis 24 Stunden) hält das alte Secret gültig, bis ein Deploy jeden Nutzer des Secrets erreicht hat. Rotieren verlängert nie das Ablaufdatum.
• Ein Organisations-Key über deinem Stand ist read-only. Bearbeiten und Rotieren kann nur, wer alles hält, was der Key hält; Widerrufen wartet nie darauf.
• Die Key-Liste beantwortet „kann das gerade handeln?" Ein Status sagt aktiv, läuft bald ab, abgelaufen oder widerrufen; ein abgelaufener Key steht nicht mehr zwischen den gültigen.

Doku: API → Authentication (nur auf Englisch).

Endpunkte liegen jetzt direkt unter https://api.fastmon.eu: GET /organizations, POST /sites/{site_id}/releases. Die Basis-URL in der Doku und alle Beispiele ziehen mit.

• Nichts muss umgestellt werden. Jeder Pfad antwortet zusätzlich mit führendem /v1, und zwar dauerhaft. Eine Pipeline oder ein Plugin auf den alten URLs läuft unverändert weiter. In neuem Code lässt du das Präfix weg.
• Das OpenAPI-Dokument liegt unter /openapi.json, und die Referenz hier wird daraus erzeugt. Die Pfade, die du liest, sind also die ohne Präfix.
• Der öffentliche Ingest (POST /c/{collector_hash}, GET /s/{source_hash}.js) hatte nie ein Präfix und bleibt, wie er ist.

Doku: API → Base URL (nur auf Englisch).

Die Zugriffskontrolle wechselt von „ist dieser User Owner?" zu benannten Berechtigungen (resource:action), und eine dritte Rolle kommt dazu.

• Viewer: ein reiner Lesezugang. Sieht Dashboards, Analytics, Releases, Synthetic-Ergebnisse, Notification Rules und Mitglieder; ändert nichts und löst nichts aus, was Geld kostet oder Mails verschickt. Vergeben beim Einladen oder unter Mitglieder.
• Berechtigungen sind das, was Routen prüfen und woran das Dashboard Aktionen knüpft. Die Organisations-Antwort trägt deine role und permissions; GET /v1/permissions listet den Katalog.
• Mehrere Owner sind möglich. PATCH /v1/members/{member_id} ändert eine Rolle; der letzte Owner kann weder herabgestuft werden noch gehen, solange andere Mitglieder da sind (last_owner).
• Ein Ablehnungscode: 403 permission_denied mit der fehlenden Berechtigung in details.permission ersetzt owner_required.
• Mitglied direkt hinzufügen (POST /organizations/{id}/members) braucht jetzt einen Owner (member:manage); Mitglieder laden stattdessen ein.
• Der Wert des Proxy-Secrets wird nur mit app:write angezeigt; ein Viewer sieht, dass eines gesetzt ist (proxy_secret_redacted).

Doku: Organisationen → Rollen.

Das persönliche API-Token wird durch API-Keys ersetzt, die sagen, was sie dürfen und wo.

• Erstellen unter Account → API-Keys oder mit POST /v1/account/api-keys: Name, mindestens eine Organisation, mindestens ein Scope und ein Ablaufdatum (oder nie). Das Erstellen fragt dein Passwort ab und verschickt eine Sicherheits-Mail; das Secret wird einmal angezeigt.
• Scopes sind Berechtigungen und werden bei jedem Request mit deiner aktuellen Rolle geschnitten, ein Key kann dich also nur einschränken. GET /v1/permissions/self zeigt, was ein Key pro Organisation darf.
• Ablauf und letzte Nutzung: Ein abgelaufener Key antwortet 401 credential_expired; last_used_at sagt, ob ein Key noch benutzt wird.
• Widerrufene Keys bleiben mit ?include_revoked=true gelistet. Widerrufen braucht keine erneute Anmeldung.
• Nur mit Session: Keys erstellen und widerrufen, Passkeys, 2FA, Passwort, E-Mail, Organisation anlegen, Einladung annehmen und die /admin-Routen lehnen API-Keys ab.
• Entfernt: GET/POST /v1/account/api-key; die Registrierung gibt keinen Key mehr aus. Verbundene Apps bekommen Keys mit deinen Berechtigungen und Organisationen zum Zeitpunkt der Zustimmung.

Doku: API → Authentication (nur auf Englisch).

Der CI/CD-Schnipsel einer Application erstellt seinen Key an Ort und Stelle: Name vorausgefüllt, Ablaufdatum nach Wahl, und nach der Passwortabfrage steht das Secret direkt im curl-Befehl. Der Key trägt release:write in dieser Organisation und sonst nichts. Unter Account → API-Keys nennt ein Key zuerst seine Organisationen, gruppiert seine Scopes nach Ressource, und widerrufene Keys behalten einen eigenen Abschnitt. Eine abgelehnte Aktion nennt jetzt die Berechtigung, nach der du fragen musst, und ein Audit-Log-Eintrag lässt sich zu seinen vollständigen Details aufklappen.

Doku: Releases vergleichen → API-Key erstellen.

Die Trennung von Cache und KV hing am Hersteller: Ein Redis-Object-Cache zählte als KV, derselbe Cache auf memcache als Cache. Acht Phasen bleiben.

• kv_dur summiert jetzt redis, valkey, kv, fm-kv, memcache und cache; im Dashboard heißt die Phase „KV / Cache". apcu verlässt die Summen (nur Drill-down).
• http_dur ersetzt external_dur mit denselben Mitgliedern und dem Alias fm-http. fm-cache und fm-external entfallen; keine Site hat sie je gesendet.
• mongodb und sqlite addieren in db_dur zusätzlich zum relationalen Alias: Wo ein Document-Store auftaucht, ist er der Primärspeicher.
• count pro Phase auf POST /analytics/server-timing: die Zahl der Pageviews hinter jedem Perzentil.
• queue und twig kommen in den Katalog (ohne Custom-Slot). Gespeicherte Werte werden nicht umgeschrieben; Notification Rules mit den alten Metriknamen werden weiter auf den neuen ausgewertet.

Doku: Server-Timing → Backend-Phasen.

Ein Tooltip in der Response-Aufschlüsselung besteht jetzt aus dem Namen der Zeile, ihrem Anfang und Ende (61ms → 358ms) und dem Anteil der Requests, die sie gemeldet haben, begrenzt auf eine lesbare Breite. Der restliche Text erscheint nur, wo ein Balken es nicht sagen kann: wenn der Early-Hints-Vorsprung den Balken von seiner Metrik weggeschoben hat. Wer auf eine Server-Phase zeigt, sieht deren Tooltip, nicht den von TTFB. „Erneut versuchen" auf einer Fehlerseite lädt die Daten neu, statt denselben Fehler noch einmal zu rendern.

Das Dashboard nimmt ttfb_final und die Phasen Search und KV auf.

• Response-Aufschlüsselung: Bei Sites mit 103 Early Hints läuft eine Zeile „Early Hints" vom ersten Byte bis zu den finalen Response-Headern. Die Server-Phasen enden dort, und der Übertragungsbalken beginnt dort, statt den Vorsprung doppelt zu zählen. Eine Server-Phase, die länger ist als das erste Byte, behält ihre gemeldete Länge, statt in die Wartezeit gequetscht zu werden.
• TTFB-Seite: ein Panel „Early Hints" mit dem Vorsprung am gewählten Perzentil, beiden ersten Bytes als einem geteilten Balken und dem Anteil der Pageviews, auf denen er gemessen wurde. Nur sichtbar, wo sich die beiden Werte unterscheiden.
• Search und KV sind eigene Phasen auf der Server-Timing-Seite, im Wasserfall und als Explorer-Metriken und -Spalten. Das Preset „Backend-Phasen" bekommt ein Diagramm DB gegen Search und KV.
• Pageview-Drawer: Die Server-Timing-Zusammensetzung ist eine verschachtelte Liste (jeder Teil unter dem, was ihn enthält, mit seinem Anteil an dieser Zeile), nicht zugeordnete Zeit steht als eigene Zeile. Das Backend wird nicht mehr zu seinen eigenen Teilen addiert.
• Jede Phase hat in der Aufschlüsselung ihre eigene Farbe, und die Cache-Phase heißt „Cache" statt „Cache (FPC)": Sie summiert die Cache-Aufrufe der Anwendung; der Full-Page-Cache ist der Cache-Status des Origins.

Doku: TTFB → Early Hints.

Zwei Dinge, die einem geteilten ?visitor=-Link fehlten.

• Wer es war: Der Kopf der Journey zeigt Land, Gerät, Betriebssystem und Browser, pro Pageview gelesen. Was bei einem gestitchten Besucher variiert, wird aufgelistet statt eingedampft.
• Die ID: per Hover vollständig kopierbar. Eine Zeilenaktion grenzt die Seite auf diesen Besucher ein: bei einem Stitch als Filter-Chip (den auch die anderen Analytics-Seiten lesen), bei einer Session-ID über das Suchfeld.
• Gerät, Betriebssystem, Land und Browser bekommen dasselbe Hover-Plus und -Minus wie die Pageview-Tabelle des Explorers.

Die Farben pro Klasse von gestern auf der Besucher-Journey hashten jeden Page-Type außerhalb des Funnels auf ein Rad mit neun Farbtönen, und Kollisionen waren die Regel: „category" und „product" landen auf demselben Ton, wer zuerst auftauchte behielt ihn, der andere rückte weiter, und „category" war in einem Besuch türkis und im nächsten etwas anderes. Die neun Klassen, die fast jede Site hat (home, category, product, search, blog, account, contact, wishlist, static), besitzen jetzt fest einen Farbton, wobei die deutschen Schreibweisen als dieselbe Klasse gelten; site-spezifische Namen behalten ihren gehashten Ton und weichen aus, wenn sie auf einen belegten treffen. „Artikel" steht absichtlich nicht auf der Liste: In einem Shop ist es ein Produkt, im nächsten ein Blogbeitrag.

Die Übersicht listete nackte Sites und versteckte damit die Struktur genau dort, wo ein neuer User sie zuerst trifft: Eine Application trägt den Tracker und seine Erfassungseinstellungen, eine Site ist eine der Domains darunter. Applications sind jetzt die Karten, die meistbesuchte zuerst, jede mit ihren Domains samt Pageviews und LCP der letzten 24 Stunden neben dem Statuspunkt. Darüber dasselbe Fenster für die ganze Organisation: Pageviews, Besucher, LCP p75. Eine Application ohne Domain sagt das und bietet an, eine anzulegen, statt unsichtbar zu sein.

cache_dur zählte redis und Shopifys edge_cart als Cache-Zeit, und Elasticsearch zählte nirgends. Zwei neue Phasen räumen das auf.

• search_dur summiert elasticsearch, opensearch, solr, search und fm-search.
• kv_dur summiert redis, valkey, kv und fm-kv.
• Beide sind Perzentil-Phasen auf POST /analytics/server-timing, Zeilenfelder auf /analytics/beacons und aggregierbare Metriken. db_dur bleibt rein relational.
• cache_dur ändert seine Bedeutung: redis wandert nach kv_dur, edge_cart fällt aus den Summen. Gespeicherte Werte werden nicht umgeschrieben, ein cache_dur-Chart über einen langen Zeitraum macht beim Deploy also eine Stufe nach unten. Ist Redis dein Cache, sende zusätzlich fm-cache.
• Shopify-Hygiene: compressionlevel und speculationtags werden verworfen (Konfiguration, kein Timing), compressiontime kommt in den Katalog, und ein numerisches desc außerhalb des Dauer-Fensters (eine Theme-ID) bleibt eine Description, statt zu einer sechsjährigen Dauer zu werden.

Doku: Server-Timing → Backend-Phasen.

Hinter 103 Early Hints (Shopify-Storefronts, Cloudflare) lag TTFB unter den Server-Timing-Phasen des Servers. Beides stimmte: responseStart ist das erste Byte der vorläufigen 103, der Server-Timing-Header reist auf der finalen Response mit.

• Der Tracker liest finalResponseHeadersStart (Wire-Key frs, Chromium ab 115, sonst null), mit der Aktivierungs-Korrektur und der 60-Sekunden-Kappung von TTFB. Der Collector speichert den Wert als ttfb_final und verwirft Werte unter ttfb.
• So liest du das Paar: leer heißt, der Browser meldet den Wert nicht, oder es war eine Soft-Navigation oder ein bfcache-Restore; gleich ttfb heißt keine vorläufige Response; größer als ttfb heißt Early Hints, und die Differenz ist der Vorsprung der Edge.
• TTFB bleibt responseStart und damit vergleichbar mit CrUX. ttfb_final ist ein Zeilenfeld auf /analytics/beacons, Teil des Besucher-Pageview-Details und eine aggregierbare Metrik.
• Die Server-Timing-Denylist des Trackers bekommt Shopifys compressionlevel und speculationtags, spiegelgleich zum Collector.

Doku: TTFB → Early Hints.

Das Besucher-Panel konnte nicht sagen, von welchem Gerät, Browser oder Land ein Pageview kam, ohne dass die Besucherliste daneben offen war. Jeder Pageview in POST /analytics/visitors/detail trägt jetzt country, browser, browser_version, device_type und os. Absichtlich pro Pageview statt pro Besucher: Ein stitch-Besucher kann Geräte, Länder und Browser wechseln, und das auf einen Wert einzudampfen würde etwas behaupten, das die Daten nicht sagen. Keine neue Erhebung; es sind dieselben Felder, die jede Beacon-Zeile schon speichert.

Funnel-Stufe und Warenkorb-Zähler waren nur auf der Analytics-Seite lesbar.

• Gruppieren nach Checkout-Stufe: gestapelt über die Zeit, eine Linie pro Stufe für jede Metrik, eine Stufen-Spalte, Drill-down pro Zeile. Die leere Stufe heißt „Kein Checkout".
• Warenkorb-Aktionen und fehlgeschlagene Warenkorb-Aktionen als Metriken, zeichen- und summierbar, in Benachrichtigungsregeln nutzbar. Sie zählen von Natur aus zu wenig und sind nie der Nenner einer Rate.
• Filter: „Warenkorb-Aktionen mindestens 1"; checkout_stage lässt sich ausschließen und nicht nur filtern.
• Pro Pageview: Stufe und Warenkorb-Aktionen als Tabellenspalten, dazu ein Checkout-Abschnitt im Drawer.
• Ein Preset „Checkout", eingegrenzt auf die drei Stufen. Das Checkout-Panel im Dashboard verlinkt mit demselben Zeitraum und derselben Site in den Explorer.
• API: checkout_stage als Gruppierung und Ausschluss, cart_interactions und cart_interaction_errors als Metriken und Metrikbereiche, alles auch auf /analytics/beacons-Zeilen.

Doku: Checkout-Funnel → Wo es auftaucht.

Ein Vorperioden-Vergleich mit rein zeitlicher Gruppierung ordnete die beiden Ergebnislisten nach Index zu. ClickHouse liefert nie einen leeren Bucket, und die Buckets fehlen in den beiden Fenstern an unterschiedlichen Stellen, also verschob eine einzige ruhige Minute in der Vorperiode jeden Vergleich danach um eine Minute: Das Diagramm verglich 14:03 mit 14:02 und nannte die Differenz eine Veränderung. Bei Minutenauflösung sind leere Buckets der Normalfall. Buckets werden jetzt über ihren eigenen Zeitstempel gepaart, verschoben um den Abstand der beiden Fenster; ein Bucket ohne Gegenstück meldet keinen Vergleich, statt sich den des Nachbarn zu leihen. Monate bleiben bei der Zuordnung nach Position, weil ein Kalendermonat keine feste Breite hat.

Die Schnellauswahl bekommt „Letzte 15 Minuten", „Letzte Stunde" und „Letzte 3 Stunden", alle im Minutenraster, sodass „brennt gerade etwas?" keinen von Hand getippten Zeitraum mehr braucht. Die Ziffern-Shortcuts decken alle acht Presets ab, 1 für 15 Minuten bis 8 für 90 Tage, und ein Link mit ?period=15min meint weiterhin dasselbe Live-Fenster wie beim Teilen. Das Zeitraum-Panel sortiert die Schnellauswahl in zwei Spalten, Minuten und Stunden links, Tage rechts mit Heute und Gestern oben, und die zuletzt genutzten Zeiträume darunter als Raster mit höchstens vier Einträgen. Beim Öffnen springt der Fokus nicht mehr ins Von-Feld, die Ziffern- und t/y-Shortcuts funktionieren also auch bei offenem Panel.

Der Typ-Chip zeichnete jede Seitenklasse im selben Grün, ein Besuch voller Home-, Produkt- und Suchseiten las sich also als eine einförmige Leiste. Jetzt trägt der Wert die Farbe: Ein Wert, der zugleich eine Checkout-Funnel-Stufe ist, übernimmt deren Farbe, damit die beiden Chips nebeneinander zusammenpassen; ein Wert, der „nicht erkennbar" bedeutet, ist grau wie überall sonst; und jede andere Klasse bekommt einen stabilen Farbton aus einem festen Rad, das innerhalb eines Besuchs weitergedreht wird, damit zwei Klassen auf demselben Bildschirm nie gleich aussehen. Das Rad lässt Rot aus, das auf der Besuchszeile schon Fehler bedeutet.

Der Titel war ein statisches „fastmon" für die ganze App, zwei offene Dashboard-Tabs ließen sich also nicht unterscheiden. Jede Route setzt jetzt ihren eigenen Titel, der spezifischste Teil zuerst, damit beim Abschneiden der unterscheidende Teil bleibt („LCP - Core Web Vitals - fastmon", „Tabelle - Explorer - fastmon"), übersetzt in die aktive Sprache und mit denselben Wörtern wie Sidebar und Breadcrumbs.

Shops konnten sehen, wie schnell ihre Seiten sind, aber nicht, ob Besucher den Checkout erreichen. Jetzt geht das, ohne Tracker-Änderung und ohne neue Erhebung.

• Stufen aus der URL: Ein Pageview auf einer Warenkorb-, Checkout- oder Danke-Seite trägt diese Stufe, beim Ingest anhand eingebauter Muster für Shopware 5 und 6, WooCommerce, Magento 2, PrestaShop, JTL 5 und Shopify erkannt.
• Warenkorb-Interaktionen aus Fetch/XHR: Ein First-Party-POST an einen bekannten Warenkorb-Endpunkt markiert den Pageview, mit der Art, wo der Endpunkt sie verrät.
• Dashboard: Checkouts als vierte zentrale Kennzahl, ein Checkout-Panel mit Besuchern pro Stufe und Warenkorb-Requests nach Art (ersetzt die Tech-Einblicke), die Stufen auf der Karte der aktuellen Besucher und Pro-Minute-Durchschnitte auf den Zähl-Kacheln.
• Filter, Besucher, Business Impact: checkout_stage als Filterdimension, die Besucherliste gefiltert auf eine Stufe oder eine Warenkorb-Interaktion, und eine gemessene Conversion-Rate auf Business Impact, wo der Funnel Daten hat.
• Nur Fakten: keine Abbruch-Kennzahl, und Abschluss zählt Danke-Seiten, keine Zahlungen.
• Einstellungen: standardmäßig an, Opt-out und Pfade pro Stufe unter Einstellungen → Checkout-Funnel. Braucht store_stitch; Warenkorb-Interaktionen brauchen collect_fetch_xhr.
• API: POST /analytics/funnels/checkout und /journeys; contains_checkout_stage und contains_cart_interaction auf der Besucherliste.

Doku: Checkout-Funnel.

„Wie sieht das ohne den Länderfilter aus?" hieß bisher: Filter löschen und danach wieder eintippen.

• Jeder Chip hat einen Ein/Aus-Schalter. Ausgeschaltet behält er seine Werte, bleibt durchgestrichen an seinem Platz, und die Abfrage läuft ohne ihn. Gilt für Einschluss-Filter, Ausschlüsse, Metrikbereiche und Ja/Nein-Filter.
• Aus heißt überall aus: nicht im Badge gezählt, kein Land in der Karte als ausgewählt gezeichnet, Gerätesegmente nicht gewählt. Ein Klick darauf schaltet den Filter wieder ein, statt einen zweiten anzulegen.
• In der URL als vorangestelltes ! am Schlüssel des Eintrags, ältere Links öffnen also mit allen Filtern an.
• Die Scope-Zeile zeigt ein Land mit seiner Flagge statt mit dem Code.

Die Zusammenfassung über der Besucherliste wurde über die geladenen Zeilen berechnet und sprang deshalb beim Weiterblättern.

• Zusammenfassung über den Zeitraum: Besucher, Besucher mit nur einer Seite und der Median der Seiten pro Besucher. Die durchschnittliche Dauer fällt weg, statt repariert zu werden: Es gibt keine zeitraumweite Besuchsdauer, aus der sie sich berechnen ließe.
• Land zeigt Flagge und lokalisierten Namen, der Code steht im Hover.
• URL: Verhaltensfilter sind einfache Zahlen (?minPages=3), und der Parameter für den verlinkten Besucher heißt visitor statt session. Alte Links funktionieren weiter und schreiben sich um.
• Fixes: Ein alter /sessions-Link mit Page-Type-Filter kam ungefiltert an, und eine 32-stellige Besucher-ID, die als Zahl in der App landete, hatte Ziffern verloren und wurde trotzdem weitergereicht. Sie wird jetzt verworfen statt verfälscht.

Der Netzwerk-Abschnitt bekommt eine Karte „Response-Aufschlüsselung" über die volle Breite. Sie ersetzt das Diagramm „Network Request Timing", das vier Metriken als einen Balken zeigte, ohne dass man tiefer hineinschauen konnte.

• Ein Wasserfall am gewählten Perzentil, wie ihn die Devtools zeichnen: DNS, Verbindungsaufbau, Wartezeit und Übertragung als Treppe, danach die LCP-Phasen (Load Delay, Load Duration, Render Delay). Server-Timing-Phasen liegen innerhalb der Wartezeit; die Vergleiche für CDN- und Origin-Cache teilen ihre Balken in Hit und Rest. FCP, LCP und DOM Interactive stehen als Marker auf der Achse.
• Ehrliche Mathematik: Perzentile einzelner Phasen addieren sich nicht, deshalb wird die Wartezeit als Rest abgeleitet und die LCP-Phasen enden genau am LCP-Marker. Tooltips zeigen den Rohwert, die Position und den Anteil der Requests, die die Phase gemeldet haben.
• Zeilen darunter listen Page-Types (wo gemeldet) oder Seiten mit kompakten Balken. Ein Klick auf eine Zeile engt den Wasserfall ein („Gesamt › cart"); die Auswahl steht in der URL.
• Der Pageview-Drawer im Explorer zeigt denselben Wasserfall für einen einzelnen Pageview.
• Fix: Ein Deep-Link auf eine Karte weiter unten (?panel=) scrollte nicht, weil der Abschnitt noch nicht gerendert war. Er lädt jetzt sofort.

Die Karte „Top Pages" zeigte Views und LCP, und die Performance pro Page-Type hatte gar keinen Platz, obwohl sich in den Zahlen der ganzen Site ein langsamer Checkout hinter einer schnellen Startseite versteckt.

• Eine Tabelle über die volle Breite: Views mit einem Balken für den Traffic-Anteil, daneben LCP, INP, CLS und TTFB als statusfarbene Pillen am gewählten Perzentil.
• Page-Types oder Seiten, umschaltbar im Kopf. Sites mit Page-Type-Detection öffnen auf Page-Types, mit dem untypisierten Traffic als gedämpfter Zeile, damit die Anteile aufgehen; Sites ohne landen auf den Seiten und werden auf die Einstellungen verwiesen.
• Zeilen filtern weiterhin das Dashboard oder springen in den Explorer. Der Traffic-Trend bekommt wieder eine eigene volle Zeile.
• Große Zahlen kürzen überall gleich ab (K/M), die exakte Zahl steht im Tooltip.

Wer Beacons über den eigenen Server weiterleitete, bekam alle Besucher als einen: Alle Requests kamen von der IP des Proxys, und ein beliebiges X-Forwarded-For zu übernehmen würde Spoofing erlauben.

• Eine explizite Freigabe pro Application: Unter Einstellungen → Collector ein Proxy-Secret generieren, es im Header FM-Proxy-Key auf der Beacon-Route mitschicken, und die Edge liest die echte Besucher-IP aus dem X-Forwarded-For deines Proxys. Geo- und Besucherzahlen funktionieren, als wäre das Beacon direkt angekommen.
• Rotation ohne Lücke: Das vorherige Secret bleibt bis zur nächsten Rotation gültig. Löschen schaltet das Vertrauen ab.
• API: POST und DELETE /v1/applications/{id}/proxy-secret.

Doku: First-Party-Proxy-Guide, mit Snippets für nginx, Caddy und Cloudflare Worker.

Zwei Änderungen an der shopware6-Ruleset.

• Home zählt als Home. Die Startseite zählte als category, weil Shopware 6 sie über den Navigation-Controller rendert und die erwartete Klasse is-ctl-index dort nicht existiert. Der Tracker liest jetzt Controller- und Action-Klasse zusammen (is-ctl-navigation is-act-home).
• Die Erkennung übersteht 6.8, das die Klassen is-ctl-* und is-act-* entfernt. Der Tracker bevorzugt die is-active-route-*-Klasse, die Shops seit etwa 6.6 ausgeben. Darüber trennt sich der Checkout sauber: Warenkorbseite als cart, die Schritte Bestätigen, Abschluss und Registrierung als checkout, der Kontobereich als account. Ältere Shops fallen auf die Legacy-Klassen zurück, wo Warenkorb und Checkout weiter cart teilen.
• Ein im Browser gecachter Tracker behält sein altes Verhalten, bis der Cache abläuft.

Doku: Tracker → Ruleset-Tabelle.

Eine Runde Filterarbeit.

• Weltkarte: Ein Klick auf ein Land funktioniert und öffnet ein Popover mit seinen Zahlen und den Plus- und Minus-Aktionen (filtern oder ausschließen). Ausgeschlossene Länder bekommen eine rote Umrandung, und die Karte behält Zoom und Ausschnitt beim Nachladen.
• Header-Chips: Ein Chip öffnet direkt seinen Werte-Editor, ein x entfernt den Filter, im Hover steht jeder ausgewählte Wert mit eigenem x.
• Werte-Editor: Ausgewählte Werte sind oben angepinnt und bleiben auch ohne passenden Traffic entfernbar; denselben Wert ein- und auszuschließen geht nicht mehr.
• Kein Springen mehr: Performance-Kacheln, Geo-Karte und die Core-Web-Vitals-Karte zeigen die bisherigen Werte weiter, während die neuen laden.

Ein Klick auf den Spaltenkopf ordnete nur die schon geladenen Zeilen um; „die zehn schlechtesten TTFB-Seiten" waren also „die schlechtesten unter den meistbesuchten".

• Serverseitige Sortierung: Das Backend sortiert, bevor es kürzt, und die Sortierung steht in der URL.
• Nichts sortiert implizit: Eine Metrik auszuwählen fügt eine Spalte hinzu und sonst nichts; ohne gewählte Sortierung benennt die Tabelle die Standard-Reihenfolge des Backends.
• Die rohe Pageview-Liste sortiert ebenfalls serverseitig, nach Zeit oder jeder Spalte, leere Werte am Ende. Ihre sichtbaren Spalten stehen im Link (?cols=).
• Die Metrik-Spalten sind aus dem „Spalten"-Menü ins Abfrage-Panel gewandert.
• API: /analytics/beacons nimmt order_by als {field, direction} über jedes skalare Zeilenfeld an.

Ein Origin kann einen Server-Timing-Key als Label statt als Timing schicken (pop;desc="DE-1331"). Solche Keys wurden gespeichert, blieben aber unsichtbar, weil alles nach Millisekunden rankte.

• Jetzt sichtbar: Die Server-Timing-Seite listet sie unter den gemessenen Keys samt Verteilung ihrer Werte, der Pageview-Drawer zeigt sie als Schlüssel/Wert-Felder, und der Explorer zeigt jeden Custom-Key als Spalte und sortiert und filtert darauf.
• Eingegrenzte Pageview-Liste: /analytics/beacons bekommt einen server_timing-Filter auf einen Key oder einen seiner Werte.
• PoP-Keys bleiben: pop, fastly-pop, cdn-pop und x-qc-pop benennen den CDN-Knoten, nicht den Besucher (asn, country und ipv6 bleiben gesperrt).
• Fix: Den Trend eines Custom-Keys mit Bindestrich oder Punkt im Namen (wp-total) aufzuklappen führte zu einem Fehler.

Die aggregierte Explorer-Tabelle und die rohe Pageview-Liste bekommen je einen Kopieren-Button, der die Tabelle als Markdown in die Zwischenablage legt, genau wie angezeigt: die gefilterten Zeilen in sichtbarer Sortierung, mit den formatierten Anzeigewerten und den gewählten Spalten. Praktisch für ein Ticket, einen Chat oder einen Prompt. Werte mit Pipes oder Zeilenumbrüchen werden escaped, eine kopierte Zeile kann das Markdown-Raster also nicht zerbrechen.

Drei kleine Korrekturen. Die rohe Pageview-Tabelle konnte auf Sites ohne gespeicherte Session-IDs eine Zeile doppeln oder verschlucken, weil sich zwei Pageviews in derselben Millisekunde einen Zeilenschlüssel teilten (jetzt zählt die Pageview-ID). Ein Kartenkopf mit Bedienelementen konnte seine eigenen Buttons über den Kartenrand hinausschieben. Und ein Chart-Tooltip zeigte für den Wert 0 gar nichts an.

Der Explorer hatte einen eigenen Filterapparat, direkt neben dem Standard-Filtermenü, das überall sonst dieselbe Aufgabe erfüllt.

• Die Standard-Bedienelemente übernehmen: Abfrage-Filter im Scope-Menü, Presets in einem Menü mit den gespeicherten Abfragen, clientseitige Ergebnisfilter über der Tabelle.
• Aktualisieren und Live-Modus wandern in die Zeitraum-Steuerung.
• Der Filterzähler zählt jede Art: Ein Ausschluss, ein Metrikbereich wie lcp >= 2.5s oder der Bot-Schalter waren bisher aktiv, während der Button „nichts gefiltert" anzeigte.

Eine Runde Interface-Arbeit in der eingeloggten App, mit Fokus auf Mobil und Filtern.

• Header in zwei Hälften: links, wo du bist, rechts, wonach du filterst. Zeitraum, Perzentil, Gerät und Filter falten sich zu einer Scope-Zusammenfassung (Letzte 7 Tage · p75 · 📱 · Land: DE +4) mit den Bedienelementen in einem Popover. Aktive Filter sortieren nach Wichtigkeit.
• Mobil: Die Seitenleiste wird zu einem Offcanvas-Drawer, Dialoge bleiben im Bildschirm, Überschriften und Abstände sind über alle Seiten konsistent.
• Fixes im Filter-Editor: Ein einwertiger Filter zeigt seinen aktuellen Wert, die Wertezähler berücksichtigen die schon gesetzten Filter, und der Schalter „Bots ausblenden" erscheint nicht mehr beim Bearbeiten eines anderen Filters.
• Die Links zu Dokumentation, Feedback und Support falten sich zu einem Hilfe-Button.

Eine Reihe von Korrekturen rund um Anmeldung und Konto. Der Bestätigungslink meldet keinen Fehlschlag mehr, nachdem er tatsächlich funktioniert hat: Ein Mail-Client, der den Link vorab lädt, oder ein schnelles Doppeltippen verbrauchte bisher das einmalige Token und ließ dich auf einer Fehlerseite zurück; die Seite bietet jetzt einen Login-Button an, wenn die Adresse bereits bestätigt ist. Wer sich auf Deutsch registriert, bekommt die Bestätigungsmail auf Deutsch statt auf Englisch. Die Anmeldung springt nicht länger in einer Endlosschleife zwischen /login und Dashboard und bringt dich zurück auf die Seite, zu der du unterwegs warst. Und eine Organisation auf einer globalen Seite auszuwählen verwirft die Auswahl nicht mehr.

Jeder Request trägt jetzt ein Traffic-Urteil.

• Mensch, Wahrscheinlich Bot, Bot. Bot ist ein deklarierter oder verifizierter Crawler. Wahrscheinlich Bot ist eine Rechenzentrums- oder VPN-Adresse oder eine User-Agent-Anomalie ohne Bot-Deklaration (ein Besucher im VPN landet hier). Mensch ist alles andere.
• Bots ausblenden reduziert die ganze Ansicht mit einem Klick auf echte Besucher. Ein Chart Bots & Besucher teilt den Traffic nach Urteil und listet die häufigsten Bots und Bot-Typen.
• Neue Filter: Rechenzentrum oder Hosting-Netz, Bot-Name, Bot-Typ, User-Agent-Anomalie.
• Die Erkennung läuft an der Edge gegen eine feste Liste von Anbietern und Crawlern; IP und User-Agent werden direkt danach verworfen.

Doku: Privacy → Bot- und Rechenzentrums-Labels.

Das Dashboard fasst Traffic-Trend, Top-Seiten, Geräte und Browser sowie die neue Bot-Aufschlüsselung zu einem Bereich Traffic & Besucher zusammen, wobei Traffic-Trend und Top-Seiten sich eine Zeile teilen, sodass die Seitenliste nicht mehr alles dominiert. Top-Seiten ist als kompakte Tabelle neu gebaut (Seite, Aufrufe, LCP) mit einem Traffic-Anteilsbalken pro Zeile und nach Status eingefärbtem LCP, und sie zeigt jetzt Query-Strings: /?q=schuhe und / sind getrennte Zeilen, statt zu einem verwirrenden Haufen zu verschmelzen. Auf der Weltkarte lässt sich die Metrik zwischen LCP, FCP und TTFB (p75) umschalten, und ein Klick auf ein Land filtert das ganze Dashboard darauf (erneuter Klick hebt es auf).

Das Dashboard hat eine optische Auffrischung. Die Seitenleiste trägt das neue fastmon-Logo, fährt beim Ein- und Ausklappen seitlich ein statt zu faden und klappt zu einer Icon-Leiste mit Popovers und Tooltips zusammen. Buttons sind jetzt Pillen, Karten und Eingabefelder flacher mit leichteren Rändern und runderen Ecken, der Zeitraum-Picker und die übrigen Chart-Steuerungen teilen sich einen segmentierten Stil, und Überschriften nutzen eine neue Serifen-Displayschrift. Die helle und die dunkle Palette wurden für besseren Kontrast nachjustiert.

Der Collector templatisiert Fetch/XHR-Endpunkt-Pfade aggressiver, damit die Ansicht pro Endpunkt lesbar bleibt. Das läuft serverseitig, also werden auch schon erhobene Daten aufgeräumt.

• Engere Templatisierung: Lange Content-Slugs klappen auf :slug, Soft-Navigation-Dokument-Fetches (_rsc, _data, /_next/data/, /page-data/) auf /:page, Third-Party-Hosts verlieren die Query, und acht oder mehr Query-Parameter erscheinen als ?:many.
• Ad-Attribution-Parameter bleiben draußen (gclid, gbraid, wbraid, msclkid, fbclid, die Familien utm_* und gad_*), auf Endpunkt-Pfaden und Seiten-URLs, auch bei aktivem collect_query_keys. Wer einen in collect_query_values_for nennt, behält ihn.

Doku: Tracker → collect_query_keys.

Login, Registrierung und Passwort-Reset sitzen jetzt auf einer zentrierten Karte über schlichtem Hintergrund, mit einer neuen Serifenschrift für die Überschriften und dem Theme-Umschalter in der Ecke. Das frühere geteilte Layout, das Testimonial-Karussell und die Performance-Risiko-Texte neben dem Formular sind weg.

Für die Anmeldung braucht es keine Wartelisten-Einladung mehr: Die „Zugang erhalten"-Links führen direkt zur Registrierung, und jede Person kann ein Konto anlegen. Eine neu angelegte Organisation wartet auf eine Freigabe, bevor sie Applications hinzufügen kann; bis dahin zeigt die Applications-Seite einen Hinweis „wartet auf Freigabe", während dein Konto und vorhandene Daten unberührt bleiben.

Ein Chart ohne Daten zeigte „Keine Daten verfügbar", was eher unseren Speicher beschrieb als deine Site. Besucherbasierte Charts (Seiten, Browser, Geräte, Länder, Referrer, Web Vitals, Fehler) sagen jetzt „Keine Besucher im gewählten Zeitraum", requestbasierte (Cache-Trefferquote, Backend-Zeit, Requests) „Keine Requests im gewählten Zeitraum". Auch die diagonale „Keine Daten"-Schraffur in Trendcharts ist weg: Eine ruhige Phase ist normal, deshalb endet die Linie einfach dort, wo die Daten enden, und setzt wieder ein, wo sie weitergehen, statt schraffiert zu werden, als wäre etwas kaputt.

Sites und Cross-Domain-Tracker werden durch Applications ersetzt.

• Eine Application, ein Snippet: Sie besitzt den Embed, die zwei Hashes und jede Tracker-Einstellung und bedient eine Domain oder zwanzig. Jede Domain bleibt eine Site mit eigenem Dashboard. Keinen „Single vs. Multi"-Modus mehr.
• Applications-Seite: eine Karte pro App mit ihren Sites samt Live-Status, Releases, Embed-Snippet und Analytics. Sites lassen sich inline adoptieren, verschieben oder löschen.
• Vorgeschlagene Domains: Eine Domain, die unregistriert Beacons schickt, erscheint zum Adoptieren mit einem Klick. Die neue Einstellung „Unbekannte Domains" entscheidet: vorschlagen (Default), automatisch anlegen oder ignorieren.
• Defaults pro Application, pro Site überschreibbar: Aufbewahrung, Besuchersignal und der Identifier zum Zählen von Besuchern. Der Collector wird beim Anlegen gewählt; Applications lassen sich als Produktion oder Entwicklung markieren.
• Umbenannte Einstellungen: store_session heißt collect_sessions, preconsent_level heißt session_consent (deferred oder immediate), und die Schalter für Fehler, Query und Fetch/XHR bekommen das Präfix collect_.

Doku: Applications, Sites, Tracker-Einstellungen.

Die Rohdaten-Tabelle im Explorer lässt dich jetzt Spalten am Titel greifen und umsortieren, die Breite an der rechten Kante des Headers ziehen und über ein „…"-Menü pro Spalte filtern oder die Spalte entfernen. Alle drei Einstellungen bleiben pro Browser erhalten. Auch die Seiten-Spalte (URL) ist jetzt breitenverstellbar: Sie füllt standardmäßig den Rest der Breite und rastet ein, sobald du sie ziehst, kann also unter ihren Inhalt schrumpfen, statt zurückzuspringen. Ein neuer Auto-Fit-Button in der Toolbar setzt alle eigenen Breiten zurück, sodass die Tabelle wieder ohne horizontales Scrollen ins Fenster passt.

Auf der Tabellenseite des Explorers wurde der Streifen Hits über Zeit bei Minutengranularität (das 6h-Preset und kurze eigene Zeiträume) als einzelner Punkt gezeichnet. Das Bucket-Label dient zugleich als X-Achsen-Schlüssel, und der Minutenfall fiel auf ein Label mit nur Tag und Monat zurück; alle Buckets desselben Tages teilten sich also ein Label und stapelten sich an derselben Position. Minuten-Buckets enthalten jetzt die Uhrzeit, wie die anderen Trend-Charts.

Die Speicherleiste auf den Einstellungsseiten von Application und Site sitzt jetzt bündig am unteren Rand, statt darüber zu schweben, während Einstellungen darunter durchscrollen. Die Breadcrumbs dort zeigen den echten Namen der Application oder Site statt eines generischen „Einstellungen", und der Zurück-Pfeil führt eine Ebene nach oben, statt sich wie Browser-Zurück zu verhalten. Wer zu keiner Organisation gehört, landet nicht mehr auf einem Dashboard, das ewig lädt, sondern bekommt einen Zustand zum Anlegen einer Organisation. Und die Live-Rate im Dashboard wird nicht mehr als 0.30000000000000004/min angezeigt.

Eine Browser-DevTools-Erweiterung, die die Beacons deiner Seite mitliest und live dekodiert.

• Gruppiert Beacons nach Pageview, packt die Wire-Keys in lesbare Felder aus, verfolgt den Lebenszyklus von init bis zum letzten Beacon und zeigt die Web Vitals, während sie sich setzen.
• Erfasst die fetch-Beacons und die sendBeacon-Bodies, die das Netzwerk-Panel nicht zeigen kann.
• Der Follow-Modus pinnt den neuesten Pageview, Vergleichen stellt zwei nebeneinander, und der Export kopiert ein Beacon als Markdown (optional anonymisiert).
• Open Source; keine Beacon-Daten verlassen das Gerät.

Doku: Beacon Inspector.

Transaktions-E-Mails kommen jetzt auf Deutsch oder Englisch, passend zur Sprache in deinem Account, mit Englisch als Rückfallebene; lokalisiert sind heute E-Mail-Bestätigung, Passwort-Zurücksetzen und Passkey-hinzugefügt. Und wenn eine Site live geht, bekommt jedes Mitglied der besitzenden Organisation eine „Site ist live"-E-Mail in der eigenen Sprache, mit Link direkt auf das Dashboard dieser Site.

Dein Theme (hell, dunkel oder automatisch) und der Schalter für die Rot-Grün-Farbfehlsichtigkeits-Palette liegen jetzt an deinem Account statt nur in einem Browser, eine Änderung auf einem Gerät gilt also auch auf dem nächsten. Die Auswahl greift sofort und wird zuerst lokal gespeichert, dann im Hintergrund synchronisiert; sie funktioniert also auch offline oder wenn die Synchronisierung fehlschlägt. Beim Login gewinnt die im Account gespeicherte Einstellung.

Der Tracker sendet weniger Requests und misst die Ladephase genauer. Am Wire-Format und an deinem Setup ändert sich nichts.

• init feuert sofort als Marker „Pageview existiert", damit auch ein Bot oder eine abrupt geschlossene Seite registriert wird.
• loaded wartet auf das finale LCP (erste Interaktion, Tab verborgen oder eine Kappung bei 10 Sekunden) statt auf den ersten, oft vorläufigen Eintrag.
• Update-Beacons nur bei einem relevanten Signal (neuer First-Party-Endpunkt, fehlgeschlagener Request, Aufruf über 500 ms). Ein typischer Pageview sendet zwei bis vier Beacons.
• Terminale Beacons behalten keepalive, Live-Beacons nicht mehr, damit das finale INP und CLS auf Chromium zuverlässig ankommen.

Doku: Beacon → Feinjustierung.

Soft-Navigation-Pageviews (SPA-Routenwechsel) sendeten auf aktuellem Chrome gar keinen LCP, selbst wenn die Route klar ein großes Bild rendert, während FCP und INP normal durchkamen. Eine Formänderung in Chromes interaction-contentful-paint-Einträgen führte dazu, dass der Tracker die Interaktions-(Klick-)Zeit statt der Paint-Zeit las, was einen LCP von null ergab, den die Plausibilitätsprüfung dann verwarf. Der Tracker liest jetzt die Paint-Zeit und ordnet jeden Paint über die Interaction-ID seiner Route zu, sodass der SPA-Routen-LCP befüllt wird.

Wurde das Tracking-Tag auf einer Seite zweimal eingebunden oder ausgeführt (ein häufiger Tag-Manager-Fehler), umschloss jede Kopie die History-API des Browsers erneut und registrierte eigene Listener, sodass ein einzelner SPA-Routenwechsel in jeder Kopie feuerte und doppelte Pageviews und doppelte Beacons erzeugte. Der Tracker sichert sich jetzt gegen eine zweite Ausführung ab und bricht ab, sodass eine zusätzliche Einbindung folgenlos bleibt.

Die rohe Requests-Liste des Explorers und die Visitors-Seite bekommen einen echten Live-Modus. Eingeschaltet rastet er den Zeitraum auf die letzte Stunde ein (ein Live-Stream über 30 Tage ist sinnlos) und stellt beim Beenden den vorherigen Zeitraum wieder her, heftet sich an die neueste Seite und zeigt brandneue Pageviews, sobald sie eintreffen, statt auf den 30-Sekunden-Count-Cache zu warten (er zeigt „Live · N angezeigt“ ohne exakte Gesamtzahl, zugunsten der Aktualität). Der Live-Umschalter und der Refresh-Button verschmelzen zu einem Control mit Countdown-Rand, der über das Intervall abläuft und bei jedem Refresh neu startet, ob manuell oder automatisch.

Zwei neue Filtermöglichkeiten. Browser-Version ist ein numerischer Bereichsfilter auf die Major-Version des Browsers (Browser-Version ≥ 150, mit ≥, ≤ oder einem Bereich, wie bei jedem numerischen Filter); kombiniere ihn mit einem browser-Filter, denn eine Versionsnummer bedeutet je Familie etwas anderes. Und du kannst jetzt einen stitch-Wert eintippen oder einfügen, um auf einen einzelnen Besucher einzuschränken, wo es vorher nur per Klick ging; ein eingefügter Wert wird auf Kleinbuchstaben-Hex normalisiert.

Die kompakten Wire-Keys des Beacons, früher ein undurchsichtiges Nummernschema (t1, t9, t10 und so weiter), sind jetzt kurze Mnemonics: ttfb, lcp, inp, cls und der Rest. Vollständig abwärtskompatibel und ohne Zutun deinerseits: Der Collector akzeptiert die alten Keys weiter, eine Seite mit einem älteren gecachten Bundle meldet also unverändert, bis sie sich aktualisiert. Dasselbe Release wirft drei veraltete JSON-Blobs raus, die der Beacon nicht mehr braucht (die alten Third-Party-, Resource- und Long-Animation-Frame-Strings, längst durch strukturierte Felder ersetzt), und spart so ein paar Hundert Bytes pro Pageview. Siehe Der RUM-Beacon.

Auf einer Seite, die sowohl einen Fehler als auch einen fetch/XHR-Aufruf protokollierte, konnte der Tracker zwei Byte-identische Update-Beacons im selben Moment absenden: Der Fehler-Kanal und der fetch/XHR-Kanal führten je einen eigenen Sende-Timer, und keiner wusste, dass der andere den vollen Snapshot bereits verschickt hatte. Da jedes Beacon den kompletten kumulativen Stand trägt, war das zweite reine Dopplung. Der Tracker merkt sich unversendete Aktivität jetzt pro Kanal und überspringt ein Update, sobald der aktuelle Stand schon auf dem Draht ist. Weniger Requests, und kein Datenverlust: Das Update, das rausgeht, trägt weiterhin beide Kanäle.

Der Drill-down-Datensatz heißt im ganzen Dashboard jetzt Pageview (Beschriftungen, Tooltips, Kopier-Buttons, Leer- und Ladezustände sowie der Markdown-Export) statt „Beacon“, was sich wie Fachjargon las. Seine Deep-Link-Parameter wechseln auf ?pageview= und ?pvtab=, alte ?beacon=-Links lösen also nicht mehr auf. Das Öffnen eines Pageviews aus der rohen Explorer-Liste schreibt ihn jetzt ebenfalls in die URL, sodass ein Neuladen dieselbe Zeile wieder öffnet und der Link teilbar ist.

Jeder filterbare Wert in der Explorer-Tabelle und im Pageview-Drawer bekommt beim Hovern + / −-Buttons, die diesen Wert direkt in die Explorer-Filter aufnehmen oder ausschließen. In der Tabelle schweben sie über dem Ende der Zelle, sodass ihr Einblenden nie eine Spalte verschiebt oder abschneidet; im Drawer sitzen sie in einem reservierten Slot neben Land, Page-Type, Gerät, OS, Browser, Connection, Protokoll, Navigation, Referrer, Kampagne, Cache-Status und Domain (Browser filtert Chrome, nicht Chrome 120). Das + wirkt auch auf den Besucher (Stitch) eines Pageviews und schränkt den Explorer auf genau diesen Besucher ein.

Der Pageview-Drawer zeichnet seine Netzwerk-Abschnitte jetzt als proportionale Bar-Lists (Schlimmstes zuerst) statt als flache Zeilen. Resources zeigen Anzahl, Größe und Dauer je Initiator-Typ (die Größen und Dauern wurden erfasst, aber nie angezeigt), Third Parties teilen sich nach Domain (Blocking-Zeit) und nach Kategorie (Request-Anteil), und Long Animation Frames reihen sich nach Blocking-Zeit je Skript. Server Timing wird zu einem gestapelten Kompositions-Balken aller Backend-Phasen (die sieben promoteten Metriken plus deine eigenen Server-Timing-Keys) mit passender Legende; eigene Keys, die bereits eine promotete Phase speisen, werden dedupliziert, sodass die Summe nicht doppelt zählt.

Der Tracker strippte die Query von jedem Fetch/XHR-Pfad; ein Front-Controller-Shop (/index.php?controller=Search gegen ?controller=Cart) fiel so in einen einzigen /index.php-Eimer.

• Dieselben Einstellungen wie die Seiten-URL: collect_query_values_for behält die gewählten key=value-Paare, collect_query_keys die bloßen Key-Namen. Ohne beides ändert sich nichts.
• Der Tracker reduziert den Pfad; der Collector wendet dieselbe Regel als Absicherung erneut an.
• Konfigurierte Keys sind auf Buchstaben, Ziffern, _ und - begrenzt, ein Key kann also nie aus dem ausgelieferten Bundle ausbrechen.

Doku: Tracker → collect_query_values_for.

Die Analytics-Filter enthalten jetzt stitch: schränke jede Aufschlüsselung, jedes Chart und jeden Drill-down auf einen oder mehrere bestimmte Besucher per Stitch-ID ein. Die Werte sind dieselben 32-stelligen Hex-IDs, die POST /analytics/beacons zurückgibt, worauf du filterst, entspricht also dem, was du zurückliest. Ungültige IDs werden ignoriert, und ein Filter nur aus ungültigen IDs trifft nichts. Es ist ein Treffer-Filter (ein Ausschließen per Stitch gibt es nicht).

Das Beacon-Drill-down (POST /analytics/beacons) liefert mehr Detail je Beacon und lässt sich auf einen einzelnen Fehler einschränken. Ein neues Feld error_fingerprint gibt nur die Pageviews mit dieser Fehlersignatur zurück, was den „In Explorer öffnen“-Link der Fehler-Seite trägt. Jede Beacon-Zeile führt jetzt außerdem ihre Fehlerklasse (normal oder ad-geblockt), die durchschnittliche Waterfall-Position jedes fetch/XHR-Endpoints, die Third-Party- und Ressourcen-Maps (Anzahl, Größe und Dauer je Kategorie) sowie die Long-Animation-Frame-Attribution je Skript. Die Long-Animation-Frame-Daten brauchen das v2-Beacon-Schema und kommen auf v1 leer zurück.

Der Tracker misst die Core Web Vitals so wie Googles web-vitals-v5-Library und CrUX, damit deine Feldzahlen zur Search Console passen.

• INP ist die CrUX-p98-Schätzung statt der einzelnen schlechtesten Interaktion. Auf interaktionsreichen Seiten liest es sich niedriger: eine Methodenänderung, keine Regression.
• Vorgerenderte Seiten erzeugen keine Phantom-Pageviews oder aufgeblähten Timings mehr; der Tracker aktiviert sich erst mit der Seite und setzt TTFB, FCP und LCP auf diesen Moment.
• Hintergrund-Tabs: Paints nach dem ersten Verbergen des Tabs werden verworfen und der Pageview markiert. CLS zählt Layout-Shifts während des Prerenders weiter, wie CrUX.

Jeder Pageview hält fest, warum ein Web Vital langsam war und welches Element es verursacht hat.

• Phasen: LCP teilt sich in Time to First Byte, Resource Load Delay, Load Duration und Render Delay; INP in Input Delay, Processing und Presentation.
• Elemente: LCP, CLS und INP tragen einen CSS-Selektor-Pfad zum verantwortlichen Element (bei LCP zusätzlich die Bild-URL). Dynamische IDs wie #order-98123 sind nie der Anker; der Pfad fällt auf einen stabilen Elternknoten zurück.
• Browser-Support: LCP-Phasen brauchen Chrome 77, Firefox 122 oder Safari 26.2; INP-Phasen Chrome 96, Firefox 144 oder Safari 26.2; CLS-Attribution gibt es nur in Chromium.

Die Detailseiten der Core Web Vitals zeigen die neue Attribution pro Pageview.

• Phasen-Aufschlüsselung auf LCP und INP: die Metrik in ihre Phasen zerlegt als Kaskade, und dieselben Phasen gestapelt über die Zeit.
• Phasen-Spalte in den Breakdown-Tabellen (langsamste Seiten, nach Seite, Land, Gerät); eine aufgeklappte Zeile bekommt eine darauf eingegrenzte Phasenansicht.
• Element-Targets auf LCP, CLS und INP ranken die am häufigsten verantwortlichen Selektoren, angeführt von einem Hauptverursacher-Hinweis; auf LCP wahlweise nach Bild-URL.
• Der Explorer bekommt die Phasen-Metriken und die INP-Interaktionstyp-Dimension; Besucher-Journey und Beacon-Drawer zeigen Phasen, Element und Interaktionstyp jedes Pageviews.

Die neue Attribution steht über die API bereit. POST /analytics/visitors/detail liefert je Pageview die Phasenaufteilung, die Element-Selektoren und den Interaktionstyp, und die sieben LCP- und INP-Teilmetriken sind in POST /analytics/query abfragbar, mit inp_interaction_type als gruppierbarer Dimension. Ein neues POST /analytics/element-targets reiht die Elemente, die am häufigsten für LCP, CLS oder INP verantwortlich sind (nach Selektor-Pfad, bei LCP auch nach Resource-URL), mit Anteil und Durchschnittswert, site-weit oder pro URL; ein eigener Endpoint, weil die Selektor-Spalten zu hochkardinal sind, um direkt danach zu gruppieren. Wie im Dashboard bleiben diese Felder leer, bis der Browser des Besuchers sie meldet.

Die Visitors-Liste zeigt jetzt standardmäßig Sitzungen mit mindestens drei Seiten statt jedes einzelnen Ein-Seiten-Besuchs, sodass sie auf lesenswerten Journeys öffnet; das Minimum ist einstellbar und bleibt in der URL. Ein neuer Verhaltensfilter Includes page type behält nur Besucher, deren Sitzung einen Pageview eines bestimmten Typs enthält, mit einem Ein-Klick-Checkout für den häufigen Fall „Sitzungen, die den Checkout erreicht haben“.

Network → Cache bekommt ein Raster Performance by cache status: die Kennzahlen (LCP, TTFB, FCP, Page Load, p75) mit einer Zeile je CDN- und Origin-Cache-Status, sodass du auf einen Blick siehst, ob ein MISS hier wirklich langsamer ist als ein HIT und um wie viel. Jede Zeile ist nach ihrem Web-Vitals-Schwellenwert eingefärbt und zeigt ihren Anteil an den Pageviews, im selben Document-Navigation-Scope wie die Verteilung darüber. Die umschaltbare Breakdown-Card bekommt einen Share-Button auf Panel-Ebene, und die Cache-Chart-Cards bekommen den Hover-Share-Button und Deep-Link-Anker, den die Analytics-Panels schon haben.

Der Explorer sind jetzt zwei Seiten, Charts und Table, die sich Zeitraum, Filterleiste und gespeicherte Queries teilen, sodass ein Wechsel zwischen ihnen deine Query nie verwirft. Charts ist eine Multi-Chart-Arbeitsfläche: füge bis zu acht Charts hinzu, jedes mit eigenen Metriken, Gruppierung und Overlays für Vorperiode oder Perzentilbänder, mach sie halb- oder vollbreit und ordne sie per Drag & Drop neu an. Presets (Core Web Vitals, Loading, Traffic, Errors, Cache, Backend) tauschen den Stapel gegen einen kuratierten Satz, und eine gespeicherte Query hält jetzt das ganze Layout fest. Table bekommt über den Zeilen eine Hits-über-Zeit-Linie, damit du siehst, wo der Traffic dahinter entstanden ist.

Die Charts-Seite kann jedem Chart einen zweiten, unabhängigen Filtersatz über denselben Zeitraum überlagern, sodass du Chrome gegen Safari oder ein Land gegen ein anderes vergleichst. Zeig Fall B als gestrichelte Zwillingsreihe auf denselben Achsen (Overlay) oder als zwei Charts pro Card mit geteilter Skala (Side by side). Solange ein Vergleich aktiv ist, zeigt das KPI-Raster oben das Delta B-gegen-A.

Die Besucher-Journey zeigt jetzt den erkannten Page-Type als Chip an jedem Pageview (Product, Category, Cart, Checkout und so weiter), neben den Chips für Navigationstyp und Cache-Status, überall dort, wo eine Site einen sendet oder erkennt. Pageviews ohne Page-Type zeigen keinen.

Sobald eine Shop-Ruleset an ist (pagetype_ruleset), wird Page-Type zu einer vollwertigen Dimension im Dashboard. Du setzt die Ruleset pro Site oder domänenübergreifendem Tracker unter Collection, schlüsselst dann nach Page-Type auf und filterst danach, nimmst ihn als Spalte in die Beacon-Liste, stellst mit dem neuen Preset Page types den Traffic-Mix und die Web Vitals je Typ als Chart dar und öffnest die eingeordnete Ansicht unter Analytics → Pages. Traffic ohne erkannten Typ erscheint als kein Page-Type.

Für Shops auf Shopware 5/6, OXID, Magento oder WooCommerce kann fastmon jeden Pageview jetzt ohne Code auf deiner Seite in einen Page-Type einordnen (Product, Category, Cart, Checkout und so weiter). Schalte pro Site eine Ruleset ein (pagetype_ruleset), und der Tracker liest nur die Body-Controller-Klasse des Shop-Frameworks aus, um den Typ abzuleiten. Standardmäßig aus (gar kein DOM-Read), und ein Server-Timing: pageType-Header hat, falls du einen sendest, weiter Vorrang.

SPA-Routenwechsel (Soft-Navigationen) erfassten bisher keine Loading-Metriken, LCP und FCP für Single-Page-Apps kamen also nur aus kalten Seitenladungen und lasen sich schlechter als die echte Erfahrung. Der Tracker misst das Soft-Nav-Loading jetzt auf zwei Wegen: Route Load (soft_nav_load), einen Same-Site-Netzwerk-Proxy in jedem Browser, und echte LCP/FCP auf Chromium, sobald dessen Soft-Navigations-API ausgeliefert wird. Route Load landet im Dashboard als eigene Metrik, getrennt von LCP/FCP und schrittweise ausgerollt. Wenn die nativen LCP/FCP einlaufen, spiegelt der SPA-LCP/FCP-p75 auch In-App-Navigationen wider, eine Änderung der Messmethodik, keine Regression.

Die Wire-Keys des Beacons wurden kürzer, um pro Request Bytes zu sparen: lifecycle heißt jetzt lcy, die Kampagnenfelder (utm_source & Co., click_id_param) werden zu Zwei-Buchstaben-Keys, und leere Kampagnenfelder fallen ganz weg statt als leere Strings mitzureisen (rund 110 bis 130 Bytes pro Beacon). Die Werte bleiben gleich, und alte gecachte Bundles laufen weiter: der Collector akzeptiert alte und neue Keys dauerhaft.

Eine neue Seite Performance → Backend macht aus deinen Server-Timing-Response-Headern Analytics: eine Request-Pfad-Card (Edge, Origin, Backend) mit jedem Cache-Status und wie viel Traffic welche Phase erreicht, Backend-Subphasen (DB, Cache, External, Render) als Share-of-Backend-Balken, ein Phasen-Trend über die Zeit und eine Matrix, die Phasen nach Seite, Seitentyp oder Cache-Status aufschlüsselt. Jeder nicht-promotete Server-Timing-Key bekommt zusätzlich einen eigenen gerankten Trend. Siehe Server-Timing.

Das Breakdown-Grid (auf Metrik-Detailseiten und aufgeklappten Explorer-Zeilen) bekommt einen Facts / Metrics-Umschalter. Metrics ersetzt die Dimensions-Panels durch je ein kompaktes Panel pro Web Vital (LCP, INP, CLS, FCP, TTFB, Page Load, TBT), auf dieselbe Zeile und dieselben Filter bezogen, sodass du auf einen Blick siehst, ob eine Seite nur bei LCP schlecht ist oder durchweg langsam. Jedes Panel ist der Standard-Perzentil-Trend oder die Verteilung, und die aktive Ansicht bleibt in der URL für teilbare Links.

Nach Minute ist jetzt eine Granularität im Datumswähler für Fenster bis zu 6 Stunden (vorher bei 2 gedeckelt). Kurze Custom-Ranges und relative Spannen wie 3h wählen automatisch Minuten-Buckets; längere fallen weiter auf Stunden oder Tage zurück.

Jede Angabe zu einem Pageview im Besucherverlauf ist jetzt ein key=value-Chip: Navigationstyp (Soft-Nav, Reload, Back/Forward, Prerender), CDN- und Origin-Cache-Status (HIT / MISS, neu), Fehleranzahl und die Web Vitals (FCP, LCP, CLS, INP, TTFB, Load), jeweils nach Schwellenwert eingefärbt. Metriken links, Kontext-Fakten rechts, unter einer schlichten URL-Zeile mit Verweildauer. Chips ohne Wert werden ausgeblendet.

Die Verhaltensfilter auf Visitors (Mindestwerte für Fehler, Seiten, Dauer, durchschnittlicher LCP) stehen jetzt in der URL, sodass Neuladen oder Teilen der Seite dieselbe gefilterte Liste behält.

Das Teilen oder Neuladen eines aufgeklappten Stitch-Besuchers konnte auf „keine Pageviews gefunden" landen: die URL merkte sich nur die Session-Identität, ein Stitch-Wert wurde also in der falschen Spalte gesucht. Die aufgeklappte Zeile merkt sich jetzt ihre Identität in der URL, sodass Neuladen und geteilte Links den richtigen Besucher wieder öffnen. Auch die Verhaltensfilter (?minErrors=…) überstehen den Round-Trip.

Der Tracker hält den Request-Umfang jetzt von Haus aus gering: bei einem schnellen Load fassen sich die ersten zwei Beacons zu einem zusammen, frühe Mid-Pageview-Updates warten auf das finale Beacon, und die Update-Beacons einer pollenden Seite werden gedeckelt. Seiten, die daran etwas ändern müssen, setzen ein paar window-Globals: __FASTMON_SAMPLE_RATE, __FASTMON_INIT_COALESCE_MS, __FASTMON_UPDATE_MIN_AGE_MS und __FASTMON_MAX_VERSION. Die Defaults passen für die meisten Sites. Siehe Der RUM-Beacon.

Die Datenerfassung einer Site ist nicht mehr einer von drei festen Modi. Du wählst beim Anlegen ein Preset (Minimal, Standard oder Full) und stellst danach jede Einstellung einzeln: die On-Device-Session-ID und ihr Consent-Timing, das am Edge abgeleitete Besuchersignal, Query-Parameter-Namen, Fehlermessages und Stack-Frame-Detail sowie die Fetch/XHR-Erfassung. Neue Sites starten auf Standard, das Unique-Visitor-Zahlen und Diagnose einschaltet und trotzdem nichts auf das Gerät des Besuchers schreibt. Die alten collection_mode-Werte laufen als veralteter API-Alias weiter. Siehe Tracker-Einstellungen.

Die Sessions-Seite heißt jetzt Visitors, unter /visitors (alte Links leiten weiter, geteilte Links funktionieren weiter). Stitch und Session sind gleichwertig: der Identitäts-Umschalter startet mit der bevorzugten Identität der Site, und eine Stitch-Zeile klappt in den vollen Pageview-Verlauf dieses Besuchers auf, dasselbe Drill-down wie bei Sessions. Die überflüssige Zähl-Card „Besucher auf dieser Seite" ist weg.

Ein domainübergreifender Tracker (ein Embed über mehrere Domains) trägt jetzt denselben Datenumfang wie eine Site, angewandt auf jede Domain, auf der er läuft; nur das Besuchersignal bleibt pro Domain. Beobachtete Domains, die noch keine Site sind, erscheinen als erkannte Domains, und Als Site hinzufügen legt die Site mit einem Klick an, mit Datenumfang, Collector-Konfiguration und Bundle-Version des Trackers. Siehe Applications.

Ein einzelnes Beacon mit einem nicht-endlichen oder außerhalb des Bereichs liegenden Connection- oder Timing-Wert ließ bisher den ganzen Batch-Insert scheitern und verwarf jedes andere Beacon im selben Flush. Solche Werte werden jetzt pro Feld auf „unbekannt" gesetzt, sodass ein fehlerhaftes oder bösartiges Beacon den legitimen Traffic drumherum nicht mehr mitreißt.

Die Breakdown-Listen auf Analytics (Sources, Seiten, Länder, Devices sowie die Top-Listen in Audience und Cache) bekommen die Hover-Aktionen der Metrik-Detailseiten: + filtert auf einen Wert, − schließt ihn aus. Wo sich eine Dimension nicht ausschließen lässt, ist das − mit Tooltip deaktiviert. Jede Zeile zeigt zusätzlich ihren Anteil am Gesamtwert neben der Zahl (zum Beispiel 12% · 4.3K), berechnet über das ganze Fenster, nicht nur die sichtbaren Zeilen.

Jede Monitoring-Seite liegt jetzt unter einer org-bezogenen URL, und die Site ist ein Filter, der dich wie der Zeitraum von Seite zu Seite begleitet. Ohne ausgewählte Site siehst du die gesamte Organisation aggregiert, und der Umschalter in der Seitenleiste hat einen eigenen Zustand Alle Sites. Der Umschalter erlaubt jetzt Mehrfachauswahl: Ein Klick auf eine Site springt zu ihr, per Checkbox (oder Cmd/Strg-Klick) kombinierst du mehrere. Site-Tags grenzen die Daten jetzt wirklich ein, mehrere Tags werden mit UND verknüpft; der alte, wirkungslose Tag-Selektor ist weg. Alte Site-Links funktionieren weiter über eine dauerhafte Weiterleitung, die die Site als Filter übernimmt. In der Cmd+K-Palette schränkt die Eingabe org: die Suche auf Organisationen ein.

Ein neuer farbenblind-freundlicher Modus unter Account, Darstellung stellt die Status- und Diagrammpalette auf ein rot/grün-sicheres Schema um (Blau, Orange, Zinnoberrot), sodass die Bewertungen Gut / Verbesserungswürdig / Schlecht überall im Dashboard, in den Diagrammen, der Geo-Karte und den Heatmaps als Blau, Orange und Rot erscheinen. Status-Indikatoren tragen zusätzlich Symbole, damit die Bedeutung nie allein von der Farbe abhängt. Die Einstellung wird auf deinem Gerät gemerkt.

Der KI-Assistent „Ask“ hat dieselbe Antwort manchmal zweimal gestreamt und doppelt gespeichert, sodass sie doppelt erschien und nach einem Neuladen doppelt blieb. Eine Ausgabeprüfung hat die Antwort neu erzeugt, nachdem sie bereits gesendet war; diese Selbstkorrektur ist entfernt, und die Prüfung protokolliert Auffälligkeiten jetzt nur noch, statt ein erneutes Senden auszulösen. Jede Antwort wird einmal gesendet und einmal gespeichert.

Die Cache-Seite ist um die drei Schichten herum gebaut, die ein Request durchläuft, mit einem Umschalter Browser / CDN / Origin.

• Dieselben Panels pro Schicht: Trefferquote, Statusverteilung, Cache-Status über die Zeit (absolut/prozentual, Legende zum Isolieren per Klick) und Seiten-Attribution.
• Browser-Cache ist um wiederkehrende Views (Reloads, Vor/Zurück) herum gefasst, ohne Gut/Schlecht-Bewertung; eine Zahl „Erste Navigationen" gibt Kontext.
• CDN und Origin lesen native Trefferquoten-Metriken und schließen Soft-Navigationen aus, die keinen Cache-Status tragen.
• Ressourcen nach Typ: Script, CSS, Bilder, Fonts und Sonstiges, umschaltbar zwischen Anzahl und Bytes. Das Dashboard bekommt ein kombiniertes Cache-Widget mit demselben Umschalter.

Release-Marker funktionieren jetzt auf jedem Chart gleich. Die Charts der Analytics-Seite (Besucher, Seitenaufrufe, Aufrufe pro Besuch) zeigen sie erstmals, und jedes Zeitreihen-Chart zeichnet sie aus einer gemeinsamen Implementierung, sodass App- und Tracker-Marker überall identisch aussehen und sich gleich verhalten. Charts, die einen Release bisher verbargen, wenn er im gewählten Zeitraum, aber außerhalb der geladenen Daten lag (LCP, Cache-Trefferquote, Synthetic, Explorer), zeigen nun jeden Release im Bereich. Auch das Hover ist überarbeitet: Ein Band am oberen Chart-Rand macht die Marker leicht greifbar, dicht beieinanderliegende Marker werden zu einem Ziel mit Zähler zusammengefasst, und der Marker-Tooltip kollidiert nicht mehr mit dem Daten-Tooltip des Charts und wird am Rand nicht mehr abgeschnitten.

Der Umschalter Über die Zeit / Verteilung / Beides auf den Metrik-Detailseiten (LCP, FCP, CLS, INP, TTFB, Seitengewicht) wird jetzt in der URL abgebildet, und das Panel hat einen Teilen-Button. Ein kopierter Link öffnet exakt diese Ansicht wieder, mit fixiertem Zeitraum. Geteilte Links auf eine Panel-Ansicht oder ein Breakdown-Unter-Panel behalten ihre Ansicht (die Parameter view, pview und panel überstehen jetzt die Navigation) und scrollen vollständig zum Ziel-Panel.

Die langsamsten/schlechtesten Seiten, die Breakdown-Grids sowie die Cache- und Fehler-Attributionstabellen verbergen Zeilen mit wenig Volumen nicht mehr hinter einer Grenze von ≥ 1 % der Seitenaufrufe (mind. 30). Jede Zeile wird angezeigt; nach Volumen grenzt du selbst im Explorer ein (zum Beispiel beacons:ge:N). Eine reine Zähl-Metrik (Requests / Visitors) neben einer Wert-Metrik zwingt die ganze Tabelle nicht mehr auf Count: Jede Spalte nutzt ihre eigene Aggregation, sodass LCP sein p75 statt einer sinnlosen Zahl zeigt. Für die Explorer-KPI-Kacheln gilt dasselbe.

Im Explorer kannst du jetzt nach einer kategorialen Dimension gruppieren, etwa dem CDN- oder Origin-Cache-Status, und als Linie, gestapelte Linie oder gestapeltes Balkendiagramm darstellen, wie sich die einzelnen Werte (HIT, MISS, EXPIRED) über die Zeit entwickeln, statt nur die aggregierte Aufschlüsselung zu sehen. Gestapelte Ansichten schalten zwischen 100 % (Anteil je Wert pro Intervall) und absoluten Zahlen um. Eine zweite Metrik wie TTFB lässt sich als gestrichelte Linie auf einer rechten Achse zur Einordnung überlagern. Eine Group-by-Dimension erzwingt nicht mehr das Balkendiagramm: Linie, Stapel und Kreis bleiben erhalten, wo sie sinnvoll sind, und der Diagrammtyp-Auswähler graut Optionen aus, die die aktuelle Abfrage nicht darstellen kann.

Verhältnis-Metriken wie die Cache-Trefferquote werden in den Explorer-Diagrammen und -Tabellen jetzt als echter Prozentwert dargestellt (zum Beispiel 80 %) statt als „0,8 %“.

Die Verteilungs-Metrik-Cards im Dashboard zeigen jetzt die Aufteilung Gut / Verbesserungswürdig / Schlecht als farbcodierte Prozentwerte im Card-Kopf, für jede Metrik mit Schwellwerten (die Core Web Vitals plus FCP, TTFB und Seitenladezeit), während Bewertungs-Badge und Trendpfeil an ihrem Platz bleiben. Das Histogramm der Card ist größer, und seine Balken lassen sich jetzt sowohl für Details überfahren als auch anklicken, um die Metrik-Detailseite zu öffnen.

Die Zeilen der „Woran es liegt“-Aufschlüsselung haben jetzt Hover-Aktionen + / −, um einen Wert direkt zu filtern oder auszuschließen, passend zu den Grid-Panels je Zeile. Für Dimensionen, die sich nicht ausschließen lassen, etwa Seiten-URLs, wird Ausschließen mit Begründung deaktiviert angezeigt. Jedes Breakdown-Panel hat außerdem einen Teilen-Button, der direkt auf dieses Panel verlinkt; beim Öffnen des Links wird dorthin gescrollt und das Panel kurz hervorgehoben.

Ein Aufräumen der Detailseiten.

• Die Werteverteilung lebt nur noch im oberen Panel „Über die Zeit" und wird unten nicht mehr wiederholt.
• Breakdown-Panels zeigen den Anteil jedes Werts an den Pageviews neben der Anzahl, und Share-Links stellen die gewählte Chart-Ansicht einer aufgeklappten Zeile wieder her.
• CDN- und Origin-Cache-Breakdowns bekommen einen Eimer „unbekannt", der nur erscheint, wenn mindestens 1 % der Views einen bekannten Cache-Status haben.
• Der Button „Im Explorer öffnen" auf der Fehlerseite ist weg; der Drill-down läuft über die Tabellen.

Als ad-geblockt verworfene Tracker-Aufrufe waren bereits aus deiner Fehlerrate ausgeschlossen, aber nirgends ausgewiesen. Die Read-APIs geben diese Zahl jetzt zurück: Die Fetch/XHR-Endpunkt-Aufschlüsselung und das Detail je Beacon enthalten eine blocked-Zahl neben aborts, und die Fehlertypen-Übersicht liefert ein neues blocked_count. Deine Fehlerrate bleibt unverändert; das macht nur sichtbar, wie viele Aufrufe ausgeschlossen wurden, sodass das Dashboard „N als ad-geblockt ausgeschlossen“ anzeigen kann, statt sie still zu verwerfen. Siehe die API-Referenz.

Jede Metrik-Detailseite (LCP, INP, CLS, TBT, Seitengewicht und die Ladezeit-Seiten) beginnt jetzt mit einem einzigen „Über die Zeit“-Panel, das du zwischen dem Perzentil-Verlauf, der Werteverteilung oder beidem nebeneinander umschaltest. Die Verteilungs-Buckets und die Gut/Schlecht-Zonen sind klickbar: Sie öffnen den Explorer eingegrenzt auf diesen Wertebereich und übernehmen deinen aktuellen Zeitraum. Kurze Zeitfenster (2 Stunden oder weniger) werden jetzt minutengenau statt stündlich dargestellt, sodass eine Ein-Stunden-Ansicht nicht mehr fast leer ist.

Jede Metrik-Detailseite hat jetzt eine Aufschlüsselungs-Tabelle, die du über mehrere Dimensionen umschalten kannst (Seite, Land, Gerät, Browser mit oder ohne Version, Verbindung sowie CDN-/Origin-Cache), mit einer TTFB-Spalte zur Einordnung und einem Umschalter Meistgesehen / Schlechteste / Beste. Klappst du eine Zeile auf, erscheint dasselbe „Über die Zeit“-Panel, eingegrenzt auf diesen Wert, plus ein Raster der übrigen Dimensionen, in dem du direkt auf einen Wert filtern, ihn ausschließen oder im Explorer öffnen kannst. Diese aufklappbare Ansicht ist auf den Detailseiten und im Explorer dieselbe: Eine gruppierte Ergebniszeile im Explorer öffnet genau dasselbe Panel und Raster.

Ein Schnellfilter Alle / Desktop / Mobil sitzt jetzt neben der Zeitauswahl auf den Metrik-Detailseiten, dem Dashboard und in Analytics und setzt denselben Gerätefilter wie die Filterleiste. Die Toolbar (Perzentil · Zeitraum · Gerät · Filter · Aktualisieren) ist über diese Ansichten hinweg jetzt identisch.

Eine Runde Explorer-Arbeit.

• Filterzeilen beschriftet als Abfrage-Filter (Server) und Ergebnis-Filter (Browser), in einer Zeile.
• Die Statusfarbe ist bei Wert-Metriken immer an; Zähl-Metriken klappen zum Breakdown-Raster und einem Trend auf.
• Breadcrumb-Drill-down: „Core Web Vitals › LCP › Explorer", mit einem Zurück-Pfeil an die exakte Stelle, aufgeklappte Zeile inklusive.
• Share-Links fixieren den Zeitraum auf absolute Zeitstempel.
• Die eigenständige Ansicht „Seiten" ist zugunsten von Analytics eingestellt.

Übertragungsgrößen und Seitengewicht skalieren jetzt bis GB und TB, statt bei MB zu deckeln (ein Gesamtwert von ~1 TB liest sich nicht mehr als „1069213.0 MB“), und große Aufrufzahlen von Drittanbietern werden kompakt angezeigt (zum Beispiel „1,1 Mio.“) mit der vollen Zahl beim Überfahren. Auf kleinen Bildschirmen läuft das aufgeklappte Aufschlüsselungs-Raster nicht mehr aus dem Bild, seine Zeilenaktionen sind auf Touch-Geräten immer sichtbar, und die Zeitauswahl ragt nicht mehr über den linken Rand hinaus.

Third-Party-Tracker, die von einem Ad-Blocker oder Tracking-Schutz geblockt werden (Bing UET, Meta Pixel, Google Tag Manager und Ähnliche), zählen nicht mehr als Fehler, ebenso wenig Requests, die der Browser abbricht, wenn ein Besucher die Seite verlässt. Sie werden markiert und behalten, nicht verworfen, sodass deine Fehlerrate echte, behebbare Probleme abbildet. Ein reales Dashboard fiel von rund 60 % Fehlerrate, die fast vollständig von einem geblockten bat.bing.com verursacht war.

Wenn ein Besucher die Seite verlässt oder den Tab schließt, bricht der Browser laufende Requests ab und kann ausgeführte Skripte unterbrechen. Der Tracker erkennt den Teardown jetzt (über pagehide und visibilitychange) und zählt solche Netzwerkfehler als Abbrüche statt als Fehler; außerdem verwirft er die während des Teardowns geworfenen JavaScript-Ausnahmen. So bläht beides die Fehleranzahl nicht mehr auf.

Melde dich mit einem Geräte-Passkey in einem einzigen Schritt an, ganz ohne Passwort und ohne separaten 2FA-Code. Passkeys verwaltest du unter Konto → Sicherheit (hinzufügen, benennen, umbenennen, entfernen). Sensible Aktionen (API-Key neu generieren, 2FA umschalten, E-Mail ändern, App verbinden, Konto löschen) erfordern jetzt eine erneute Authentifizierung („Step-up") mit deinem stärksten hinterlegten Faktor: einem Passkey oder TOTP.

Neue Spalten für CDN- und Origin-Cache (HIT/MISS) sowie ein Cache-Status-Filter im Beacon-Explorer.

Der Fehler-Drilldown der KI-Funktion „Ask" liefert seine Zusammenfassung und Zeitreihe jetzt korrekt, statt bei jedem Aufruf fehlzuschlagen.

Betreibe einen einzigen Tracker über mehrere Domains derselben Codebasis (z. B. shop.de und shop.fr); Beacons werden automatisch der passenden Site je Domain zugeordnet, sodass Analytics und Zugriffsrechte pro Site erhalten bleiben. Anlegen, Bearbeiten, Hashes rotieren und Löschen erledigst du auf der Sites-Seite der Organisation, inklusive einer Liste „erkannter Domains", die nicht registrierte Hosts als neue Site vorschlägt.

Als Partner markierte Organisationen können Kunden-Organisationen anlegen und verwalten: einen Kunden erstellen (auf Wunsch mit Owner-Einladung per E-Mail), verwaltete Kunden auflisten, die aggregierte Beacon-Nutzung einsehen und einen Kunden wieder ablösen. Unter Organisation → Team werden zudem die Partner aufgeführt, die deine Organisation verwalten dürfen; Owner können diesen Zugriff widerrufen.

Der bisher binäre Umschalter fastmon / First-Party ist jetzt dreistufig, jeweils mit einem First-Party-/Third-Party-Badge: Default (fastmons Collector), Custom (eine URL, die du selbst kontrollierst) und Relative (ein Same-Origin-Endpoint /c/<hash>). (API: ein neues Feld collector_mode an Sites und Trackern.)

DELETE /sites/{id} schlägt nicht mehr fehl, wenn zur Site Releases, Wochenübersichten oder Feedback gehören.

Internationalisierte Hostnamen (z. B. münchen.de) und FQDNs mit Punkt am Ende wurden bei der Aufnahme abgewiesen oder verworfen; Hostnamen werden jetzt bei Registrierung und Aufnahme einheitlich normalisiert.

Beacons speichern jetzt den Host, den der Tracker tatsächlich gemeldet hat, statt der konfigurierten Site-Domain. So stimmt die Aufschlüsselung pro Domain wieder. Bestehende Zeilen behalten ihren alten Wert.

Im Anonymous-Modus fallen unterschiedliche defekte First-Party-Ressourcen auf demselben Host nicht mehr zu einem einzigen Fehler zusammen (gilt für neue Beacons).

Neues Feld browser_version in der Visitors-Liste und fünf neue wählbare Spalten für /analytics/beacons (version, tracker_version, site_id, lifecycle, delivery_method). Siehe die API-Referenz.

Median- und Perzentilwerte für Web Vitals in der Langzeitauswertung werden genauer berechnet; das korrigiert eine systematische Unterschätzung des Medians.

Die überarbeitete Auswahl beginnt mit einem absoluten Bereich, der auch relative Eingaben akzeptiert (now-6h oder Kurzformen wie 4h / 30d); relative Bereiche bleiben gegenüber „now" live, mit einer „Now"-Schaltfläche und dem Tastenkürzel r zum Aktualisieren. Metrik-Schwellen lassen sich jetzt in natürlichen Einheiten eingeben, z. B. lcp >= 2.5s oder total_byte_weight < 512kb.

Das Filtern der Visitors-Liste nach Gerätetyp, Browser, Land oder Betriebssystem löst keinen Fehler mehr aus.

Die Metrik sessions ist überall durch visitors ersetzt: in Charts, der Metrik-Auswahl und den Alert-Regeln. Ein Visitor wird über eine Identität gezählt: stitch (am Edge abgeleitet, einwilligungsfrei, der Standard) oder session (einwilligungspflichtig). Der Explorer hat einen Umschalter zwischen Stitch und Session samt Identitäts-Badge je Zeile bekommen, und jede Site hat eine neue Einstellung für die Standard-Identität von Visitors. Siehe Visitors und Sessions.

fastmon kann First-Party-App-Integrationen autorisieren: ein In-App-Zustimmungsdialog und der Tab „Verbundene Apps" in den Kontoeinstellungen, in dem du autorisierte Apps einsehen und trennen kannst.

Die Marke wird jetzt überall kleingeschrieben: in der App, bei der Authentifizierung, in E-Mails und in den SEO-Metadaten.

Das Annehmen einer Einladung wirft dich nicht mehr in eine zweite, leere Organisation, auch nicht bei der Anmeldung über Google oder GitHub.

Der Tracker behält den vollständigen minifizierten Stack-Frame-Pfad, damit JavaScript-Fehler auf die korrekte Quellposition zurückgeführt (de-minifiziert) werden können.

Der Tracker meldet jetzt jeden Fetch/XHR-Aufruf bereits während eines Pageviews, nicht nur langsame Ausreißer. So ist die Fetch/XHR-Ansicht vollständig.

Die Detailseiten für Core Web Vitals und Performance/Network zeigen die Verteilung der Metrik mit Zonen für Gut / Verbesserungswürdig / Schlecht und Markern bei p50/p75/p90; jede Zeile einer Seite klappt zu ihrer eigenen Verteilung auf. Über Teilen-Schaltflächen öffnest du exakt diese Seite oder Zeile wieder; gleichzeitig kamen die Fehler-Aufschlüsselung pro Seite sowie Filter mit mehreren Werten und Ausschluss-Filter (≠) hinzu.

Der Tracker markiert client-seitige Routenwechsel als nav_type=softnav, sodass Navigationen in Single-Page-Apps in der Auswertung von vollständigen Seitenladungen unterschieden werden.

Eine eigene Seite unter Network analysiert die Fetch/XHR-Aufrufe deiner App: p75/p95-Latenz (Tail), ein Filter für blockierende Aufrufe, Abbrüche getrennt von Fehlern, die Antwortgröße, ein Mini-Wasserfalldiagramm der Backend-Phasen je Aufruf sowie ein Umschalter zwischen First-Party, Third-Party und allen Aufrufen. Die Erfassung steuerst du je Site über den Schalter „Subrequests speichern". Siehe Analytics.

Ein Tab für den Gerätetyp (Desktop / Mobil / Tablet), ein „Auto"-Theme, das der Hell-/Dunkel-Einstellung des Betriebssystems folgt, und ein deutlich ausführlicheres Detail-Panel je Beacon (Server-Timing-Phasen, Cache-Status, aufgerufene Endpoints, Attribution).

Ein durchsuchbares Menü steuert die ganze App: zu jeder Seite springen, Organisation oder Site wechseln, Zeitraum und Granularität ändern, Filter setzen oder entfernen. Die Filtersteuerung ist zudem in den Header gewandert, neben die Zeitraum-Auswahl, mit einem Zähler-Badge für aktive Filter.

Der Tag-Filter in der Sidebar schränkte nur die Site-Liste ein und beeinflusste die Analytics nie; deshalb wurde er entfernt. Tags sollen als echte site-übergreifende Auswertung zurückkehren. Siehe Sites.

Der persönliche Zugriffstoken heißt jetzt durchgängig API-Key: in der API, den SDK-Beispielen und den Kontoeinstellungen. Anmeldedaten und Verhalten bleiben gleich, nur der Name hat sich geändert (passend zum Backend). Siehe Authentifizierung.

Bei Sites im Full-Collection-Modus ließ der Drilldown pro URL unbemerkt Zeilen weg; er liefert jetzt die vollständige Aufschlüsselung.

Analytics-Abfragen über kurze Zeitfenster lassen sich jetzt minutenweise aggregieren (zusätzlich zu Stunde und Tag), sodass ganz aktueller Traffic und Vorfälle in der richtigen Auflösung sichtbar werden.

Ein datenschutzorientierter Umbau am Edge: Der Edge leitet alles ab, was fastmon benötigt (Land, Gerät, Referrer-Quelle), und das Backend erhält die rohe IP-Adresse, den User-Agent-String und die vollständige Referrer-URL nie. So werden bewusst weniger personenbezogene Daten gespeichert. Siehe Datenschutz.

Ein neuer, am Edge abgeleiteter Identifier mit begrenzter Lebensdauer (stitch) verknüpft Pageviews desselben Besuchers ohne Cookies und ohne Einwilligung. Er wurde später zur Standard-Identität für Visitors. Siehe Visitors und Sessions.

Traffic trägt jetzt utm_*-Parameter und Click-IDs von Werbeplattformen, sodass du Analytics nach Kampagnen-Quelle, -Medium und -Kampagne aufschlüsseln kannst (Plausible-konform).

Statt einer rohen Referrer-URL werden Referrer in eine normalisierte Quelle und ein Medium einsortiert (Snowplow-Stil), sodass die Referrer-Aufschlüsselung sauber und gruppierbar ist.

Der Tracker erfasst device_memory, hw_concurrency, save_data, prefers_dark und prefers_reduced_motion nicht mehr: eine Datenminimierung, die die übertragene Datenmenge und die pro Besucher gespeicherten Daten verringert.

Der Tracker liest document.referrer und matchMedia nicht mehr und wertet den User-Agent nicht mehr aus (das übernimmt jetzt der Edge), wodurch das eingebundene Skript kleiner wird und weniger Daten sendet.