Changelog

fastmon hält jetzt Veränderungen fest, die es von selbst erkennt, jede mit Beginn und Ende. Beobachtungen waren eine Admin-Vorschau und stehen jetzt jeder Rolle einer Organisation mit dem Watchdog-Feature offen.

• Shifts vergleichen eine Viertelstunde Traffic, TTFB, LCP, JavaScript-Fehler oder Bots mit derselben Viertelstunde an den 7 Tagen davor. Eine Verschlechterung erscheint nach 30 Minuten, alles andere nach 2 Stunden.
• Trends vergleichen die letzten 7 Tage von LCP, INP, CLS, TTFB oder Fehleranteil mit den 14 Tagen davor, einmal täglich. Ein offener Trend sagt, seit wann die Metrik auf dem neuen Niveau liegt.
• Als gesehen markieren nimmt eine Beobachtung aus den offenen, mit einer Notiz für das Team. Sie verlässt die Karten und den Zähler in der Seitenleiste und endet weiter von allein. Owner und Member können markieren.
• Die Wochenmail nennt die offenen Trends einer Application nach der Tabelle, und die Trends, die besser wurden, als gute Nachricht. Ein offener Trend ersetzt den Wochenvergleich seiner Metrik.

Doku: Beobachtungen.

Einen Fehler auf der Seite JavaScript-Fehler kannst du als gesehen markieren, mit einer Notiz für das Team. Die Liste zeigt standardmäßig die offenen Fehler, die gesehenen hinter einem Schalter. Die Markierung gilt für den Fehler selbst, ein Deploy, der das Bundle verschiebt, behält sie.

Die Fehlerrate und jede Summe zählen den Fehler weiter, und der Wochenüberblick öffnet keinen neuen Befund dafür. Owner und Member können markieren, und ein gesehener Fehler lässt sich auf seiner Seite wieder öffnen.

Beobachtungen und Fehler-Signaturen lassen sich über die API als gesehen markieren. Beides braucht die neue Berechtigung observation:write, die Owner und Member haben.

• PATCH /observations/{observation_id} mit status: acknowledged markiert eine Beobachtung als gesehen, status: open nimmt es zurück, und note fasst bis zu 1.000 Zeichen. Beide Listen und der Zähler in der Seitenleiste überspringen eine gesehene Beobachtung unter status=open. Sie steht unter status: acknowledged, bis sie endet.
• POST /organizations/{org_id}/error-acknowledgements mit dem fingerprint einer Fehlerzeile markiert den Fehler als gesehen, mit optionaler note. GET auf demselben Pfad listet sie, PATCH /error-acknowledgements/{acknowledgement_id} ändert die Notiz, und DELETE öffnet die Signatur wieder.
• Die Fehlerliste trägt status in jeder Zeile von POST /analytics/error-types, open oder acknowledged, und nimmt ihn als Filter. Ohne Filter liefert sie beide.
• Audit-Einträge observation.updated, error.acknowledged und error.reopened halten jede Änderung fest.
• Beobachtungen tragen reference_unit, eins von share, page_views, milliseconds oder days. Ein Trend trägt evidence.since.

• navigator.webdriver zählt als bot, auch wenn der Besucher als hyperactive oder unnamed markiert war. Der Bot-Filter blendet ihn jetzt aus. Zuvor geschriebene Zeilen behalten ihr Label.
• ua_anomaly hat zwei neue Werte. hyperactive markiert einen Besucher mit mehr als 1.000 Beacon-Requests in einer laufenden Stunde, für 24 Stunden. unnamed markiert einen Desktop-Client, dessen User-Agent keinem Browser und keinem bekannten Bot zuzuordnen war. Beide zählen als suspect und fallen aus der Sicht auf Menschen heraus.
• Das Besucher-Stitching rotiert um 02:00 UTC statt 24 Stunden nach dem Start des Edge, damit ein Besucher tagsüber nicht mehr in zwei zerfällt.

Doku: Datenschutz → Der stitch-Identifier.

• Filter bearbeitest du in einem Pop-up. „Filter“ im Header, ein Filter-Chip oder die Taste f öffnet es: links die aktiven Filter, rechts die Werte des offenen Filters nach Name und nach Seitenaufrufen, dazu ein Katalog aller Felder. Nichts ändert sich vor „Anwenden“.
• Perzentil, Vergleich, Gerät und Traffic bleiben als kleine Menüs im Header und wirken sofort. Die gespeicherten Abfragen des Explorers sind ins Pop-up gewandert.
• Browser und Browser-Version sind ein Filter. Der Versionsbereich steht unter den gewählten Browsern.
• Explorer-Filter und Sortierung laufen auf dem Server. Der Trichter einer Spalte filtert jeden Seitenaufruf, nicht nur die 50 auf dem Bildschirm. Spalten wählst du in einem Pop-up und ziehst sie in die Reihenfolge.
• Ein Seitenaufruf öffnet sich als Pop-up, und Links und Rechts blättern durch die Liste.
• Kürzel: v maximiert das Diagramm oder die Tabelle unter der Maus, ? listet jedes Kürzel, l startet und stoppt den Live-Modus. r aktualisiert, und das Symbol dreht sich, bis die Daten da sind.

Doku: Analytics.

• Der Application-Picker sucht. Tippe eine Application, eine Domain oder einen Tag. Domains stehen gruppiert unter ihrer Application, Development-Applications in einer eigenen Gruppe, und ein Punkt zeigt, ob eine Domain in den letzten 24 Stunden Daten geschickt hat.
• Mehrere Domains oder Tags wechselst du auf einmal. Der Kreis am Ende einer Zeile sammelt sie, und „Anwenden“ wechselt zu allen.
• Der Organisations-Picker funktioniert genauso, mit den zuletzt geöffneten Organisationen oben und deiner Rolle und deinem Plan unter jedem Namen.
• Die Account-Seite ist aufgebaut wie die Application-Einstellungen. Profil, Darstellung, Sicherheit, Benachrichtigungen und Zugriff zeigen, was gesetzt ist, und deine Organisationen stehen unter Profil. Alte Links auf die Tabs öffnen weiter den richtigen Abschnitt.
• Das Avatar-Menü öffnet Account, Benachrichtigungen und API-Keys direkt und stellt Theme und Sprache mit beschrifteten Schaltern um.

• Ein neuer Fehler ist erst ein Alarm, wenn er Besucher erreicht hat. Unter 0,5 % der Seitenaufrufe der Woche heißt er „Verbesserungsbedarf“, nicht „schlecht“.
• Die Schwere wählt die drei Befunde einer Application. Drei neue Fehler verdrängen keine LCP- oder TTFB-Verschlechterung mehr aus der Mail.
• Eine Verschlechterung, die in beiden Wochen dieselbe Zahl druckt, entfällt, etwa 1.180 zu 1.245 ms, beide als 1,2 s.
• „Eine Seite lädt schneller“ öffnet diese Seite, mit der Vorwoche daneben.
• Eine Metrik, die schlecht bleibt, hat einen eigenen Titel, etwa „Fehlerrate weiterhin hoch“, und die mittlere Bewertung heißt „Verbesserungsbedarf“ wie im Dashboard.
• Die Seite ist aufgebaut wie die Metrik-Seiten: zwei Kacheln zählen die Befunde, der Einleitungsabsatz der Mail folgt, und „Über mehrere Wochen“ nennt die offenen Trends, die die Mail schon hatte.

• Ein Fehler, der in eine andere Zeile derselben Datei gewandert ist, bleibt eine Zeile. Die Liste gruppiert nach Typ, Form der Meldung und Datei, ein Deploy, der das Bundle verschiebt, macht aus einem bekannten Fehler also keinen neuen. „Neu“ und „Nimmt zu“ vergleichen auf derselben Gruppierung.
• Ein Script vom Host einer deiner Sites ist auf jeder Seite der Application First Party. Das Bundle eines Shops auf einem Übersetzungs-Proxy oder einer Preview-Domain ist nicht mehr Third Party. Eine Zeile, deren Vorkommen sich widersprechen, heißt „Gemischt“.
• Raten auf gesampelten Applications stimmen. Der Anteil betroffener Seitenaufrufe, die Top 5 und die Spalte Seitenaufrufe nehmen gewichtete Seitenaufrufe, das Diagramm liegt also nicht mehr über 100 %.
• /analytics/query gruppiert nach errors.fingerprint liefert error_beacons und error_rate.

Das Dashboard ist von oben nach unten neu gebaut. Ein Statusband sagt, ob Besucher kommen, das Tracking läuft und Beobachtungen offen sind. Besucher-Kacheln und ein Experience-Panel zeigen, was sich geändert hat, und jede Kachel öffnet ihre Seite.

• Das Experience-Panel hat den Score oben und acht Metrik-Kacheln darunter, jede mit Wert, Bewertung, Veränderung und dem Anteil guter und schlechter Seitenaufrufe. Eine Kachel wählt das Diagramm darunter.
• Die Antwort-Aufschlüsselung läuft über alle Seiten, von DNS über die Server-Timing-Phasen bis zum LCP, je Seitentyp oder Seite. Ihre zweite Ansicht reiht Seitentypen oder Seiten nach LCP, INP, TTFB und Fehlerrate.
• „Wohin die Zeit geht“ teilt den LCP in seine vier Phasen und zeigt das erste Byte mit und ohne Cache-Treffer.
• Der Globus färbt Länder nach LCP, TTFB oder Traffic und maximiert wie ein Diagramm. Ein maximiertes Diagramm steht als max= in der Adresse, ein Link öffnet es also.
• Weniger Abfragen: Die Karten eines Breakdown-Rasters laden, sobald sie ins Bild scrollen.

Seiten ist ein neuer Eintrag in der Seitenleiste unter Untersuchen. Er listet zuerst deine Seitentypen, dann jede Seite nach URL mit Suche, jeweils mit LCP, INP, CLS und Seitenaufrufen, sortiert nach Seitenaufrufen oder nach dem schlechtesten Wert.

Jede Seite und jeder Seitentyp öffnet eine eigene Seite, aufgebaut wie die LCP- und TTFB-Seiten. Oben stehen die vier Metriken, ein Klick auf eine öffnet darunter ihre Metrik-Seite, eingegrenzt auf diese Seite oder diesen Seitentyp. Ein Seitentyp endet mit der Liste seiner Seiten, und ein Button öffnet die Seite im Explorer.

Das Budget von Ask zählt pro Tag statt pro Minute, eine zweite Frage direkt nach der ersten wird also nicht mehr abgelehnt. Ist das Tagesbudget aufgebraucht, antwortet Ask ab 00:00 UTC wieder.

Der Experience Score lässt die Ladezeit weg und bewertet nur noch Fehler aus deinem eigenen Code.

• Neue Gewichte: LCP 0,25, INP 0,20, CLS 0,15, FCP 0,15, Fehlerrate 0,15 und TTFB 0,10. Jeder Score verschiebt sich, manche Noten ändern sich.
• first_party_error_rate ist die bewertete Fehlerrate, gut bis 1 % und schlecht über 5 %. Daneben steht third_party_error_rate, unbewertet.
• error_rate zählt weiter jeden JavaScript-Fehler, wird aber nicht mehr bewertet. In POST /analytics/experience-score bleibt sie als veralteter Eintrag ohne Score.
• Überall dieselbe Rate: Die Wochenmail, die Vorlage „Fehlerrate zu hoch“ und die Zuverlässigkeits-Kachel im Dashboard nehmen die First-Party-Rate. Bestehende Alert-Regeln bleiben, wie sie sind.

Kein Score sinkt, und Sites mit Third-Party-Fehlern steigen. Doku: Experience Score.

INP, CLS, FCP, TBT, Ladezeit, DNS, Connect und Transfergröße haben jetzt Seiten wie LCP und TTFB. Jede zeigt den Wert mit Trend, die Seitenaufrufe nach Bewertung, eine Zusammenfassung, die Verteilung und eine Tabelle, wo die Metrik am schlechtesten ist.

• INP teilt die langsamste Interaktion in Input Delay, Processing und Presentation auf.
• INP und CLS listen die Elemente hinter dem Wert, INP und TBT die Skripte in Long Animation Frames.
• Transfergröße zeigt das Gewicht pro Ressourcentyp und eine Rangliste der Third-Party-Domains.
• Vergleichen geht auf allen acht Seiten und sitzt jetzt im Filter, als Chip mit einem x zum Beenden.
• Ein gesetzter Filter färbt den Filter-Button schwarz, im Dark Mode weiß.

Die Zusammenfassung schreibt POST /analytics/metric-summary, mit dem neuen Satztyp level und facts.unit. Doku: Web Vitals.

Die Analytics-Seite ist neu aufgebaut, aus Karten, die alle gleich funktionieren.

• Karten: Ein Menü wählt die Dimension, und jede Karte blättert durch ihre Zeilen. Der Kartentitel öffnet alle Werte mit Suche, zweiter Dimension, Sortierung und CSV-Download.
• Seiten bekommen eine breite Karte mit Seitenname, URL und LCP.
• Bestellungen erscheinen als Linie oder als drei Bahnen: Warenkorb, Checkout erreicht und bestellt. Die Conversion-Kachel steht bei jedem Zeitraum.
• Seitenaufrufe lassen sich nach Menschen und Bots aufteilen, pro Bot oder pro Bot-Typ. Die Aufteilung ändert nur das Diagramm.
• Live: Eine Zeile über dem Diagramm zeigt die Besucher gerade jetzt, und „Live ansehen“ öffnet einen Ticker der neuesten Bestellungen oder Events.
• Besucherwege: Funnel und Käufervergleich teilen sich eine Karte, und die Besuchstiefe zeigt, wie viele Seiten ein Besuch erreicht.
• Diagramme zeichnen jeden Bucket an seinem Ende, die laufende Stunde gestrichelt bis zur Hochrechnung. Releases sind eine dünne lila Linie.

Statuscodes sind von der Analytics-Seite verschwunden. Filtern auf „Direkt / keine“ und andere leere Werte bleibt vorerst aus. Doku: Analytics.

Diagramme haben drei neue Auflösungen, und Buckets ab sechs Stunden beginnen nach deiner Uhr.

• Auto nimmt die kleinste Breite mit höchstens 300 Buckets. Die letzten 24 Stunden zeigen 5-Minuten-Buckets, 48 Stunden 15-Minuten-Buckets, ab 28 Tagen gibt es Tage.
• Feine Breiten schneiden ein langes Fenster auf seinen letzten Teil zu: Minuten auf 25 Stunden, 5 Minuten auf 5 Tage, 15 Minuten auf 15 Tage. Die Kachel sagt das dazu.
• Deine Zeitzone: Ein Tag beginnt um deine Mitternacht, eine Woche am Montag, ein Monat am Ersten. Bei der Zeitumstellung hat ein Tag 23 oder 25 Stunden.
• Die Uhrzeit steht in Tooltips und Achsen jedes Diagramms unter einem Tag, auch in Ask.
• Conversion und Bestellstufen folgen der Auflösung des Diagramms bis zu einem Tag.

Doku: Analytics.

Das Ausdrucksfeld im Zeitwähler startet mit dem aktuellen Zeitraum, etwa now-7d, sodass du nur die Zahl änderst. Es nimmt auch ein Fenster in der Vergangenheit: 7d-3d ist der Zeitraum von vor 7 bis vor 3 Tagen. Ein Info-Symbol listet alle Ausdrücke, die es versteht.

Die Application-Einstellungen haben einen eigenen dataLayer-Abschnitt, und die Events-Übersicht zählt den Umsatz pro Bestellung.

• dataLayer: GA4-Ecommerce-Events lesen, jeden anderen Push nach Namen lesen, die Keys für Properties wählen und Namen behalten oder verwerfen, mit * als Präfix.
• Umsatz zählt jede Bestellung einmal, mit ihrem größten Wert, pro Währung. Die bisherigen Summen pro Event bleiben als „Wert pro Event“.
• API: POST /analytics/events/overview liefert order_revenue und value_sums. revenue ist veraltet.

Eine Danke-Seite, die purchase bei jedem Neuladen pusht, zählt eine Bestellung pro Seitenaufruf. Doku: Eigene Events.

Die dataLayer-Brücke hat zwei unabhängige Schalter, beide standardmäßig aus.

• collection.ga4_ecommerce liest die sieben GA4-Ecommerce-Namen mit Wert, Währung und Artikeln. Applications mit collection.data_layer an wechseln auf diesen Schalter.
• collection.data_layer liest jetzt jeden Namen, den die Seite pusht, ohne Properties. Die gtm.*-Pushes vom Google Tag Manager zählen nie, und ein Name zählt höchstens 10-mal pro Seitenaufruf.
• collection.data_layer_prop_keys übernimmt bis zu 30 Top-Level-Keys eines Pushes als Properties.
• collection.data_layer_mode mit data_layer_names sperrt oder erlaubt bis zu 50 Namen. Der Collector setzt das binnen fünf Minuten um, fastmon.event() filtert er nie.
• Maskierung: Ein Property-Key mit user, customer, email, mail, phone, password oder token geht als [masked] raus.
• E-Mail-Adressen in Event-Properties werden zu [email], bevor das Event den Browser verlässt.

Doku: Eigene Events und Datenschutz.

Eigene Events hängen nicht mehr an einem späteren Beacon oder an sendBeacon, das EasyPrivacy blockiert.

• Binnen etwa einer Sekunde: Kommt kein Beacon, schickt der Tracker das Event per fetch, höchstens 20-mal pro Seitenaufruf. Ein solcher Beacon hat den Lifecycle event_update.
• Beim Verbergen der Seite gehen wartende Events noch einmal per Keepalive-fetch raus, eine Kopie pro Event.
• Single-Page-Apps: Ein Routenwechsel schickt jedes wartende Event unter der Seite, zu der es gehört.
• Falsche Browser-Uhr: Ein Event bekommt die Uhrzeit des Beacons und zählt einmal, auch wenn es beim Verlassen erneut geht.
• Namen: fastmon.event("Add To Cart") wird als add_to_cart gespeichert. Ein Name ohne Buchstaben oder Ziffer wird übersprungen.

Doku: Eigene Events.

Die Browser-Cache-Trefferquote zählt jetzt die Cache-Treffer von Safari, deshalb springt die Safari-Quote mit dem Release. Eine Cross-Origin-Ressource ohne Timing-Allow-Origin verbirgt ihre Bytes und bleibt jetzt aus der Quote heraus. Ein Seitenaufruf ohne Ressource mit bekanntem Cache-Status speichert keine Quote statt 0 %.

Ein Checkout-Funnel mit Filter auf Viewport, Verbindung oder Page-Type behält Checkout und Kauf eines Shopify-Shops, statt 0 % zu zeigen.

• Das Pixel schickt die Viewport-Klasse, die Verbindungsklasse, wo der Browser eine meldet, und den Page-Type checkout. Installierte Pixel aktualisieren sich selbst.
• Login-Filter: Das Pixel kennt keinen Login-Status, daher antwortet logged_in bei einem Shopify-Scope mit 422. Das Dashboard bietet einen Button, der den Filter entfernt.
• Pixel-Status schaut 31 Tage zurück und braucht bis zu 30 Sekunden, bis eine Testbestellung erscheint.

In der ersten Woche stehen die Pixel-Besucher der Vorwoche in der Live-Übersicht in einer Zeile ohne Page-Type. Doku: Shopify-Checkout.

Richte einen CNAME auf fastmon.site und trag diesen Host als Collector-Endpoint im Modus „Custom collector“ ein. fastmon stellt das Zertifikat dafür aus, einen Reverse Proxy brauchst du nicht. Doku: Tracking-Code einbinden → Eigene Domain.

POST /analytics/query und jede Zeitreihen-Route nehmen neue Breiten und eine Zeitzone.

• Neue Breiten: five_minutes, fifteen_minutes und six_hours. Breiten unter einer Stunde erlauben höchstens 1500 Buckets, minute reicht damit über etwa 25 Stunden.
• granularity: auto nimmt die kleinste Breite mit höchstens 300 Buckets, ab 28 Tagen day. meta.granularity_options listet jede Breite mit 4 bis 1500 Buckets.
• timezone nimmt einen IANA-Namen wie Europe/Berlin. Buckets ab sechs Stunden beginnen dann an den Grenzen dieser Zone, die Zeitstempel bleiben UTC.
• Wochen beginnen am Montag, mit oder ohne timezone.
• Vergangene Fenster lesen finalisierte Daten. Nur ein Fenster bis 6 Stunden, das kurz vor jetzt endet, liest Live-Beacons.
• Ask und MCP nehmen jede Breite, die Tools für Fehler, NEL, CSP und Events nehmen interval.
• Breaking: Ein Client, der auf granularity verzweigt, muss die neuen Werte akzeptieren.

POST /analytics/query gruppiert und filtert nach Teilen der Seiten-URL.

• url_path ist die URL ohne Query, so ergeben /p?color=red und /p?size=m zusammen /p.
• url_key liefert eine Zeile pro Query-Key, url_key_set die Menge der Keys, die eine Seite hatte.
• url_param mit url_param_key gruppiert nach dem Wert eines Keys. Es gruppiert nur und filtert nicht.
• meta.pageviews sind die Seitenaufrufe des Fensters nach allen Filtern, der Nenner für einen Anteil.

Ein Key, dessen Wert die Application nicht speichert, antwortet mit 422 und nennt collection.query_values_for.

Ein Textfilter mit "" wählt jetzt die Zeilen ohne Wert. referrer_source: "" liefert die direkten Besuche, bisher kam der gesamte Traffic. exclude nimmt die Referrer-, UTM- und click_id_param-Spalten, und Ask und MCP nutzen stattdessen empty und not_empty.

POST /analytics/query nennt die Stichprobengröße jetzt sample_count, denn sie zählt Seitenaufrufe. beacons antwortet weiter als veralteter Zwilling. Das Dashboard zeigt die Stichprobengröße nicht mehr dort, wo das Backend keine Besucher oder Seitenaufrufe schickt.

Die Anmeldung mit GitHub oder Google braucht eine bestätigte Adresse und verknüpft sich nicht mehr mit einem unbestätigten oder gesperrten Konto. Webhook-, Slack- und Discord-Benachrichtigungen gehen nur an die öffentliche Adresse, die geprüft wurde.

Der Tracker schickt Events, die dein Shop selbst festlegt: einen Namen und bis zu 30 Properties.

• fastmon.event(name, props) stellt ein Event in die Warteschlange. Ein Queue-Stub nimmt Aufrufe an, bevor der Tracker geladen ist.
• Ein Klick auf ein Element mit data-fm-event schickt ein Event mit diesem Namen, jedes data-fm-event-*-Attribut wird zur Property. Mit einem leeren data-fm-event="" zählt ein Klick innerhalb eines markierten Containers nicht.
• GA4-Ecommerce-Pushes auf window.dataLayer werden zu Events, wenn collection.data_layer für die Application an ist. Standardmäßig ist es aus. Der Tracker übernimmt view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_payment_info und purchase und lässt Texte über 500 Zeichen weg.
• Kein eigener Request: Events fahren mit dem nächsten Beacon des Seitenaufrufs mit, höchstens 20 pro Beacon und 100 pro Seitenaufruf. Ein Event nach dem Verbergen der Seite öffnet den hidden-Beacon erneut.

Doku: Eigene Events.

Die Events-Seite zählt und listet jetzt auch die eigenen Events deines Shops, nicht nur den Checkout.

• Übersicht zeigt die Events im Zeitverlauf nach Name, die Namen nach Häufigkeit, den Umsatz pro Event und Währung aus value und currency und die häufigsten Werte jeder Property.
• Events listet sie einzeln mit ihren Properties. Eine Zeile klappt alle gespeicherten Felder auf und hat einen Link zum Teilen.
• Korrigieren oder löschen kannst du ein einzelnes Event in seiner aufgeklappten Zeile, als Owner oder Member. Stage-Events aus Checkout-Seiten bleiben, wie sie sind.
• Filter: Die Namensauswahl nimmt jeden Namen, und URL, Page-Type, Login-Status, Verbindung und Viewport-Klasse grenzen die Events ebenfalls ein.

Die Besucher-Journey zeigt die Events mit ihren Properties. Doku: Eigene Events.

Die API speichert, zählt und korrigiert Events mit beliebigem Namen, nicht nur die Checkout-Namen.

• POST /c/e/{collector_hash} nimmt ein einzelnes Event mit beliebigem Namen aus jedem Browser an, ohne Tracker.
• POST /analytics/events/overview zählt die Events eines Zeitraums pro Name, im Zeitverlauf, als Umsatz pro Währung und pro Property-Wert.
• PATCH und DELETE /sites/{site_id}/events/{event_id} ändern oder entfernen ein Event. Das Audit-Log hält event.updated und event.deleted fest.
• Breaking: name und source an einer Event-Zeile sind Strings statt Enums, source kennt zusätzlich tracker. Ein Listen-Cursor von vor der Änderung antwortet mit 400.
• Ask und MCP bekommen get_events, und list_sites meldet event_tracking und collect_data_layer.

Doku: Eigene Events.

Checkout-Stufen und Käufer kommen jetzt auf jeder Site und in jedem Zeitraum aus Events. Die checkout_stage eines Seitenaufrufs zählt nicht mehr als Stufe.

• Exakte Zahlen: Funnel, Stufen, Kohorten, Journeys und die Käufe der Live-Übersicht zählen bei jeder Sampling-Rate exakt. Besucher bleiben geschätzt, die Conversion-Rate teilt also exakte Käufer durch geschätzte Besucher.
• purchase erreicht die Erfolgsstufe neben order_placed, ein Käufer mit beiden zählt einmal.
• Filter: URL, Page-Type, Login-Status, Verbindung und Viewport-Klasse filtern die Events exakt. Kampagne und Referrer filtern auf den Einstiegs-Seitenaufruf des Besuchers.
• Breaking: Die Checkout-Routen antworten mit 422 auf technische Seitenfilter, einen Metrikbereich, einen Filter auf die Checkout-Stufe und die Identität session. Unter session hat die Besucherliste keine Checkout-Stufe, kein outcome und keine Stufenzahlen.

Doku: Checkout-Funnel.

Partner-Organisationen bekommen unter Partner in der Seitenleiste den Partnerfloor: jeder live Client als eigene Zone auf einer Bühne. Die Größe einer Zone folgt dem Anteil des Clients am Traffic der letzten Stunde, die Farbe dem LCP p75. Sie zeigt die Leute, Warenkorb und Checkout, die heutigen Bestellungen und die Veränderung zur Vorwoche.

Ein Klick auf einen Client öffnet seinen Shopfloor an Ort und Stelle. POST /organizations/{org_id}/partner/live liefert den Floor und braucht partner:read und analytics:read. Doku: Analytics → Partnerfloor.

Ein Button „Vergleichen“ neben dem Zeitraum setzt ein zweites Fenster. Das kann der vorige Zeitraum, Tag, Woche oder Monat sein, ein beliebiges eingetipptes Fenster oder ein Release im Vergleich zum vorigen.

• Die Zusammenfassung sagt, was sich gegenüber diesem Fenster geändert hat, und die Wert-Kachel zeigt die Veränderung.
• Jedes Diagramm zeichnet das zweite Fenster neben das erste: den Trend gestrichelt, die Verteilung als Umriss, die Phasen als blassen Balken.
• „Wo der LCP schlecht ist“ und „Wo der TTFB langsam ist“ ergänzen pro Zeile den Wert des Fensters und die Veränderung, die größte Verschlechterung zuerst.

Der Vergleich steckt im Link der Seite. Doku: LCP → Vergleichen.

Beim Ziehen an einer Spaltenkante in der Explorer-Tabelle wurde jede Spalte gedeckelt, die URL-Spalte ließ sich nur noch schmaler machen. Spalten werden wieder breiter, und ein Doppelklick auf die Kante passt die Spalte an ihren Inhalt an.

compare_to nimmt neben den vier Modus-Strings ein Fenster {from, to} beliebiger Länge oder ein Release {release_id}.

• Wo: POST /analytics/query, /analytics/funnels/checkout/stages, /analytics/error-types, /analytics/histogram und /analytics/metric-summary. Jede Route gibt das verwendete Fenster als request.comparison_time_range zurück.
• Ein Release vergleicht ab seinem released_at über die Länge von time_range, bis zum nächsten Release oder bis jetzt. Release-Zeilen haben window, das du als time_range schicken kannst.
• Breaking: facts.previous_period in der Metrik-Zusammenfassung und previous_period an den Zeilen der Fehlertypen heißen jetzt comparison.
• Deprecated: compare_to_release_id funktioniert weiter. Schick stattdessen ein Fenster in compare_to.

Mit compare_to sagt die Metrik-Zusammenfassung, was sich geändert hat, statt wie die Metrik steht, und sie deckt jetzt auch TTFB ab. Doku: Releases vergleichen → Metriken vergleichen.

Die TTFB-Seite ist aufgebaut wie die LCP-Seite: der Wert mit Bewertung und Trend, die Seitenaufrufe nach Bewertung und eine kurze Zusammenfassung.

• Wohin die Zeit geht teilt das erste Byte in Verbindung, Server, den Weg dazwischen und die Wartezeit, die niemand gemessen hat. Bei Sites mit 103 Early Hints siehst du, wo der Browser das erste Byte gezählt hat.
• Mit Server-Timing teilt sich der Server-Anteil in Edge, Origin, Datenbank, Cache, Suche, HTTP-Aufrufe, eigenen Code und Templates.
• Wo der TTFB langsam ist sortiert Page-Types, Seiten, Cache-Status, Login-Status und Origin-Hosts nach ihren langsamen Seitenaufrufen.
• Cache und Origin zeigt jede Cache-Ebene mit und ohne Treffer und hebt einen Origin-Host hervor, der aus der Reihe fällt.
• Verlauf zeichnet auf der TTFB- und der LCP-Seite eine Linie pro Page-Type, und das Panel lässt sich auf Fenstergröße bringen.

Doku: TTFB → TTFB in fastmon.

Die Besucherliste zeigt, über welche Quelle und welchen Kanal jemand gekommen ist, etwa Google-Suche oder Newsletter. Das Besucher-Pop-up markiert jede Rückkehr von außen in der Zeitleiste und in der Journey, mit Kampagne. In der API haben Journey-Schritte arrival, und journey[0].arrival ist die Einstiegsquelle.

Neu laden, Routenwechsel und der Rückweg von einer Zahlungsseite zählen nie als Rückkehr. Doku: Sessions → Einstieg.

Routenwechsel von Single-Page-Apps und Wiederherstellungen aus dem BFCache haben jetzt die Quelle internal. Sie wiederholen nicht mehr Quelle und Medium der Einstiegsseite. Auf einer SPA-Site zeigen Ansichten nach Referrer-Quelle daher weniger Seitenaufrufe für benannte Quellen und Direktzugriffe, auch in den gespeicherten Daten.

Bei der Registrierung fragen wir kein Passwort mehr ab. Der Bestätigungslink öffnet eine Seite, auf der du es wählst, und ein abgelaufener Link bietet dir einen neuen an. Eine Einladung fragt das Passwort weiterhin im Formular ab.

In der API nimmt POST /auth/verify-email den Token und das Passwort, GET /auth/verify-email gibt es nicht mehr.

Die site_policy „Suggest“ verwirft einen Beacon von einem unbekannten Host jetzt auch bei einer Application mit nur einer Site und schlägt den Host als Site vor. Bisher landete jeder Host auf dieser einen Site, etwa 127.0.0.1 aus einem Testlauf. Ein www.-Host oder ein eigener Checkout-Host braucht eine eigene Site. Doku: Tracker → site_policy.

Unter Besucher & Sampling überlässt du mit „Anteil automatisch festlegen“ fastmon die Sampling-Rate einer Produktions-Application. fastmon leitet sie aus deinen gebuchten Pageviews ab und ändert sie höchstens um eine Stufe pro Tag, zwischen 100 und 1 %. Das gilt nur für Pläne mit einer festen Zahl an Pageviews.

Die manuelle Rate geht jetzt bis 1 % hinunter, das API-Feld heißt collection.sampling_mode. Doku: Applications → Sampling-Modus.

Ein Zeitdiagramm über mehr als 6 Stunden fällt am rechten Rand nicht mehr auf null. Der laufende Abschnitt wird als unfertig gezeichnet, so weit die Daten vollständig sind, der Rest ist schraffiert.

Die Leute eines Partners handeln in einem Client mit der Rolle, die sie in der Partner-Organisation haben: Owner, Member oder Viewer. Eine direkte Mitgliedschaft im Client hat weiterhin Vorrang.

• Neu im Client: Ein Partner kann Apps auf Organisationsebene verbinden, etwa das Shopware-Plugin, und Org-Keys ausstellen.
• Weiterhin nicht erlaubt: den Client löschen, die Inhaberschaft übertragen, Abrechnung oder Partner-Verbindungen verwalten und seine Owner herabstufen.
• Zugänge bleiben: Keys und Verbindungen, die ein Partner angelegt hat, tragen via_partner_org_id und funktionieren nach dem Trennen weiter. Beim Trennen werden sie aufgelistet, damit der Client sie rotieren oder trennen kann.

Doku: Organisationen → Partner-Zugriff.

fastmon öffnet mit dem Bereich, den du zuletzt gewählt hast: eine Application, eine Auswahl von Sites, ein Tag oder die ganze Organisation. Beim ersten Besuch öffnet es die Produktions-Application als Ganzes statt einer ihrer Sites.

Der Tracker liest den Page-Type aus <meta name="fm-page-type" content="product"> und schickt ihn als pt, in jedem Datenschutzmodus.

• Ersatzname: page-type zählt, wenn das Tag mit Präfix fehlt oder leer ist. Bei mehreren Tags gleichen Namens gilt das letzte, gekürzt auf 32 Zeichen.
• Bei jedem Beacon gelesen: Eine Single-Page-App, die das Tag beim Routenwechsel neu setzt, beschriftet damit den neuen Pageview. Eine Sekunde später liest der Tracker es noch einmal, für Router, die den Head spät aktualisieren.
• Soft-Pageviews schicken das Tag erst, wenn es sich seit dem ersten Lesen geändert hat. Ein Tag, das sich nie ändert, bleibt bei der Einstiegsseite.
• Eine Wiederherstellung aus dem BFCache schickt das eigene Tag der Seite.
• Reihenfolge: Ein Page-Type aus Server-Timing gewinnt, das Tag schlägt Body-Klassen, URL-Regeln und Erkennung. page-type-sources listet es als meta_tag.

Außerhalb von Shopify zählt brand jetzt als Kategorie, cms und blog als Content, statt unter Other zu landen. Doku: Applications → Page-Type-Detection.

free ist fastmon One ohne Bezahlung: alle Features, unbegrenzte Pageviews und Applications. Die API nimmt und liefert kein beta mehr, eine Anfrage damit bekommt eine 422. Synthetic Monitoring erlaubt auf free, one und partner gleichermaßen 5 manuelle und 10 automatische Seiten, auf partner vorher 10 und 20. Doku: Organisationen → Pläne.

Jede Organisation listet ihre Features, und ein Partner legt fest, welche er für jeden Client abdeckt.

• features an der Organisation nennt jedes Feature mit Status: covered durch einen Partner, granted von fastmon, included im Plan oder locked. Gesperrt ist noch nichts.
• PATCH /organizations/{org_id}/partner/clients/{client_org_id} setzt die Features und Pageviews, die ein Partner abdeckt, im Rahmen seines Vertrags unter GET /organizations/{org_id}/partner/contract.
• billing an einer Partner-Verbindung ist true, sobald sie irgendetwas abdeckt.
• Das Audit-Log kennt drei neue Aktionen: org.grants_changed, partner.contract_changed und partner.coverage_changed.

POST /analytics/query nimmt neue Metriken, und Alert-Regeln, Histogramm, Ask und MCP nehmen sie auch.

• cdn_served_rate und origin_served_rate: der Anteil der Seitenaufrufe, die ein Cache aus seiner gespeicherten Kopie beantwortet hat (HIT, STALE, UPDATING oder REVALIDATED). cdn_hit_rate und origin_hit_rate zählen weiter nur HIT.
• ttfb_phase_connect, _edge, _origin, _backend, _unattributed und _unmeasured teilen das erste Byte jedes Seitenaufrufs auf. Ihre Mittelwerte ergeben in jeder Gruppierung zusammen den mittleren TTFB.
• ttfb_phase_db, _http, _render, _search, _kv und _code teilen den Backend-Anteil auf.
• metric_ranges nimmt ttfb_final und die Server-Timing-Phasen von edge_dur bis code_dur. Ein Seitenaufruf ohne die Messung trifft keine Grenze.

POST /analytics/error-types nimmt compare_to: previous_period und gibt dann jeder Zeile previous_period.count. Eine Signatur außerhalb der Top 50 der Vorperiode bekommt ihre echte Zahl, statt als neu zu gelten. Andere Modi antworten mit 422.

POST /analytics/histogram und Alert-Regeln zählten einen Seitenaufruf einmal pro gespeicherter Beacon-Version, ein früher Beacon wog also doppelt. Beide lesen jetzt dieselben Daten wie die Diagramme. Ein Alert-Fenster über 6 Stunden hinkt am neuesten Ende 15 Minuten hinterher, wie die Diagramme.

Ein DNS-Lookup oder TCP-Connect über 60 s oder länger als das erste Byte, in dem er steckt, wird leer gespeichert. Ein aufgeweckter Tab hatte Minuten in diese Mittelwerte getragen. Gespeicherte Zeilen verlieren die Verbindungen, die länger als ihr erstes Byte sind, ebenfalls; Werte über 60 s von vor dem 12. Oktober bleiben.

POST /analytics/element-targets nennt pro Element eine example_url, für jede Metrik und Gruppierung. Mit einem target zählt es nur die Seitenaufrufe dieses Elements, und group_by: "url" listet dessen eigene meistbesuchte Seiten. group_by nimmt außerdem page_type und device_type.

Die LCP-Seite unter Core Web Vitals ist neu aufgebaut. Zwei Kacheln zeigen den LCP und den Anteil gemessener Seitenaufrufe, darunter verlinkt eine kurze Zusammenfassung auf die Abschnitte.

• Wohin die Zeit geht teilt den LCP in Serverantwort, Load Delay, Load Duration und Render Delay, gemessen an den Zielwerten von web.dev.
• Wo der LCP schlecht ist sortiert Seitentyp und Gerät oder eine andere Dimension nach Seitenaufrufen über 4 s. Eine Zeile öffnet sich als Pop-up mit eigenem Diagramm.
• Die LCP-Elemente zeigen jedes Element mit Selektor, Art, Discovery-Pfad und Phasen. Das Detail prüft HTML, Preload, fetchpriority, Lazy Loading und Browser-Cache und hat einen eigenen Link.
• AI Prompt an einem Element baut einen Prompt für einen Assistenten, mit den Zahlen, den Prüfungen und dem, was fastmon nicht erfasst.
• Ein Seitenaufruf im Explorer zeigt sein LCP-Element genauso und verlinkt es auf der LCP-Seite.

Doku: LCP → LCP in fastmon.

Die Diagramme der Metrikseiten zeigen weniger und lesen sich leichter.

• Der Verlauf zeichnet nur das gewählte Perzentil vor den Bewertungszonen, im Diagramm wie im Tooltip. Seine Balken zählen bei einer gesampelten Anwendung den hochgerechneten Traffic.
• Die Verteilung zeigt die Zonen als Skala unter den Balken, ohne geschätzte Perzentil-Markierungen.
• Das Breakdown-Raster zeigt die Phasen jeder Zeile als Streifen und Icons für Seiten, Verbindungen und Cache-Status.
• Zahlen auf den gestapelten Diagrammen von NEL, CSP, Fetch/XHR und Cache-Status stehen ausgeschrieben da, etwa 150.000, und werden nicht mehr abgeschnitten.
• Auf dem Handy halten Diagramme 16 px Abstand zum Rand, und ein Verlauf beschriftet jedes zweite Datum.

fastmon speichert, aus welchem Netzwerk ein Besucher kommt, als asn und isp, in jedem Datenschutzmodus. Der Edge leitet es wie das Land aus der IP ab.

• NEL und CSP listen die Netzwerke der betroffenen Besucher in einer Karte „Netzwerke“. Ein Ausfall bei einem Provider steht dort als eine Zeile, etwa „Deutsche Telekom AG“.
• Netzwerk ist ein Filter, nur zum Einschließen. Jede Metrikseite und der Explorer schlüsseln danach auf.
• Analytics zeigt die häufigsten Netzwerke in einem Tab neben den Ländern.
• Das Pageview-Detail nennt das Netzwerk des Besuchers oben im Raster.
• „Netzwerktyp“ heißt jetzt die Karte, die Privat- und Rechenzentrums-Traffic trennt.

Doku: Privacy → Was wir sammeln.

Ein Klick auf eine gruppierte Zeile im Explorer zeigt die Pageviews dieser Gruppe als gewohnte Liste, mit ihren Spalten, Filtern und Seiten. Eine Leiste darüber springt zur vorigen oder nächsten Gruppe und zurück zu allen, und die offene Gruppe steht im Link. Auf dem Handy zeigen beide Explorer-Tabellen eine Karte pro Zeile.

Die Links zur Setup-Anleitung auf den NEL- und CSP-Seiten öffnen die Anleitung mit fertigen Headern für die gewählte Anwendung. Über mehrere Anwendungen hinweg öffnet sie sich wie bisher ohne.

asn ist Dimension und Filter von POST /analytics/query, den NEL- und CSP-Breakdowns, den MCP-Breakdown-Tools und der Live-Ansicht. Eine Gruppierung nach asn liefert auch isp, den Namen des Netzwerks. Jede Antwort auf Zeilenebene mit country trägt jetzt auch asn und isp, etwa Beacon-Zeilen, Besucher, Fehler sowie NEL- und CSP-Reports.

Der Tracker erfasst bei jedem Seitenaufruf drei häufige Ursachen für ein langsames LCP-Bild, in jedem Datenschutzmodus.

• lfp: die fetchpriority des Bildes oder des Preloads, der es geladen hat (high, low oder auto).
• llg: das loading des Bildes, vereinheitlicht auf lazy oder eager.
• ldv: ob die Ressource aus dem Browser-cache oder über das network kam. Eine 304-Revalidierung zählt als Netzwerk, und eine Soft Navigation liest nur ihre eigenen Ressourceneinträge.

Die Cache-Prüfung liefert vor allem Chromium. Firefox und Safari lassen sie bei Bildern aus ihrem seiteninternen Cache leer, jeder Browser bei einem Cross-Origin-Bild ohne Timing-Allow-Origin. POST /analytics/element-targets gibt jedem LCP-Element fetch_priority_high_rate, lazy_rate und cache_rate, und POST /analytics/query gruppiert nach lcp_fetch_priority, lcp_loading und lcp_delivery. Doku: LCP → LCP in fastmon.

Eine Ask-Frage kostet etwa halb so viele Tokens. Eine Frage mit einem Tool-Aufruf reißt das Minutenlimit der Organisation also nicht mehr allein. Eine abgelehnte Frage antwortet mit ihrem eigenen Status statt mit einem 500, ein aufgebrauchtes Budget mit 429 und retry_after_seconds.

Der Tab „Reports“ von Network Error Logging und Content Security Policy gruppiert und blättert seine Reports.

• Gruppiert nach Besucher, Seite oder URL: auf NEL der fehlgeschlagene Request, auf CSP die blockierte URL. Eine Gruppe klappt direkt zu ihren Reports auf und sortiert nach den meisten Reports oder den neuesten.
• Seiten mit 25, 50 oder 100 Reports und „Zurück“ und „Weiter“, statt Nachladen beim Scrollen.
• Ein geöffneter Report steht in der URL, die Adresse ist also ein Link darauf, auch außerhalb des aktuellen Zeitraums.
• CSP ist aufgebaut wie NEL: die Reports als Tabelle, und „Add directive“ im Filter-Panel wählt jede Direktive.
• Kein Sampling-Badge mehr auf beiden Seiten. Der Browser schickt jeden Report, und fastmon speichert alle.

Doku: Content Security Policy → Die Seite.

POST /analytics/nel/breakdown und POST /analytics/csp/breakdown gruppieren nach stitch, status_code_range und bot_name, NEL zusätzlich nach request_url, error_type und path. Jeder Schlüssel passt in seinen Filter und wählt genau die Reports seiner Gruppe. Jede Zeile trägt first_seen_at und last_seen_at, und order_by: {"field": "last_seen_at"} stellt die neueste Gruppe nach vorn. Doku: Network Error Logging → API.

Ask und MCP-Clients lesen Network-Error-Logging- und CSP-Reports mit sechs neuen Tools: get_nel, get_nel_breakdown, list_nel_reports, get_csp, get_csp_breakdown und list_csp_reports. Sie nehmen die Filter der Dashboard-Routen und zählen genauso. Eine Zeile aus list_csp_reports enthält kein original_policy. Doku: MCP → Was das Modell lesen kann.

get_server_timing, get_fetch_xhr, get_resource_breakdown und get_third_party_impact führen die Abfragen der Dashboard-Panels aus und antworten mit deren Feldnamen. Ein Client, der die alten Schlüssel liest, muss umstellen.

Ältere Ask-Unterhaltungen behalten die alten Schlüssel in ihren gespeicherten Tool-Ergebnissen.

POST /analytics/element-targets liefert pro Target eine distribution mit p50, p75, p90 und p95. Ein Client wechselt das Perzentil also ohne zweite Anfrage.

• Mit metric: "lcp" trägt jedes Target die Mittelwerte der vier LCP-Teilphasen, das häufigste lcp_discovered_via und image_rate.
• Mit by: "element" kommen die resource_url, die die meisten Seitenaufrufe des Targets ausliefert, und resource_url_count dazu.
• metric in der Antwort ist das Enum der Anfrage, mit denselben Werten lcp, cls und inp.

group_by: "url" scheitert bei Shops mit vielen Seiten nicht mehr mit einem 500. Doku: LCP → LCP in fastmon.

Ein Besucher-Link öffnet die Journey über der Seite, auf der du bist, und Schließen bringt dich dorthin zurück. Das gilt für NEL- und CSP-Reports, die Explorer-Tabelle, das Seitenaufruf-Detail und Checkout-Events.

• Cmd- oder Strg-Klick öffnet weiterhin die Visitors-Seite in einem neuen Tab.
• Ein Besucher ohne Seitenaufruf im Zeitraum zeigt seine Reports und Events der Reihe nach, mit einem Hinweis.
• Der Live-Modus hat einen eigenen Schalter im Pop-up und hält die Journey stehen, während neue Seiten dazukommen. Er aktualisiert auf jeder Seite, die ihn hat, alle 7 Sekunden.

Doku: Analytics → Visitors.

Ein Scope über mehrere Sites oder die ganze Organisation hat stitch-Besucher gezählt, egal was die Applikationen speichern. Eine Organisation, deren Applikationen nur Session-IDs speichern, sah dort 0 Besucher und sieht jetzt die echte Zahl.

• Uneinige Applikationen zählen nach der Kennung, die die meisten speichern. Jede Applikation zählt einmal.
• Keine Kennung gespeichert: visitors ist null statt 0.
• meta.is_identity_mixed ist true, wenn die Zahl eine Untergrenze ist. POST /analytics/query nennt in request.identity, wonach es gezählt hat.

Doku: Besucher und Sessions.

Geschäftskunden in Deutschland, den Niederlanden und Belgien mit USt-IdNr. bekommen ihre Rechnung zusätzlich als E-Rechnung über Peppol. Die USt-IdNr. dient als Peppol-Kennung und muss deshalb zu deiner Registrierung passen. PDF und Rechnungsmail bleiben, wie sie sind. Doku: Organisationen → Pläne.

POST /analytics/query nimmt bis zu 20 Metriken statt 10. Die Server-Timing-Tabelle pro Seitentyp scheitert bei Sites, die jede Phase melden, nicht mehr mit einem 422.

Ein Link, der eine Seite oder den Explorer auf eine Zeile gefiltert öffnet, behält „All traffic“ und „Bots only“ und die übrigen Filter der Seite. Bisher fiel er auf ausgeblendete Bots zurück.

Ein Cmd- oder Strg-Klick auf ein Segment in der Legende des Analytics-Charts zeigt nur dieses Segment, etwa einen Bot im Bot-Split. Derselbe Klick holt alle Segmente zurück. Ein normaler Klick blendet weiterhin ein Segment aus, aber nie das letzte. Doku: Analytics → Das Dashboard.

Die Bestellungen von heute im Shopfloor zählen bis zur Anfrage und aktualisieren sich alle 10 Sekunden. Die Zahl sagt, bis wann sie zählt („Stand 14:32“), und die Vorwoche läuft bis zur gleichen Uhrzeit. Ein Verkauf fällt nicht mehr aus der Kopfzeile heraus, während der Server aufholt. In der API trägt today.time_range.to von POST /analytics/live-summary diesen Zeitpunkt. Doku: Analytics → Shopfloor.

Einige Abfragen zählen jetzt so wie das Dashboard.

• error_count der Fehlerliste zählt jeden JavaScript-Fehler im Scope, nicht nur die gelisteten Signaturen. Der share jeder Zeile teilt durch diese Summe.
• Ein Fehler-Drill-down, dessen Vorkommen sich zu 0 summieren, zeigt sein erstes und letztes Auftreten und seine Beispiele.
• Ask und die MCP-Tools get_overview, detect_changes und get_cwv_distribution berechnen den p75 wie das Dashboard, ihre Zahlen können sich also leicht verschieben.
• get_cwv_distribution bewertet mit den Schwellenwerten des Dashboards. Ein CLS von genau 0,1 gilt als gut, ein gemeldeter Wert von 0 ebenfalls.

URL-Regeln für Seitentypen und Checkout-Pfade verstehen einen Teil der URLPattern-Syntax.

• Neue Bausteine: :name für ein Pfadsegment, (de|en) für eines der aufgezählten Wörter und {/}? für einen optionalen Teil.
• Ein Muster ohne ? prüft nur den Pfad. /checkout trifft jetzt auch /checkout?step=2, und ein Query-Muster ohne ?, etwa *cl=basket*, trifft nicht mehr.
• Ungültige Muster werden beim Speichern abgelehnt, etwa ein eingefügter regulärer Ausdruck. Ein bereits gespeichertes überspringt der Collector, und die Einstellungen markieren es schon beim Tippen.
• URL-Regeln sind nummeriert und lassen sich verschieben, denn die erste passende gewinnt.

Doku: Checkout-Funnel → Mustersyntax.

„Bots“ neben dem Chart-Typ teilt das Pageview-Chart in Menschen und Bots, einzelne Bots oder Bot-Typen. Der Bot-Filter zieht mit und springt zurück, wenn du die Ansicht ausschaltest. Jeder Stapel lässt sich in der Legende ausblenden, und die Ansicht steht in der URL. Doku: Analytics.

Die Liste der JavaScript-Fehler filtert nach Herkunft: Alle, Eigene oder Dritte. Die Fehler-Charts öffnen mit dem Anteil an den Pageviews, „Absolut“ schaltet auf die Anzahl. Chart und Fehlerrate zählen weiter jeden Fehler. Doku: Analytics → Fehler-Analytics.

Ein aufgeklappter Endpunkt zeigt seinen eigenen p75 oder p95 über den Zeitraum, mit Aufrufen, Release-Markern und dem Zeitraum davor. Er steht in der Adresszeile, die URL verlinkt also genau das Geöffnete. Das Chart „Zeitverlauf“ und die Charts für NEL und CSP zeichnen eine Linie pro Serie mit auslaufender Fläche, und jede Serie lässt sich in der Legende ausschalten.

Das Befehlsmenü listet bei gleich guten Treffern Prod-Applications und -Sites vor Dev. Hast du noch keine Site gewählt, öffnet das Dashboard eine Prod-Site. In der API trägt jeder Site-Treffer von GET /search das environment seiner Application. Doku: Analytics → Befehlsmenü.

Die Seite Network Error Logging liest sich direkter.

• Reports ist eine Tabelle mit Zeit, Typ, Status, Zeit bis zum Fehler, Request, Seite, Gerät, Browser, Besucher und Land. Sie lädt beim Scrollen nach, sortiert nach jeder Spalte und lässt sich als Markdown oder CSV kopieren.
• „Typ hinzufügen“ bietet jeden bekannten Fehlertyp an, die des Zeitraums zuerst.
• Verbindungsfehler lassen sich nach Typ filtern, mit + und -.
• Die Warnung „wahrscheinlich ausgefallen“ an einer Serveradresse ist weg.

Doku: Network Error Logging → Die Seite.

Nutzung, Kontingent-Hinweis und Plan-Seite haben Beacons gezählt, ein Pageview mit mehreren Beacons zählte also mehrfach. Jetzt zählt jeder gespeicherte Pageview einmal, Bots eingeschlossen. Ein gesampelter Pageview zählt so, wie er gespeichert ist, nicht hochgerechnet, die Zahlen sinken also auf deine echten Pageviews. Doku: Organisationen → Pläne.

GET /organizations/{org_id}/usage und GET /organizations/{org_id}/partner/usage liefern pageview_count und time_range. beacon_count, total_beacons, period_start und period_end sind weg, auch aus den Zeilen pro Site und pro Kunde. Ein Client, der sie liest, muss umstellen.

Ohne Organisation zeigt der Startbildschirm die offenen Einladungen für deine E-Mail-Adresse mit einem Button „Beitreten“, auch wenn du dich ohne den Einladungslink registriert hast. Die Einladung übersteht außerdem den Weg über Login und Registrierung. Eine neue E-Mail-Adresse gilt erst, wenn du sie auf der Seite bestätigst, die die Bestätigungsmail verlinkt.

Der Besucher-Dialog hat neben „Im Explorer öffnen“ einen Aktualisieren-Button, ein laufender Besuch holt so seine neuen Seiten nach. Bestellungen, Checkout und Warenkorb zeigt die Besucher-Seite nur bei einem Shop. Doku: Analytics → Besucher.

Die Besucher-Seite zeigt jetzt, was in einem Besuch passiert ist, nicht nur, wie viele kamen.

• Zwei neue Spalten. Ausgang sagt bestellt, Checkout verlassen, Warenkorb, gestöbert oder abgesprungen. Verlauf zeigt einen Block pro Seite, die Breite ist die Verweildauer, die Farbe der Seitentyp.
• Segment-Chips über der Liste setzen die Verhaltensfilter: mit Fehlern, langsam, bestellt, Checkout erreicht, Warenkorb-Aktivität, nur eine Seite. Jeder Chip zeigt, wie viele Besucher er listet.
• Die Zusammenfassung zeigt zusätzlich den Anteil der Besucher mit JavaScript-Fehler, die langsamen Besucher und die Käufer.
• Ein Besucher öffnet sich in einem Dialog, auf dem Handy als Sheet von unten. Ein Klick auf eine Seite öffnet ihr volles Detail, und „Im Explorer öffnen“ listet alle Pageviews des Besuchers.

Doku: Analytics → Besucher.

Jede Zeile von POST /analytics/visitors enthält outcome (ordered, checkout, cart, browsed oder bounced) und journey, die ersten 50 Pageviews mit Seitentyp, Verweildauer, Fehlern und Checkout-Stufe. POST /analytics/visitors/segments zählt die Besucher hinter jedem Segment der Liste. Auf einem gesampelten Shop sind diese Zahlen hochgerechnet. Doku: Besucher und Sessions → Besucher abfragen.

Eine Application speichert die Fetch- und XHR-Aufrufe standardmäßig für 25 % ihrer Besucher. Jede Application, die sie für alle Besucher gespeichert hat, steht jetzt auf 25 %.

• Die Zahlen bleiben vergleichbar. Aufrufe und Fehler werden hochgerechnet, Perzentile und seltene Endpunkte beruhen aber auf weniger Aufrufen.
• Der Rest des Pageviews wird vollständig gespeichert, und Warenkorb-Interaktionen zählen mit der Pageview-Rate.
• Zurück auf 100 % stellst du unter Besucher & Sampling oder mit collection.fetch_xhr_sampling_rate. Die Rate greift nie über die Traffic-Rate hinaus.

Doku: Applications → Fetch- und XHR-Sampling.

Unter dem Sampling-Feld steht eine empfohlene Rate aus dem Traffic der letzten sieben Tage. Sie nennt die Pageviews pro Tag und Monat, auf denen sie beruht, und wie viele die Rate behält. Übernehmen trägt sie ins Feld ein, speichern musst du selbst. Doku: Applications → Empfohlene Rate.

GET /applications/{app_id}/sampling-recommendation empfiehlt die Rate, die etwa 20.000 Pageviews am Tag behält, aufgerundet auf die nächsten 0.05 und nie unter 0.2. Weggefallen sind binding_constraint, constraints, inputs.quiet_hour_pageviews, inputs.smallest_slice und inputs.checkout, neu ist inputs.pageviews_per_month. Ein Client, der die entfernten Felder liest, muss angepasst werden. Doku: Applications → Empfohlene Rate.

Die Einstellungen einer Application gliedern sich jetzt in Allgemein, Datenumfang, Besucher & Sampling, Shop & Seitentypen und Collector.

• Die Navigation zeigt den aktiven Wert jedes Bereichs, du siehst eine Einstellung also, ohne den Bereich zu öffnen.
• Eine Speicherleiste zählt deine ungespeicherten Änderungen und kann sie verwerfen. Blockiert etwas das Speichern, springt sie zum Feld.
• Die Session-ID liegt jetzt unter Besucher & Sampling. Vor dem Einschalten fragt das Dashboard nach, weil sie auf das Gerät des Besuchers schreibt.
• Die Site-Einstellungen nutzen dieselben Zeilen und dieselbe Speicherleiste. Alte Links auf „Daten & Privacy“ öffnen Datenumfang.

Jeder Wert eines Pageviews hat jetzt einen festen Platz: oben acht Eckdaten und sechs Vitals-Kacheln, darunter neun einklappbare Abschnitte. Jeder Abschnitt zeigt eine Zusammenfassung in einer Zeile, und die Feldsuche öffnet den Abschnitt mit dem gesuchten Wert. JavaScript-Fehler nutzen die volle Breite, der Stack ist außer beim ersten Fehler eingeklappt. Doku: Analytics → Der Explorer.

Hinweise teilen sich oben eine schmale Leiste statt gestapelter Streifen. „Details“ öffnet alle auf einmal, den dringendsten zuerst. Auf dem Handy zeigt die Leiste den dringendsten Titel und wie viele weitere es gibt.

Die neue Phase code_dur ist die Zeit, die dein Backend in seinem eigenen Code verbringt, außerhalb von Datenbank, Key-Value, HTTP und Rendering. Sie kommt aus fm-code oder aus dem Tideways-Layer unknown, den das Shopware-Plugin durchreicht. Das Dashboard zeigt sie als „Code“ neben DB, KV, HTTP und Render. Pageviews von vor der Änderung behalten unknown als eigenen Key. Doku: Server-Timing → Backend-Phasen.

Auf einer Seite vom Typ search behält die gespeicherte URL den Wert von q, search und OXIDs searchparam, gekürzt auf 64 Zeichen. Eine category-Seite behält searchparam für OXIDs Filterformular. Das gilt in jedem Modus und ohne Opt-in, deine Datenschutzerklärung muss Suchbegriffe der Site-Suche also nennen. Doku: Privacy → Suchbegriffe der Site-Suche.

Jeder Checkout-Pageview schreibt ein Stage-Event, /analytics/events und die Checkout-Journeys liefern also mehr Zeilen.

• Namen: view_cart, begin_checkout und order_placed, dieselben Namen wie beim Shopify-Pixel. source ist collector oder shopify_pixel.
• meta.sampling.estimated_metrics nennt die hochgerechneten Felder einer Funnel-, Live-, NEL- oder CSP-Antwort. Ohne Sampling bleibt die Liste leer.
• Auf den NEL-Routen beschreibt meta.sampling das Failure-Sampling des Browsers statt der Rate der Application.

Doku: Checkout-Funnel → Stage-Events und Sampling.

Checkout-Funnel und Käufe zählen jetzt bei jeder Sampling-Rate jeden Besucher, ein Shop kann also wieder gesampelt laufen.

• Stage-Events entstehen für jeden Checkout-Pageview, auch für Besucher, die das Sampling verwirft. Funnel-Schritte, Kohortengrößen, Stufen-Verlauf und Käufe lesen sie.
• Live-Zahlen zählen jeden Besucher im Fenster, gesampelt oder nicht, im Shopfloor und in /analytics/live.
• Hochgerechnete Werte tragen ein ~ im Dashboard, etwa die Warenkorb-Zahlen und die Vorwoche. Checkout-Schritte und Bestellungen bleiben unmarkiert.
• Events gibt es im Explorer für jeden Shop, nicht nur für Shopify.

Doku: Checkout-Funnel → Stage-Events und Sampling.

Fehler → Content Security Policy zeigt, was die Policy deiner Site blockiert hat und was eine Report-only-Policy blockieren würde. Dafür muss die Policy fastmon als Report-Endpunkt nennen.

• Zwei Tabs: Übersicht und Reports. Die Übersicht stapelt die Verstöße im Zeitverlauf nach Direktive oder nach Policy, dazu Karten für Blockiertes, Seiten, Scripts, Direktiven, Sites, Länder, Geräte, Browser, OS und Traffic.
• Die Karte Sites ist der Einrichtungs-Check. Jede Site zeigt ihren letzten Report, eine Site ohne Report sagt das. Gibt es gar keine Reports, verlinkt die Seite die Einrichtungsanleitung.
• Das + filtert auf einen Wert, das - schließt ihn aus, und die Lupe öffnet seine Reports. Blockiert oder Report-only, Direktive, blockierte URL, Seite und Script bleiben in der Adresse.
• Reports listet jeden CSP-Report mit der verletzten Policy. Jeder hat einen eigenen Link zum Teilen und verlinkt auf den Besucher.
• Die Journey eines Besuchers zeigt seine CSP-Reports zwischen den Seitenaufrufen, blockierte in Rot, Report-only in Gelb.

Doku: Content Security Policy → Die Seite.

Nennt eine Policy in report-to und report-uri die Adresse https://fastmon.site/c/v/{collector_hash}, meldet der Browser jeden Verstoß an fastmon. Lass eine neue Policy zuerst als Content-Security-Policy-Report-Only laufen, dann siehst du, was sie kaputt machen würde.

• Beide Formate kommen an, die Reporting API und das ältere report-uri, praktisch jeder Browser meldet also. Die Zahlen sind exakt und nicht gesampelt.
• Der Host des Reports muss eine Site der Application sein oder eine Subdomain davon. Ein Report legt nie eine Site an.
• Ein Report behält Disposition, Direktive, blockierte und auslösende URL ohne Query, die Seite und die Policy mit geleerten Nonces. Identische Reports eines Uploads werden einmal mit ihrer Anzahl gespeichert.
• Verworfen werden das Code-Sample von 'report-sample', Reports von Browser-Erweiterungen und ein Referrer von einem anderen Host.
• Shopify-Storefronts können die Header nicht setzen.

Doku: CSP-Verstöße an fastmon melden · Datenschutz → CSP-Reports.

POST /analytics/csp zählt Reports und betroffene Besucher je Direktive und Disposition im Zeitverlauf. /analytics/csp/breakdown gruppiert sie nach einer Dimension, etwa der blockierten URL oder der Seite, und /analytics/csp/reports listet sie einzeln mit der verletzten Policy. Die Besucher-Details und die Checkout-Journeys tragen csp_reports neben nel_reports. Die Filter disposition, effective_directive, blocked_url und source_url gelten nur auf den CSP-Routen, jede andere Route antwortet mit 422. Doku: Content Security Policy → API.

Die Plan-Seite fragt nicht mehr, welchen Plan du willst. Der Tarif für 29 EUR entfällt, und alles, was ihm fehlte, gehört jetzt zu fastmon One.

• Preis und Kontingent bleiben: 99 EUR netto im Monat mit 1.000.000 Seitenaufrufen und einer Production-Application. Development-Applications bleiben kostenlos.
• Du entscheidest nur noch über Kapazität: zusätzliche Seitenaufrufe in Millionenschritten und Slots für Production-Applications, neben deiner Nutzung und der Prognose.
• Eine Preisübersicht zeigt jede Position zum vollen Preis, jeden Rabatt als eigene Zeile, die Änderung gegenüber heute und den Betrag inklusive USt. Fehlende Rechnungsdaten füllst du direkt auf der Seite aus.

Doku: Organisationen → Pläne.

Jede Antwort mit einem Plan liefert one, wo bisher standard stand, und light ist aus dem Enum verschwunden. Eine Übergangsfrist gibt es nicht: Ein Client, der auf "standard" prüft, trifft ohne Fehlermeldung nicht mehr. GET /organizations/{id}/billing/plans liefert kein early_adopter mehr, und GET /organizations/{id}/billing weist beide Add-on-Beträge nach Abzug des Jahresrabatts aus. Doku: Organisationen → Pläne.

Das Chart unter JavaScript-Fehler trennt einen Fehleranstieg von einer Traffic-Spitze.

• Das Chart der betroffenen Seitenaufrufe schaltet zwischen Anzahl und %. Der Anteil ist der Teil der Seitenaufrufe eines Buckets, der einen Fehler hatte.
• Top 5 zeichnet die fünf Fehler mit den meisten betroffenen Seitenaufrufen als Linien neben die Summe. Die Legende zeigt ihre Werte für den Bucket unter der Maus und verlinkt auf jeden Fehler.
• Ziehen über das Chart zoomt hinein. Beide Einstellungen bleiben im Link, und die eigene Seite eines Fehlers hat denselben %-Umschalter.
• „Zuletzt gesehen" ist minutengenau, in der Liste und in ihrer Sortierung. Jede Zeile von POST /analytics/error-types trägt last_seen_at.

Doku: Analytics → Error Analytics.

Die Zeitraum-Pille und ihr Picker brauchen weniger Klicks.

• Minus und Plus verdoppeln oder halbieren das Fenster, auch mit den Tasten - und +. Ein Live-Fenster bleibt live.
• Zieh über ein Trend-Chart, um in diesen Abschnitt zu zoomen. Unter sechs Stunden laden die Charts minütlich neu.
• Zu jetzt springen schiebt ein vergangenes Fenster bei gleicher Länge in die Gegenwart.
• „Minütlich" geht auch bei langen Fenstern und kürzt sie auf ihre letzten 6 Stunden. Die Pfeile blättern dann in 6-Stunden-Schritten.
• Die Auflösung ist eine Reihe Kacheln, jede mit der Zahl der Intervalle, die sie ergibt, oder mit dem Grund, warum sie nicht passt.
• Datum und Uhrzeit sind eigene Felder und greifen sofort, einen Übernehmen-Button gibt es nicht mehr. Das Ausdrucksfeld nimmt eine Uhrzeitspanne wie 14:00-16:30.
• Eine Zeitleiste oben zeigt das Fenster auf den Tagen drumherum. Zieh es, zieh an einer Kante, oder scroll und pinch zum Zoomen.

Doku: Analytics → Zeitraum.

page_type.url_rules nimmt bis zu 10 URL-Muster, jedes mit einem Page-Type, und das erste passende gewinnt. Das ist für einen Shop gedacht, dessen Body-Klassen nichts verraten, etwa ein Headless-Storefront, und braucht keine Tracker-Änderung. Im Dashboard findest du sie als URL-Regeln unter der Page-Type-Detection.

• Die Quellen greifen in dieser Reihenfolge: Header, deine Body-Klassen, deine URL-Regeln, das Ruleset der Plattform, die Shopify-Routen, zuletzt die Checkout-Stufe.
• Ein Warenkorb-, Checkout- oder Erfolgs-Pfad liefert einen Page-Type, wenn sonst nichts greift: cart für den Warenkorb, checkout für die beiden anderen. Seitenaufrufe von vor dem 29.09.2026 behalten ihren leeren Page-Type.
• GET /applications/{app_id}/page-type-sources listet die Quellen einer Application in dieser Reihenfolge, jede mit dem Page-Type, den sie speichert. Auch Viewer dürfen das lesen.

Doku: Applications → Page-Type-Detection.

Bei einer OXID-Application behält die gespeicherte URL den Controller cl, etwa /index.php?cl=thankyou, auch ohne collect_query_values_for. Die URL-Reports zeigen ab dem 29.09.2026 eine Zeile pro Controller, andere Query-Werte fallen weiter weg.

• Der Checkout-Funnel braucht keine eigenen Pfade. basket markiert den Warenkorb, user, payment und order den Checkout, thankyou den Abschluss. Deine eigenen *?cl=*-Muster haben weiter Vorrang.
• Der Page-Type kommt aus dem Controller, wenn Header, deine Regeln und die Body-Klasse nichts geliefert haben. details ist product, thankyou ist checkout.

Doku: Checkout-Funnel → OXID.

Die Checkout-Zahlen auf der Analytics-Seite lesen sich wie ein Shop-Bericht.

• Conversion ist eine Kennzahl über dem Hauptchart, gezeichnet gegen die Vorperiode. Der Tooltip nennt die Besucher hinter jedem Punkt, den Anteil mit Warenkorb, die mit kaputtem Warenkorb und die Zeit bis zum Kauf.
• Abgeschlossene Checkouts heißen Bestellungen. Die letzte Funnel-Stufe heißt „Bestellt", in den Filtern, den Chips und im Explorer.
• Business Impact zeigt dieselbe Conversion-Rate, Käufer durch alle Besucher. Bisher wurde durch die Besucher mit Warenkorb geteilt.
• Die Checkout-Karte nennt die Besucher mit kaputtem Warenkorb und wie lange ein Kauf dauert, als Median und p90.
• Käufer im Vergleich ist eine Tabelle ganz unten auf der Seite, zugeklappt, bis du sie öffnest. Sie stellt Käufer den Besuchern gegenüber, die ohne gesehenen Kauf bis in den Checkout kamen, je Funnel-Stufe.
• Die Checkout-Zahlen folgen den Filtern der Seite, Bestellungen eingeschlossen, außer Filtern, die eine Checkout-Stufe wählen.
• Sie erscheinen nur bei einem Shop. Eine Application mit unbekannter Plattform gilt als Shop, bis du sie als keinen markierst.

Doku: Checkout-Funnel → Wo es auftaucht.

Der Explorer und POST /analytics/query gruppieren Seitenaufrufe nach status_code, Fehlerseiten wie 404 oder 500 werden so zu eigenen Serien. Seitenaufrufe, deren Browser keinen Status meldet, meist Firefox und Safari, bilden die Gruppe „Nicht gemeldet", auf der API 0. Benachrichtigungsregeln filtern ebenfalls auf status_code, und die Gruppierungsauswahl im Explorer hat ein Suchfeld. Doku: Analytics → Der Explorer.

POST /analytics/query liefert für lcp, inp, cls und ttfb den Anteil der Seitenaufrufe, die gut, verbesserungswürdig und schlecht bewertet sind, als good_share, needs_improvement_share und poor_share. Die drei Anteile eines Buckets ergeben zusammen 1, gerechnet über die Seitenaufrufe mit diesem Messwert und mit den Schwellenwerten des Experience Score. So siehst du pro Stunde einen langsamen Ausläufer, wo sich der p75 kaum bewegt. Jede andere Metrik in derselben Anfrage ergibt 422.

compare_to: previous_period liegt jetzt so wenige ganze Wochen zurück, wie das Fenster braucht, mindestens eine. Freitag bis Montag wird mit Freitag bis Montag der Vorwoche verglichen, 30 Tage gehen fünf Wochen zurück.

• Bis 7 Tage entspricht das previous_week. Die letzte Stunde gegen die Stunde direkt davor gibt es nicht mehr.
• compare_to: previous_day vergleicht mit demselben Fenster 24 Stunden früher, auf /analytics/query und im Checkout-Funnel. Das Dashboard bietet es noch nicht an.
• Das Dashboard vergleicht genauso, auch bei „Neu" und „Steigend" in der Fehlerliste, bei Seitenaufrufen pro Besucher und beim Experience Score unter Business Impact.

Doku: Analytics → Das Dashboard.

Eine Abfrage mit compare_to_release_id lieferte 500, sobald das Release im Fenster lag, und gibt jetzt die Aufteilung in vorher und nachher zurück. Ein released_at mit UTC-Offset wie +02:00 wird zum richtigen Zeitpunkt gespeichert. Releases, die vor dem Fix so angelegt wurden, behalten die falsche Zeit, bis du sie bearbeitest.

Eine Tabelle pro URL mit vielen Perzentilen, etwa der Response-Breakdown über 90 Tage, bricht auf Sites mit einigen tausend Seiten nicht mehr ab. Perzentile aus einzelnen Seitenaufrufen rechnen jetzt wie die aggregierten Tabellen, bei den Zeit-Metriken mit einer Obergrenze von 30 s. Ein solches Perzentil kann leicht von früheren Werten abweichen und hängt nicht mehr davon ab, welche Tabelle das Fenster bedient. Benachrichtigungsregeln rechnen weiter ohne Obergrenze.

get_errors und get_error_detail nennen in jedem Stack-Frame den Skriptpfad, etwa www.example.com/js/theme.js:1:77801. Ein Frame auf einem geteilten Host zeigt damit, ob er in deinem Bundle oder in einem Drittanbieter-Skript sitzt. get_errors liefert bis zu fünf Frames pro Signatur statt drei, und die Nachricht einer Signatur kommt nicht mehr leer zurück, wenn ein Teil der Zeilen ohne Fehlermeldungen erfasst wurde. Doku: MCP → Was das Modell lesen kann.

Unter Fehler → Network Error Logging siehst du die fehlgeschlagenen Requests, die Chromium-Browser für deine Seite melden. Dazu gehören auch Seiten, die nie geladen haben und den Tracker deshalb nie ausgeführt haben. Voraussetzung sind die NEL-Header auf deiner Seite.

• Drei Tabs: Übersicht, Pfade und Reports. Der Tab steht in der Adresse, ein Link öffnet also dieselbe Ansicht.
• HTTP-Fehler stehen oben, Serverfehler vor Clientfehlern. Jede Zahl nennt zuerst die betroffenen Besucher mit ihrem Anteil an allen Besuchern, danach die Reports.
• „Wo sie scheitern“ zeigt jede Dimension als Karte: Statuscodes, Seiten, Länder, Seiten und Hosts, Serveradressen, Geräte, Browser, OS und Traffic. Eine geöffnete Karte nimmt die ganze Zeile ein.
• Seiten und Hosts ist gleichzeitig der Setup-Check. Jede Site zeigt ihren letzten Report, eine Site ohne Report sagt das. Zeigen die meisten Reports ohne Details auf eine Serveradresse, nennt die Karte sie als wahrscheinlich ausgefallen.
• Verbindungsfehler haben einen eigenen Abschnitt, standardmäßig zugeklappt. Er vergleicht sie mit ihrem üblichen Niveau und meldet ein kaputtes Zertifikat sowie einen Anstieg bei abgelehnten oder abgelaufenen Verbindungen, unbekannten Hosts oder Reports ohne Details.
• Reports listet jeden NEL-Report mit seiner Klasse. Mehrere Reports eines Besuchers auf einer Seite hintereinander fasst die Liste zu einer Zeile mit Anzahl zusammen. Jeder Report öffnet alle gespeicherten Felder, hat einen eigenen Link zum Teilen und verlinkt auf die Journey des Besuchers.
• Die Journey eines Besuchers zeigt seine NEL-Reports zwischen den Pageviews, in zeitlicher Reihenfolge, als solche markiert und mit dem Fehlertyp in Klartext.
• Abgebrochene Ladevorgänge bleiben ausgeblendet, auf der Seite und in der Journey. Ein Schalter blendet sie ein.
• Das + neben einem Wert filtert darauf, das - schließt ihn aus, und die Lupe öffnet die Reports der Zeile. Die Kacheln 5xx und 4xx filtern eine ganze Statusklasse. Die Filter bleiben in der Adresse und stehen im Filter-Panel unter „Nur auf dieser Seite“. Ein Seiten-Icon am Filter-Button zeigt das an.

Doku: Network Error Logging → Die Seite im Dashboard.

JavaScript-Fehler, Fehlgeschlagene Ressourcen und Network Error Logging sind jetzt drei Seiten unter Fehler, jede mit eigener Adresse, Breadcrumb und Eintrag in der Command Palette. Alte Links auf einen Tab öffnen die neue Seite mit ihrem Zeitraum und ihren Filtern. Doku: Analytics → Error Analytics.

Zwei neue Felder an jedem Report zeigen dir, was fehlgeschlagen ist und wo.

• nel_class sagt, was ein Report bedeutet: http_error, connection, abandoned, downgraded oder other. Die Klasse wird beim Lesen abgeleitet, ältere Reports haben sie also auch.
• server_ip ist die Adresse deines Servers, an die der fehlgeschlagene Request ging. Gespeichert wird nur eine öffentliche Adresse, Reports von vor dem 28.09.2026 haben keine.
• Beide sind Filter mit exclude und Breakdown-Dimensionen auf POST /analytics/nel.
• Steigt downgraded auf einer Site mit zwei Adressen, fällt eine davon aus, und server_ip nennt sie.
• Zwei lange Chromium-Fehlertypen gehen nicht mehr verloren. Ein Fehlertyp darf jetzt bis zu 64 Zeichen lang sein.

Doku: Network Error Logging → Mehrere Serveradressen.

Mit zwei Response-Headern auf deiner Seite melden Chromium-Browser jeden fehlgeschlagenen Request an https://fastmon.site/c/n/{collector_hash}. Das umfasst DNS-Fehler, abgelehnte Verbindungen, Timeouts und 5xx-Seiten, die den Tracker nie ausgeführt haben.

• Nur Chromium. Safari und Firefox senden keine Reports, jede Zahl ist also eine Untergrenze.
• Der Host des Reports muss eine Site der Application sein oder eine Subdomain davon. Ein Report legt nie eine Site an.
• Ein Report speichert Fehlertyp, Phase, HTTP-Status, Zeit bis zum Fehler, Methode, Protokoll, die gekürzte URL, die Seite, von der er kam, und die Hauptversion des Browsers. Dazu kommen die Besucherkennung unter store_stitch und die Edge-Labels, der User-Agent wird verworfen.
• Cloudflares eigene NEL-Einstellung ersetzt deine Header, und Shopify-Storefronts können sie nicht setzen.

Doku: Network Error Logging einrichten und Datenschutz → NEL-Reports.

Drei Routen unter /organizations/{org_id}/analytics/nel lesen die Reports. Sie nehmen den Site-Scope sowie die Besucher- und Edge-Label-Filter der anderen Analytics-Routen.

• POST …/nel liefert die gewichtete Anzahl, die Zeitreihe, die Zahlen pro Fehlertyp und Statuscode und die am stärksten betroffenen Paare aus Host und Pfad. affected_visitors zählt eindeutige Besucher, wo die Site stitch speichert, und elapsed_by_error_type gibt p50, p75 und p95 der Zeit bis zum Fehler.
• POST …/nel/breakdown gruppiert die Reports nach einer dimension, etwa page_url, host, browser_version oder site_id. Eine site_id-Zeile trägt mit last_seen_at ihren letzten Report.
• POST …/nel/reports listet einzelne Reports, neueste zuerst, geblättert per cursor, und filters.report_id wählt einen aus. visitor_id verlinkt einen Report auf die Journey des Besuchers.
• Eigene Filter: error_type, status_code_range, host, path und page_url, alle außer dem Bereich auch als exclude. Jede andere Analytics-Route beantwortet sie mit 422.
• Ohne error_type-Filter zählt auch abandoned. Schließ es aus, um Besucher auszublenden, die gegangen sind, während noch etwas lud.
• Besucherdetail und Checkout-Journeys liefern nel_reports neben pages und events, bis zu den letzten 100 pro Besucher.
• Umbenannt am 28.09.2026. Bis dahin hießen die Routen …/network-errors, die Klasse network_error_class und die Liste network_errors. Die alten Namen antworten mit 404.

Doku: Network Error Logging → API.

Der Beacon enthält jetzt den HTTP-Status des Dokuments als rs, gelesen aus responseStatus des Navigation-Eintrags. So erkennst du einen Pageview einer Fehlerseite, die trotzdem den Tracker lädt.

• Unbekannt ist 0, nie 200. Firefox, Safari und Soft Navigations melden keinen Status, und ein Wert außerhalb von 100 bis 599 wird als 0 gespeichert.
• status_code steht in jeder Zeile von POST /analytics/beacons, und metric_ranges nimmt ihn an: {"metric": "status_code", "gte": 400} listet Fehlerseiten. MCP und Ask kennen denselben Filter.
• Der Explorer zeigt den Status als Spalte unter "Network & context", und HTTP status >= 400 in der Filterleiste listet Fehlerseiten.

store_stitch, count_visitors_by und data_retention_days gibt es an Sites nicht mehr, weder in der API noch in den Site-Einstellungen. Eine Site übernimmt den Wert ihrer Application, und schickt ein Request die Keys noch mit, werden sie ignoriert. Eine Domain, die andere Werte braucht, gehört in eine eigene Application. Docs: Applications → Datenschutz-Einstellungen für alle Sites.

Analytics → Shopfloor zeichnet deinen Shop als Zonen nach Seitentyp. Jeder aktuelle Besucher steht als Punkt auf der Seite, die er gerade ansieht.

• Besucher bewegen sich, wenn die Daten es tun. Ein neuer Besucher kommt über seine Traffic-Quelle herein, ein Klick führt quer über die Fläche, und ein Kauf läuft zum Ausgang, auf Wunsch mit Kassenklingeln.
• Das Zeitfenster ist 5, 15, 30 oder 60 Minuten. Die Hauptzahl, die Bestellungen und die Zahlen jeder Zone folgen ihm.
• Besucher, Bestellungen und Conversion Rate von heute zählen ab deiner eigenen Mitternacht, jeweils neben demselben Wochentag der Vorwoche. Eine Zeitleiste darunter zeigt Besucher pro Stunde und eine Prognose für den Tag.
• Ein Klick auf eine Zone führt hinein, mit ihren Seitentypen und ihren Top-10-URLs, die sich jeweils im Explorer öffnen.
• Gemacht für einen Monitor an der Wand. ?window=60&sound=1&kiosk=1 öffnet ihn fertig eingestellt, auf dem Handy steht die Fläche hochkant.
• Er braucht store_stitch, und eine Site ohne sagt das. Bots folgen dem Traffic-Scope, der Filter bietet Land, Gerät, Seitentyp und Traffic.
• Die API dahinter sind POST /analytics/live, POST /analytics/live-summary mit optionaler timezone und GET /platforms/{platform}/page-types. Letztere sortiert die Seitentypen einer Plattform in Gruppen, die für jede Plattform gleich sind.

Doku: Analytics → Shopfloor.

fastmon erfasst jetzt pro Stufe, wie viel Frische eine gecachte Seite noch hatte, als cdn_ttl und origin_ttl in Sekunden. Alter plus TTL ergibt die konfigurierte Lebensdauer.

• CDN-eigene Keys funktionieren ohne Änderung an deiner Seite: cdn-cache-age, cdn-cache-ttl, origin-cache-age und origin-cache-ttl, jeweils mit den Sekunden in desc. Sie erscheinen nicht mehr als Serverphase, und die fm-*-Keys gewinnen, wenn beide gesendet werden.
• Die Cache-Seite zeigt die Frische pro Stufe als Balken aus Alter und verbleibender TTL, mit p50, p75 und p95, auch pro Seitentyp. Ein Chart mit Median von Alter und TTL über die Zeit zeigt einen Purge als Alter, das auf null fällt.
• Der Explorer bietet CDN age, CDN TTL, origin age und origin TTL als Metriken, Spalten und Filter. POST /analytics/server-timing liefert einen cache_ttl-Block, und Benachrichtigungsregeln, MCP und Ask kennen beide TTLs.

Doku: Server-Timing → Cache-TTL.

Mehrere Änderungen machen beide Seiten leichter zu lesen und zu filtern.

• Die Spalten für Alter und TTL sind Mediane und passen damit zur Karte zur Cache-Frische.
• Karte und Tabelle zum Cache-Status filtern beim Hover, Plus behält einen Status, Minus schließt ihn aus. Die Tabelle teilt auf Wunsch nach Seitentyp auf.
• Eine geöffnete Zeile in der Phasentabelle von Server-Timing zeigt jede Phase über die Zeit, eingeschränkt auf diese Zeile.
• Die Karte der Origin-Hosts zeigt den Traffic-Anteil jedes Hosts im Vergleich zu einer gleichmäßigen Verteilung.
• Die Legende des Trends zeigt Durchschnitt, Maximum und letzten Wert pro Linie, ein Klick blendet eine Linie aus oder ein.
• Behoben: Der Trend nach Host oder Login läuft auf kurzen Zeiträumen wieder bis zum Ende, und Hit-Raten im Explorer zeigen bei gewähltem Perzentil nicht mehr 0 %.

Der Traffic-Chart stapelt die Pageviews in die drei Traffic-Klassen. Jeder Pageview zählt so einmal, und die Bänder ergeben zusammen die Gesamtzahl. Vorher waren Bots und Rechenzentrums-Traffic zwei überlappende Reihen, und ein Googlebot-Pageview wurde doppelt gezeichnet. Die Besucherlinie zählt immer echte Besucher, und der Chart hat einen Share-Link auf ?panel=traffic.

Gibt es eine Application unter einem Namen als prod und als dev, steht prod jetzt zuerst: auf der Seite der Applications, im Site-Switcher und in der Command Palette. Ansonsten liefern die Listen der Applications und Sites den neuesten Eintrag zuerst, und beim Blättern durch die Site-Liste wiederholt oder überspringt sich keine Site mehr.

Die Route verlangte eine application_id, die kein Client mitschickte, sie hatte also keinen funktionierenden Aufrufer. Leg eine Domain stattdessen mit POST /applications/{app_id}/sites an. GET auf dem Pfad der Organization bleibt unverändert.

Ein CDN liefert den Server-Timing-Header des Origins bei jedem Hit erneut aus. Eine Seite aus der Edge zeigte dadurch die Backend-Zeit des Requests, der den Cache einmal gefüllt hat. Bei einem Pageview mit CDN-Status HIT, STALE, UPDATING oder REVALIDATED werden die Origin-Phasen und eigenen Zeit-Keys jetzt weder gespeichert noch gezählt.

edge_dur, die Cache-Status, Alter und TTLs zählen weiter. Origin-Perzentile können sich deshalb verschieben, und auf gut gecachten Sites sinken die Zahlen. Docs: Server-Timing → Backend-Phasen.

GET /applications/{app_id}/sampling-recommendation sagt, welche Rate der Traffic der letzten sieben Tage zulässt: 0.1, 0.25, 0.5 oder 1.0. Sie nennt die entscheidende Regel und die Pageviews dahinter und ändert die konfigurierte Rate nie. inputs.checkout.status sagt, ob der Checkout entschieden hat, und ein dünner Checkout erzwingt nicht mehr 1.0. Doku: Applications → Sampling-Empfehlung.

"Share of visitors kept" unter Data & privacy setzt die Sampling-Rate der Application. Seiten mit hochgerechneten Zahlen zeigen neben dem Titel ein Sampling-Badge, das erklärt, welche Zahlen hochgerechnet sind. Doku: Applications → Traffic-Sampling.

granularity=minute funktioniert auf den Zeitreihen für Checkout-Stufen, Checkout-Funnel, Fehler- und Failed-Resource-Detail und den Stitch-Vergleich, für Zeiträume bis 6 Stunden. Ein längerer Zeitraum antwortet mit 422, und auto liefert bis 48 Stunden weiter stündlich. Der Checkout-Chart nutzt das auf den Zeiträumen von 15 min bis 6 h und zeigt eine Kurve statt Spitzen zur vollen Stunde.

collection.sampling_rate an der Application legt fest, von welchem Anteil der Besucher die Beacons gespeichert werden, standardmäßig 1.0.

• Die Edge entscheidet einmal pro Besucher. Die Pageviews eines Besuchers bleiben also komplett erhalten oder fallen komplett weg. Eine neue Rate greift nach etwa einer Minute.
• Traffic-Zahlen werden hochgerechnet, auf jedem Analytics-Endpoint, in Ask, im MCP und in der Wochen-Mail. Perzentile, Anteile und Mindeststichproben rechnen weiter mit den gespeicherten Zeilen.
• Gespeicherte Zeilen zählen weiterhin im Beacon-Explorer, bei den Funnel-Stufen und in den Histogrammen.
• Die kleinste Rate ist 0.1. Alles darunter lehnt die API ab. Gesampelt wird nur eine Application, die stitch speichert, Checkout-Events nie.
• meta.sampling in jeder Analytics-Antwort nennt die niedrigste Rate, die im Scope konfiguriert ist, und ob sie unter 1.0 liegt.

Doku: Applications → Traffic-Sampling.

Der Tracker liest window.__FASTMON_SAMPLE_RATE nicht mehr. Eine Seite, die es noch setzt, sendet jeden Pageview. Sampling ist jetzt die Application-Einstellung collection.sampling_rate und wird an der Edge pro Besucher entschieden. Doku: Applications → Traffic-Sampling.

Der Abschnitt zeigt die Welt als Globus oder als flache Karte, neben der Länderliste.

• Der Globus öffnet dort, wo dein Traffic ist. Ein Shop, der in einen Markt verkauft, landet auf diesem Markt. Ziehen dreht ihn, das Mausrad zoomt, Pfeiltasten und Plus/Minus gehen auch.
• Die flache Karte hält die Pole im Maßstab, Grönland sieht also nicht mehr wie ein Kontinent aus. Zoom- und Reset-Knöpfe sitzen direkt auf der Karte.
• Die gewählte Ansicht steht in der URL. Neu laden oder ein geteilter Link öffnet dieselbe.
• Ein Klick auf ein Land zeigt seine Filter-Buttons. Die Hervorhebung folgt dem Mauszeiger und bleibt nicht mehr hängen.
• Der Abschnitt hat auf dem Dashboard eine Überschrift.

Die Checkout-Events eines Shopify-Pixels tragen jetzt dieselbe Besucherkennung wie die Pageviews des Shops. Der Funnel zählt einen Käufer nicht mehr doppelt, und die Journey des Besuchers zeigt den Checkout. Events von vor der Umstellung bleiben getrennt.

Bei der Umstellung hat sich jede Besucherkennung einmal geändert, wie bei der täglichen Salt-Rotation. Eine Application mit mehreren Domains zählt einen Besucher jetzt über alle hinweg nur einmal. Doku: Privacy → stitch.

Checkout gestartet, Zahlung abgeschickt und Bestellung aufgegeben stehen jetzt zwischen den Pageviews, in der Reihenfolge, in der sie passiert sind. Ein Event von vor dem gewählten Zeitraum steht mit negativem Versatz da. Nach Session gruppiert sagt die Journey, warum die Checkout-Hälfte fehlt.

Die Liste hatte einen Filter „mindestens 3 Seiten" aktiv, den niemand gesetzt hatte, und Besucher mit einer oder zwei Seiten fehlten. Alle Filter starten jetzt leer, und der Seitenzahl-Filter funktioniert weiter, wenn du ihn setzt.

Ein Name, ein Typ und eine Skala pro Begriff, in Responses, Request-Bodies und Query-Parametern gleichermaßen.

• Zeit heißt timestamp. Jeder Punkt einer Zeitreihe, jedes Event und jede Journey-Zeile antwortet damit, statt mit at, t, bucket oder ts.
• Anteile sind Brüche von 0 bis 1. share, with_error_share, relative_change und progress ersetzen percentage, percentage_of_total, share_pct, change_percent und percent.
• First Party gegen Third Party ist ein Feld, ownership, mit den Werten first_party, third_party und mixed. Es ersetzt bucket, is_first_party und by_bucket.
• Dauern und Zähler tragen ihre Einheit und ihr Substantiv: duration_ms, p75_ms, time_to_success_seconds, error_count, frame_count, sample_count.
• Geschlossene Wertelisten sind Enums, darunter die Funnel-stage, granularity, device_type und identity. Ein generierter Client bekommt einen Typ statt eines freien Strings.
• Kein Response-Feld ist mehr nullable. 444 deklarierten T | null für einen Wert, den die API nie schickt: Ein Feld ohne Wert fehlt einfach. Auf dem Draht ändert sich nichts, ein generierter Client sieht jetzt ein optionales Feld.
• Jeder deprecated Name nennt seinen Nachfolger über x-replaced-by im OpenAPI-Dokument, eine Migration lässt sich also aus der Spec fahren.

Doku: API → Analytics (nur auf Englisch).

Bisher lagen Antwort, Paging und ein Echo des Requests in einem flachen Objekt.

• meta trägt die Fakten zur Antwort: execution_time_ms, bei einer Liste dazu total, limit, offset und has_more an einer Stelle.
• request trägt, womit der Server tatsächlich gerechnet hat: den Zeitraum mit einem relativen Fenster schon in seine zwei Enden aufgelöst, die Bucket-Breite, die Identität und die Filter.
• Jede Liste antwortet mit ihren Zeilen unter data. meta.total ist überall die Zahl der Zeilen, die die Liste vor dem Paging getroffen hat.
• Eine Summe über ein Top-N hat einen eigenen Namen (frame_count, failed_count, resource_count, size_bytes, beacon_count) und wird so nie als Zeilenzahl gelesen.
• Alle zwanzig Analytics-Responses tragen die beiden Objekte, auch POST /analytics/query und POST /analytics/histogram.

228 Stück, über Analytics, Synthetic, Notifications, Applications, Issues und Partner. Für jeden gab es seit der Release, die ihn deprecated hat, einen Ersatz, und jeder ist aus dem OpenAPI-Dokument raus, ein generierter Client bietet ihn also nicht mehr an.

• Ein Request mit einem alten Body-Key wird abgelehnt. Ein übrig gebliebenes id, bucket, first_party, range_days oder mute_until ist ein 422, der den Key nennt, statt eines Schreibvorgangs, der verschwindet.
• Das Usage-Fenster behält seine alten Namen für zwei weitere Releases. period_start, period_end und total_beacons auf GET /organizations/{org_id}/usage und auf der Partner-Usage-Route antworten weiter, denn usage:read ist ein Kunden-Scope.
• Die Application behält sechs flache Felder für das Shopware-Plugin: source_hash, collector_hash, proxy_secret, collector_mode, collector_endpoint und pagetype_ruleset.

• Das Checkout-Chart zählt den Shopify-Checkout mit. Die Stufenzahlen kommen jetzt aus den Checkout-Events und den Seiten-URLs, das Chart passt also zur Funnel-Karte darunter, statt leer darüber zu stehen.
• Alle drei Stufen werden gleich gegen die Vorperiode verglichen. Es waren drei getrennte Abfragen, und ein Vergleich, der für eine ankam und für die anderen nicht, ließ den Funnel unterschiedlich gemessen aussehen.
• Eine Shopify-Application verweist auf ihren Pixel-Guide, vorausgefüllt mit den eigenen Hashes. Das Embed-Snippet jeder Application verschwindet, sobald ihr erstes Beacon ankommt.
• Die Karte sagt, wann das letzte Checkout-Event ankam, du siehst also, dass das eingefügte Pixel meldet. Sie warnt zuerst, wo das Besuchersignal aus ist, denn ohne das sind die Events unbrauchbar.
• Besucher mit abgeschickter Zahlung stehen neben den abgeschlossenen Checkouts, nie als eigene Stufe. Abgeschlossene Checkouts eines Shopify-Shops sind als Untergrenze gekennzeichnet.
• Eine Stufe über der davor erklärt sich selbst. Bei Shopify ist das Alltag: Wer direkt in den Checkout springt, lädt nie eine Warenkorbseite.
• Ein nach Session gruppierter Funnel sagt, warum seine Checkout-Hälfte fehlt: Die Pixel-Events tragen keine Session-ID. Das Rotieren der Hashes warnt jetzt, dass es ein installiertes Pixel kaputt macht.
• Behoben: Die gemessene Conversion-Rate auf der Business-Seite wurde nie angezeigt. Sie las ein Feld, das die API umbenannt hatte, und die Seite fiel auf ihre Schätzung zurück, auch bei einem Shop mit meldendem Funnel.

Doku: Checkout-Funnel → Shopify-Checkout-Events.

• Eine Events-Seite im Explorer, eine Zeile pro Event, das der Tracker gemeldet hat. Nach Typ filtern, durchblättern und den Besucher öffnen, zu dem eine Zeile gehört.
• Sie erscheint für Organisationen, deren Applications Events erzeugen können, heute also für einen Shopify-Shop mit seinen drei Checkout-Events.
• Der Funnel verlinkt dorthin, „stimmt diese Zahl?" hat damit ein Ziel. Eine leere Liste sagt, dass im Zeitraum nichts ankam, nicht dass ein Pixel fehlt.
• Auf der API kommen dieselben Zeilen aus POST /analytics/events, neueste zuerst und cursor-paginiert.

Die flachen Zwillinge der gruppierten Einstellungen antworten nicht mehr. Lies sie aus collection, shop.checkout, page_type, script, site_defaults und collector.proxy_secret, die seit 2026.9.27 dieselben Werte tragen.

• Entfernt: collect_sessions, collect_fetch_xhr, collect_error_messages, collect_error_frames, collect_query_keys, collect_query_values_for, session_consent, template_url_ids, checkout_tracking, die drei Checkout-Pfadlisten, pagetype_rules, source_version, data_retention_days, store_stitch, count_visitors_by und die zwei Proxy-Secret-Felder.
• Create und Update lehnen jeden unbekannten Key ab. Ein entferntes flaches Feld ist ein 422, der es nennt, ein Schreibvorgang verschwindet also nie stillschweigend.
• Das gilt auch für Read-only-Felder aus einem GET, etwa id, source_hash, site_count oder created_at. Ein Read-Modify-Write-Client muss nur noch schicken, was er ändert.
• Das Shopware-Plugin ist nicht betroffen. Seine sechs Felder bleiben flach, und collector_mode und collector_endpoint werden flach wie unter collector weiter angenommen.

Doku: Applications → Felder einer Application.

• Der Site-Status meldet Checkout-Events, ein eingefügtes Pixel wird damit sichtbar. events_today, last_event_at und events_available stehen neben den Beacon-Feldern, und ein gesetztes last_event_at beweist, dass das Pixel meldet.
• Die Journey eines Besuchers trägt den Checkout. POST /analytics/visitors/detail antwortet mit events neben pages, je mit Name, Funnel-Stufe, Quelle und Zeit. Die beiden Arrays verschränkst du nach Zeit.
• Der Besucherfilter findet einen Shopify-Käufer. contains_checkout_stage zählt ein Checkout-Event als erreichte Stufe. Jede Zeile ist weiter eine Pageview-Zeile, ein Besucher, den nur Events kennen, hat also keine.
• Neu POST /analytics/funnels/checkout/stages meldet pro Stunde oder Tag die Besucher, die Warenkorb, Checkout oder Abschluss erreicht haben, Events eingeschlossen. Ein compare_to, das hinter den Installationstag des Pixels reicht, zeigt die Installation als Anstieg.
• Neu POST /analytics/events listet die Events selbst, neueste zuerst und cursor-paginiert, eine Testbestellung lässt sich also gegen die Shopify-Bestellliste halten. Ein Filter ohne Spalte auf der Events-Tabelle ist ein 422, der ihn nennt.

Doku: Checkout-Funnel → API.

Shopify betreibt den Checkout auf eigener Infrastruktur, wo dein Theme-Skript nie lädt. Der Funnel endete deshalb am Warenkorb.

• Ein Snippet einfügen, im Shopify-Admin unter Einstellungen → Kundenereignisse → Custom Pixel. Es meldet drei Schritte: Checkout betreten, Zahlung abgeschickt, Bestellung aufgegeben.
• Das Dashboard verlinkt auf den Guide, mit den Hashes deiner Application in der URL, das Snippet dort ist also fertig zum Einfügen.
• Mit eigenem Collector ist auch das Pixel First-Party. Das Skript lädt von deinem Host, der Checkout macht also keinen Third-Party-Request. Dein Proxy muss /s/e/* und /c/e/* weiterleiten.
• Gemessen wird sonst nichts. Keine Web Vitals, keine Ladezeit und keine Fehler aus dem Shopify-Checkout.
• Ein Event trägt den Schritt, Land, Gerät, Browser und Traffic-Klasse des Besuchers sowie die Edge-Kennung. Keine URL, keine Session-ID, kein Bestellwert, nichts, was Shopify über den Kunden weiß.
• store_stitch muss an sein. Ohne die Edge-Kennung bleiben die Checkout-Zahlen leer.
• Setze Berechtigung auf „Nicht erforderlich" und Datenverkauf auf „gilt nicht als Datenverkauf". Mit Shopifys Voreinstellung wartet das Pixel auf Marketing-Einwilligung, und die beiden Hälften deines Funnels beschreiben dann verschiedene Gruppen.
• Rotierst du die Hashes der Application, stoppen die Events. Die alte Skript-URL antwortet still mit 404, füge nach einer Rotation also das neue Snippet ein.
• Content-Blocker stoppen das Pixel. Die EasyPrivacy-Liste des EasyList-Projekts blockt den Sandbox-Pfad von Shopifys Custom Pixels, und uBlock Origin liefert sie ab Werk mit. Diese Besucher schicken Storefront-Pageviews und keine Checkout-Events.
• Käufe sind eine Untergrenze. Shopify feuert sein Checkout-abgeschlossen-Event bei den meisten Shop-Pay- und Apple-Pay-Bestellungen nicht.

Doku: Shopify-Checkout messen.

Der Funnel liest die Events des Pixels neben den Pageviews, und das verschiebt in einem Shopify-Shop ein paar Zahlen.

• Eine Bestellung erreicht success, ein betretener Checkout erreicht checkout, ohne Pageview auf beiden. Besucher, die nur im Checkout auftauchen, zählen in visitors_total mit, die Conversion-Rate bleibt also bei höchstens 100 %.
• Neu payment_submitted_visitors: Besucher, die die Zahlung abgeschickt haben. Das Feld steht neben den Schritten, ist selbst keiner, und fehlt statt 0 zu sein, wenn kein Event gelesen wurde.
• Zahlung ohne Kauf heißt meistens Wallet-Bestellung. Genau das macht den Success-Schritt zu einer Untergrenze.
• Eine Rate von über 100 % zwischen Warenkorb und Checkout ist jetzt normal. Wer direkt in den Checkout springt, hat nie eine Warenkorbseite geladen, und die Schrittraten bleiben ungekappt.
• Ein Filter, den die Event-Zeilen nicht beantworten können, lässt sie außen vor: URL, Seitentyp, Kampagne, ein Metrik-Schwellwert.
• Der Kohortenvergleich zählt nur Besucher mit Pageview. Ein Käufer, dessen ganzer Lauf aus Checkout-Events besteht, steht im Success-Schritt und in keiner Kohorte.
• Sessions-Explorer, Session-Detail und Journey lesen die Stage weiterhin aus den Pageviews.

Doku: Checkout-Funnel → Shopify.

Dieselbe Zahl hatte mehrere Namen, in beiden Sprachen. Jeder Begriff hat jetzt ein Wort.

• Ein Seitenaufruf ist ein Pageview, eine Person ein Besucher. Das Dashboard sagte außerdem Aufrufe, Besuche, Sitzungen und Unique Visitors.
• Labels, die die falsche Zahl benannt haben, sind korrigiert. „Views pro Besuch" teilte Pageviews durch Besucher und heißt jetzt „Pageviews pro Besucher".
• Seite und Site sind auseinanderzuhalten. Eine Site bleibt eine Seite; eine Seite in einer Liste, Spalte oder Zählung ist eine URL.
• Eine Bewertungsskala: Gut / Verbesserungswürdig / Schlecht. Die Parallelskalen (Okay, Needs work, schnell / okay / langsam) sind weg.
• Ein Wort für den gemessenen Zeitraum. Es ist ein Zeitraum, kein Fenster und keine Spanne.
• Labels sind in Satzschreibweise. Produkt- und Spezifikationsnamen behalten ihre Großschreibung: Core Web Vitals, Largest Contentful Paint, Speed Index, Service Worker, Early Hints, Best Practices.
• Leere Charts sagen „Keine Daten im gewählten Zeitraum". Die alte Formulierung nannte Besucher, auch auf Charts, die keine zählen.

Ein kaputtes Skript füllte vier der fünf obersten Zeilen. Browser melden dieselbe Codestelle ein paar Zeichen versetzt, und ein zweiter Aufrufer ist ein zweiter Stack.

• Eine Zeile ist ein Fehler, keine Signatur. Sie zählt alle Varianten und sagt, für wie viele Signaturen sie steht.
• „Neu", „Steigend", Sparkline und betroffene Pageviews gelten für die ganze Gruppe. Eine Zeile liest sich nicht mehr als neu, nur weil ihre größte Signatur gewechselt hat.
• Die Detailseite einer Signatur wechselt zwischen den Varianten ihres Fehlers. Gespeicherte Fingerprints ändern sich nicht, es wird nichts neu gruppiert.
• POST /analytics/error-types nimmt group_variants, standardmäßig aus. Eine gruppierte Zeile trägt die Summe und listet jeden Fingerprint in variants.
• Vergleiche Zeilen über Zeiträume hinweg anhand ihrer Varianten. Der fingerprint der Zeile ist ihre größte Variante und kann wechseln.

Doku: Analytics → Error Analytics.

Eine Application hält jetzt fest, welche Plattform sie nutzt, ob sie ein Shop ist und ob sie eine Single-Page-App ist.

• platform hält Shopsystem oder CMS, etwa Shopware 6, Shopify oder PrestaShop. Die beiden letzten ließen sich vorher nicht speichern, weil es für sie kein Body-Class-Ruleset gibt.
• Eine selbst gesetzte Plattform ist manual und wird von späterer Erkennung nicht überschrieben. Das Objekt trägt key, source, detected_via und detected_at.
• Der Seitentyp aus den Body-Klassen ist ein eigener Schalter, page_type.body_class. Eine Plattform zu wählen schaltet ihn nicht ein, und pagetype_ruleset leitet sich aus beiden ab.
• shop.active sagt, ob eine Application ein Shop ist, dazu shop.source für die Herkunft. Ohne Einstellung folgt der Wert der Plattform.
• spa markiert eine Single-Page-App, wird von Hand gesetzt und ist aus. Noch liest keine Auswertung die beiden Felder.
• Die Response gruppiert ihre Felder: page_type, shop.checkout, collection, collector, script und site_defaults. Create und Update nehmen dieselben Gruppen als Teilobjekte.
• Die flachen Felder sind deprecated. Sie funktionieren weiter, ein API-Client sollte aber auf die Gruppen wechseln.
• Das Dashboard schickt beim Speichern nur noch, was du geändert hast.

Doku: Applications → Felder einer Application.

Eine Soft-Navigation hat keinen Dokument-Header, und Safari vor 16.4 gibt ihn nicht heraus. Diese Shopify-Pageviews hatten gar keinen Seitentyp, der Collector liest ihn jetzt aus der URL. Das Label ist Shopifys eigenes (product, collection, page, index, cart, search, blog, article), dasselbe, das ein harter Load meldet. Bereits gespeicherte Zeilen bleiben leer.

Doku: Server-Timing → Seitentyp.

Der Tracker schickt ein fetch_xhr_update für den ersten Fehler mit einem bestimmten Status auf einem Endpunkt. Wiederholungen erhöhen nur noch den Fehlerzähler, den das nächste Beacon ohnehin trägt. Ein gepollter Endpunkt, den ein Adblocker abweist, kostete bisher bis zu 20 Collector-Requests pro Pageview.

Nur Firefox' Formulierung wurde als syntax_unexpected_token erkannt, dasselbe kaputte Skript tauchte also einmal pro Engine auf. Chrome und Safari bekommen jetzt dieselbe Art und den lesbaren Satz dazu. Die betroffenen SyntaxError-Gruppen bekommen einen neuen Fingerprint und erscheinen einmalig als neu. Speichert eine Site keine Messages, kommt die Art aus dem Tracker, die alten Gruppen wachsen also weiter, bis die Browser das neue Bundle geladen haben.

Doku: Tracker → Was eine Message sagt.

Die Rate lag zwischen 30 % und 130 %. Sie teilte durch den Warenkorbschritt, den ein Drawer-Warenkorb, ein Express-Checkout oder ein Deep Link nie erzeugt.

• Die Conversion-Rate teilt Käufer durch alle Besucher. Das ist die Zahl, die GA4 und Shopify melden, messbar am üblichen Benchmark von 1 bis 3 %.
• visitors_total steht daneben, und jeder Punkt der Zeitreihe trägt eigene visitors. Die Bucket-Besucher addieren sich nicht zur Gesamtzahl.
• FunnelStep.conversion_rate heißt jetzt reach_rate. Dieselbe Zahl, ehrlicher Name: der Anteil am ersten Schritt, der über 100 % liegen kann.
• Eine Conversion-Rate pro Zeit-Bucket, gemessen am eigenen ersten Schritt des Buckets. Die Reihe hat einen Punkt für jeden Bucket mit Traffic, ein kaputter Tag liest sich also als 0 %.
• Neu POST /analytics/funnels/checkout/cohorts vergleicht Besucher mit beobachtetem Kauf gegen die, die den Checkout ohne Kauf erreicht haben. Pro Gruppe: Web Vitals über die ganze Journey und pro Stage, Warenkorb-Calls, ihre Dauer und ihre Fehler.
• checkout_no_success ist keine Zählung verlorener Käufe. Ein echter Käufer landet dort, sobald die Erfolgsseite für den Tracker unsichtbar ist.
• Vier weitere Zahlen: cart_interaction_rate (Benchmark 5 bis 6 %), cart_interaction_error_visitors, time_to_success_seconds (p50, p75, p90) und die Arten der Warenkorb-Interaktionen pro Punkt.
• Lies die ersten beiden als Untergrenze, überall dort, wo die Warenkorb-Calls des Shops für die fetch/XHR-Erfassung unsichtbar sind.
• Filter, die Funnel-Seiten auswählen, verengen den Nenner nicht mehr (checkout_stage, die Warenkorb-Schwellwerte). Zielgruppenfilter (Site, Land, Gerät, Kampagne) verengen beide Hälften.
• Läuft die Besucherzählung in einen Timeout, fehlen visitors_total und conversion_rate in der Response. Eine Rate, die nicht gemessen werden konnte, fehlt, statt 0 % zu sein.

Doku: Checkout-Funnel → Was die Zahlen bedeuten.

Jede Seite startet ohne Bot-Traffic, die Zahlen beschreiben also echte Besucher, solange du nichts anderes sagst.

• „Nur Bots" ist ein wählbarer Bereich, neben „Keine Bots" und „Alle", in der neuen Traffic-Auswahl des Filtermenüs. Beide zusammen sind dein gesamter Traffic und nichts doppelt.
• Der gewählte Bereich steht im Seitenkopf neben dem Zeitraum: ein durchgestrichener Bot, ein Bot oder „inkl. Bots" in Worten.
• Er zählt nicht als Filter und überlebt „Alle entfernen". Panels, in denen es um Bots geht, zeigen sie so oder so.
• Jeder Teil der Filter-Pille öffnet das Filterpanel, auch Perzentil, Gerät und Bot-Markierung.

• Beim Maximieren verschwindet auch die Sidebar. Über der Tabelle bleibt nur die Kopfzeile mit Logo, Filtern und Account-Menü.
• Maximiert ist ein Lesemodus, keine Einstellung. Er gilt, solange du auf der Seite bist.
• Ab 1536 px wandern Query-Panel und Tabellen-Toolbar in die Kopfzeile. Schmaler bleiben sie in der Seite.
• Kopieren, CSV und Maximieren teilen sich die Zeile mit der Ergebnisangabe, statt eine eigene zu belegen.
• Die Pageview-Liste sagt unten, wie viele Zeilen getroffen haben, neben Seitengröße und Blätterung.

Das Menü kannte die Gruppen der Sidebar und nicht die Seiten darin, die Suche nach „fetch" fand also nichts.

• Jede Seite ist mit ihrer Gruppe gelistet. Tippst du eine Gruppe („Netzwerk"), erscheint alles darunter.
• Wochenüberblick, fastmon AI, Partner und dein Account sind im Menü, jeweils unter derselben Bedingung wie in der Sidebar.
• Seiten werden auch unter ihrem anderen Namen gefunden. „API" findet Fetch/XHR, „Largest Contentful Paint" findet LCP.
• Öffnest du eine Organisation, stehen ihre Applications oben, über den Domains. Eine davon zu wählen, setzt den Scope der Seite, auf der du bist.

Doku: Analytics → Navigation über die Befehlspalette.

Ein stündlicher Zeitraum schaltete das Chart von selbst auf Balken um, dieselbe Seite änderte also ihre Form, wenn du den Zeitraum gewechselt hast. Das Balkendiagramm gibt es weiter, es muss nur gewählt werden.

Gebaut für die Rejection ohne Message und ohne Stack: Der Fehler sagt nichts, der fehlgeschlagene Request sagt URL, Methode und Status.

• POST /analytics/error-types/correlated-requests fragt für eine Fehlersignatur, welche fetch/XHR-Endpunkte in denselben Pageviews scheitern.
• Zu jedem Endpunkt steht die Fehlerquote in Pageviews ohne diesen Fehler. Sortiert wird nach dem Verhältnis der beiden.
• Die Antwort sagt, dass etwas gemeinsam auftritt, nie dass eines das andere verursacht.
• Welche Fehlschläge zählen, richtet sich nach der Message. Ein Fehler über eine leere Antwort passt zu abgebrochenen Calls, einer über ungültiges JSON zu 4xx- und 5xx-Seiten.
• Applications ohne fetch/XHR-Erfassung bleiben außen vor, statt die Antwort zu leeren, und fetch_xhr_collected: false sagt das.
• Gelesen werden rohe Pageviews, die Antwort reicht also so weit zurück wie diese, nicht so weit wie die Rollups.

Doku: Analytics → Was kaputt ist, und wo.

Eine Seite mit mehr als 24 API-Endpunkten behält 24 davon benannt statt 23.

• Die Überlaufzeile des Trackers belegt keinen Platz mehr. Sie summiert Dutzende Calls und gewann deshalb immer um den letzten Platz.
• Fehler eines verdrängten Drittanbieter-Endpunkts zählen wieder zu Dritten. Bisher liefen sie als eigene.
• Von Adblockern geblockte Calls in der namenlosen other-Zeile zählen nicht mehr als Fehler. Volle Seiten mit geblockten Tracker-Calls melden eine etwas niedrigere fetch/XHR-Fehlerrate.
• Vor dem Deploy erfasste Pageviews behalten die Form, in der sie erfasst wurden.

• Ein entferntes Literal behält seine Anführungszeichen. Ein Beispiel liest sich als '*' is not a valid selector, eine entfernte E-Mail als <email>, Zahlen behalten das nackte *.
• Eine URL in einer Message überlebt als Origin plus Pfad. Query, Fragment und numerische Pfad-IDs werden weiter entfernt.
• Safaris Selektorfehler tragen wieder ihre Form. WebKits 'x' is not a valid selector kam unklassifiziert an, derselbe Fehler gruppierte also pro Engine getrennt.
• Neue Vorkommen klassifizieren als selector_invalid, nennen den Selektor in message_value und teilen sich einen Fingerprint über die Engines hinweg.
• Fehlergruppen auf Basis des Message-Texts starten einmalig neu. Fehler mit erkannter Form behalten ihren Fingerprint, unklassifizierte gruppieren mit dem Tracker-Rollout neu.

Doku: Tracker → Was eine Message sagt.

Ein Besucher in einer Rekursionsschleife meldete Hunderttausende Fehler.

• Der Tracker hört bei 1000 pro Kanal auf zu zählen, Fehler und fehlgeschlagene Ressourcen getrennt. Der Collector kappt Beacons älterer Builds auf dieselbe Grenze.
• Ein gespeicherter Zähler von genau 1000 heißt „1000 oder mehr", und das Dashboard schreibt „mindestens".
• Eine Aufschlüsselung übersteigt nie die Zahl, die sie aufschlüsselt. Meldet ein Beacon mehr Vorkommen als die Grenze, werden seine Signaturen in die gespeicherte Summe skaliert.
• Jenseits der Grenze erfasst der Tracker keine neue Signatur mehr auf diesem Pageview. Ein Fehler, der nach 1000 anderen zum ersten Mal auftritt, kann in der Liste fehlen.
• Ein Fehler, den der Tracker nicht erfassen konnte, bläht den Zähler nicht mehr auf. Ein widerrufener Proxy oder ein werfendes toString erhöhte den Zähler und verlor seinen Eintrag; jetzt landet so etwas als „Other".

Doku: Tracker → Was als Fehler zählt.

• Alle Befunde der Woche stehen oben in einer Liste, gruppiert nach App, jede Zeile führt zum Chart dahinter. Die App-Blöcke darunter tragen die Zahlen der Woche.
• Eine Woche ohne Veränderung ist keine gute Woche mehr. Eine Metrik, die zwei Wochen in Folge schlecht ist, steht im Eingangssatz.
• Fehler sind zurück, auf der Seite und in der Mail. Die Fehlerrate ist die letzte Spalte der Tabelle, und ein neuer oder gestiegener Fehler wird zum Befund.
• Jeder Befund sagt, was ein Besucher merkt. Layoutverschiebungen heißen, dass Klicks danebengehen; eine träge Reaktion heißt, dass nach dem Klick nichts passiert.
• Die Woche wählst du in der Kopfleiste, wo jede andere Seite ihren Zeitraum hat.
• Jede Überschrift ist die der Mail, und die Statusfarben folgen jetzt den beiden Farbenblind-Themes.

Einen Fehler zu öffnen klappte bisher eine Zeile in einer Tabelle in einer Karte auf, mit Stack, Aufschlüsselungen und Beispielen in einer Tabellenzelle.

• Eine Signatur liegt unter /org/<org>/errors/<fingerprint>, das ist zugleich ihr Share-Link. Bestehende ?error=-Links leiten dorthin weiter.
• Die Liste beginnt mit dem, was kaputt ist, als Satz: was passiert ist, wessen Code es ist, die Datei, wie oft und wann zuletzt.
• Neue und steigende Fehler sind ohne Klick sichtbar. Jede Zeile trägt eine Sparkline und ein Abzeichen, sortiert wird nach häufigste, neu, steigend oder zuletzt gesehen.
• Die Liste sortiert nach erreichten Pageviews, nicht nach Häufigkeit. Eine Zeile, deren Vorkommen aus wenigen Besuchen stammen, ist als Schleife markiert.
• „Wo es auftritt" ist das Aufschlüsselungsraster der Metrikseiten, Bots und Netzwerk inklusive. Dieselben Filter-, Ausschluss- und Explorer-Aktionen wie überall.
• Ein Fehler ohne Inhalt sagt, warum: Messages oder Frames abgeschaltet, ein Drittanbieter-Skript ohne CORS-Opt-in, oder es kam schlicht nichts an. Chart und Aufschlüsselung funktionieren trotzdem.
• „AI-Prompt" übergibt den ganzen Fall an einen Assistenten. Er schreibt dazu, was deine Site nicht erfasst, und nichts wird geladen, bevor du ihn öffnest.
• JavaScript-Fehler und fehlgeschlagene Ressourcen sind zwei Tabs, jeder mit eigener Überschrift, eigenem Chart und eigener Liste.
• Wessen Code es ist, steht als Überschrift, der Breadcrumb nennt den Fehler statt seines Hashes, und eine aufgeklappte Zeile schreibt ihren Anker in die URL.

Doku: Analytics → Error Analytics.

• Alle Dimensionen sind gleichzeitig sichtbar, je eine Karte, mit einem Share-Link, der genau diese Karte wieder öffnet. Eine Dimension, für die deine Site nichts schickt, blendet ihre Karte aus.
• Eine Domain-Karte sagt, zu welcher deiner Domains eine langsame Seite oder ein Fehler gehört.
• Eine Karte mit Zählwerten sortiert nach ihrer Zählung. Die Reihenfolge heißt „Meiste" und „Wenigste" statt „Schlechteste" und „Beste".
• Eine Regel für Farbe. Jeder Balken ist grau und sagt wie viel; die Zahl daneben trägt die Farbe und sagt wie gut oder schlecht.
• Jede Liste sagt, wie viel der Antwort sie zeigt, und führt in den Explorer, mit den Filtern der Seite.
• Öffnest du eine Zeile, bleiben deine Filter erhalten, statt aus der Zeile allein neu gebaut zu werden.
• Fehler-Aufschlüsselungen zählen wieder Fehler. Zählwerte werden summiert und Raten gemittelt, egal welches Perzentil die Seite eingestellt hat.
• Länder haben auch in den Metrik-Panels Flaggen und Browser ihre Zeichen.

• Das Snippet ist in Zeilen umbrochen und eingerückt. Es bricht an Statements und Blöcken um und hält Schließer zusammen (}), };, eine Folge }}}).
• Neu formatiert wird nichts. Der Umbruch setzt Whitespace zwischen Tokens und ändert kein Zeichen, die gemeldete Spalte zeigt also weiter auf ihren Code.
• Die Zeile mit dem Fehler ist markiert, mit Tönung und einer Linie am linken Rand. Das Snippet bricht um, statt seitwärts zu scrollen.
• Snippets sind von 160 auf 300 Bytes je Seite der Fehlerspalte gewachsen. Zwischengespeicherte Auflösungen werden einmalig neu geholt.
• Der AI-Prompt markiert die Spalte im Code selbst, als /*<<COLUMN>>*/, und benennt sie in Worten darüber.
• Die Error-Detail-Response trägt ihre Diagnose selbst: error_type, message_kind, message_value, sample_message und messages_collected.

DB, KV, Search, HTTP und Render endeten alle beim ersten Byte, zwei gleich lange Phasen lagen also auf demselben Abschnitt der Zeitleiste und lasen sich wie parallele Arbeit. Sie sitzen jetzt im Backend-Balken, eine nach der anderen, in der Reihenfolge, in der ein Request üblicherweise läuft. Backend-Zeit, die keine Phase erklärt, wird als „Sonstige App-Zeit" gezeichnet, und der Key-Value-Tier heißt überall „KV".

Das deutsche Dashboard schrieb „20.0 %" und „1.49 %" mit Punkt, neben Zahlen mit Komma. Jede Prozentangabe läuft jetzt durch einen Formatter, ebenso die gekürzten Zahlen in den Aufschlüsselungs-Panels.

Auf dem Handy kürzt sich ein langer Breadcrumb, statt die Seite zu verbreitern, und die Aktionen eines Fehlers bekommen eine eigene Zeile. Die Bedienelemente einer Karte haben eine eigene Trennlinie, und Tab-Leisten scrollen, statt umzubrechen.

• Neue Einstellung template_url_ids pro Application, standardmäßig aus. Mit ihr wird /order/12345 als /order/:id gespeichert und ausgewertet.
• Es ist die Regel, nach der die fetch/XHR-Pfade längst laufen: numerische, UUID-, lange Hex- und opake Token-Segmente, dazu eine ID in einem sonst festen Segment. Lange Produkt-Slugs bleiben wörtlich.
• Sie greift beim Ingest und nur für neue Zeilen. Ein Bericht über den Umschaltzeitpunkt hinweg zeigt eine Weile beide Formen.
• Wieder ausschalten holt die rohen URLs nicht zurück.
• Checkout-Funnel-Matching und der Error-Frame-Strip sehen weiterhin den echten Pfad.

Doku: Tracker → template_url_ids.

LCP-Perzentile überspringen Pageviews ohne Wert, eine Länder- oder Browserzeile kann also auf einer Handvoll Messungen stehen. lcp_coverage ist der Anteil der Pageviews mit gemeldetem LCP, 0 bis 1: das n neben dem p75. Verfügbar in der Dashboard-API, im MCP-Server und in Ask.

Der Tracker liest navigator.webdriver, das ein automatisiert gesteuerter Browser selbst setzt. Der Collector speichert es als ua_anomaly = webdriver, und bot_class ordnet es unter bot ein. Der Bots-ausblenden-Schalter entfernt damit Puppeteer-, Playwright- und Selenium-Sessions ohne Stealth-Schicht.

Die meisten Sites sammeln keine Fehlermeldungen, die meisten Fehler lesen sich also als Typ plus Stack und sonst nichts. Der Tracker erkennt die Formulierung des Browsers jetzt gegen einen festen Katalog und schickt ihre Form statt des Texts.

• Die Form reist in jeder Konfiguration mit, auch in Minimal: eine Art aus einer geschlossenen Liste, dazu der Name, auf den diese Art zeigt. Eine leere JSON-Antwort, ein Request, der mit HTML statt JSON beantwortet wurde, eine Variable, die es nicht gibt, ein Selektor, den der Browser abgelehnt hat. Ein Fehler ist damit lesbar, wo vorher nur ein Stack stand.
• Derselbe Fehler auf Chrome und auf Safari ist jetzt eine Signatur. Die beiden Engines formulieren ihn unterschiedlich, und die Gruppierung folgte bisher der Formulierung.
• Eine Site, die keine Messages sammelt, schickt auch keine mehr. collect_error_messages ist ins ausgelieferte Bundle eingebacken, die Message wird also gar nicht erst zusammengebaut. Bisher verließ sie den Browser und wurde beim Empfang verworfen.
• Die Signaturen werden einmalig neu gruppiert. Alte Gruppen behalten ihren Key und wachsen nicht weiter, derselbe Fehler taucht ab dem Deploy unter einem neuen Key auf, und die Vorkommen davor und danach lassen sich nicht addieren. Kein Backfill: Die Messages, die die neue Gruppierung liest, wurden nie gespeichert.

Doku: Tracker → Was eine Message sagt.

Eine Fehlerzeile begann mit der Datei, in der geworfen wurde, und las sich damit wie „die URL, auf der das passiert ist". Und ein minifizierter Frame wie bundle.6a2ce3.js:1:6800 sagte überhaupt nichts.

• Die Zeile ist die Message, oder der Satz aus ihrer Form, wo es keine gibt, mit Typ, Zugehörigkeit und Wurfstelle darunter. Der ganze Stack steht ebenfalls in der Zeile: die Wurfstelle in voller Stärke, die Aufrufer darunter blasser.
• „Stack auflösen" liest die Datei, die deine Besucher tatsächlich ausgeführt haben. Jeder Frame kommt mit der Methode zurück, in der er steht, dem umgebenden Modul und dem Code an dieser Spalte, syntaxgefärbt und zum fehlerhaften Aufruf gescrollt. Ohne Source-Map und ohne Setup auf deiner Seite, denn ein Minifier behält Klassen- und Methodennamen. Mehrere aufeinanderfolgende Frames aus demselben Vendor-Bundle klappen zu einer Zeile zusammen, die die Library nennt, ein Frame, der den Fehler nur weiterreicht, ist als Rethrow markiert, und ein Frame, der sich nicht lesen lässt, sagt warum. Es ist ein Button und nichts, was eine Zeile von selbst tut, denn dabei wird dein Bundle abgerufen. Der Endpunkt ist POST /analytics/error-types/symbolicate.
• Ein neues Chart sagt, welcher Fehler gestiegen ist. „Welche Fehler, über Zeit" stapelt die fünf größten Signaturen je Bucket, benannt nach ihrer Message statt nach ihrem Hash. Ein Klick auf einen Namen in der Legende öffnet diese Signatur darunter.
• Eine Fehlersignatur ist ein Filter wie jeder andere. LCP, Browser, Länder oder der Funnel lassen sich also über den Traffic lesen, auf dem eine Sache kaputt ist.
• Eine aufgeklappte Signatur zeigt alles, was wir haben: Vorkommen, betroffene Besucher, erstes und letztes Auftreten, ihren Verlauf, die Seiten, Browser, Länder, Geräte und Betriebssysteme, auf denen sie auftritt, und die letzten Pageviews, die sie getragen haben. Die offene Zeile steht in der Adresszeile.
• Seiten sind danach sortiert, wie viele Fehler sie geworfen haben, nicht nach ihrer Fehlerrate. Eine Seite mit einem Pageview, der einmal geworfen hat, hat eine Rate von 100 % und ist nicht der kaputte Checkout.
• Dasselbe Panel steckt in der Zeilen-Detailansicht des Explorers, und eine Script error.-Zeile sagt jetzt, warum sie leer ist.

Doku: Analytics → Was kaputt ist, und wo.

Die eingebauten Rulesets matchen die Klassen, die ein Shop-System ausliefert, und ein eigenes Theme darf sie umbenennen. Ein OXID-Theme mit c-body--details statt des erwarteten cl-details erfasste gar keinen Page-Type, und nichts sagte das.

• pagetype_rules bildet exakte Klassennamen auf Page-Types ab (home, product, category, cart, checkout, search, account), in der Page-Type-Einstellung und über POST/PATCH /applications. Die Regeln stehen vor der Ruleset, statt sie zu ersetzen. Du reparierst also den einen Page-Type, den dein Theme umbenannt hat, und die anderen sechs kommen weiter aus der Ruleset. Regeln ohne Ruleset sind ein eigener Modus: Ein Shop-System oder CMS, für das wir keine Ruleset haben, bekommt einen Page-Type, sobald du seine Klassen benennst.
• Klassennamen sind exakt, nie Muster. Der Vergleich läuft im Browser jedes Besuchers, und ein Muster wäre dort ein Risiko auf deiner eigenen Seite. Höchstens 24 Regeln, höchstens 32 Zeichen pro Klasse, und Groß- und Kleinschreibung spielt keine Rolle, anders als bei den eingebauten Rulesets.
• Detect nennt dein Shop-System, Detection einzuschalten fängt also nicht mehr damit an, die eigene Body-Klasse in den DevTools zu lesen. Es liest die Startseite der ältesten Domain der Applikation und sagt, was es gefunden hat, mit den Belegen dafür und dem Page-Type, den es erfasst hätte. Shopify und PrestaShop werden erkannt und als nicht wählbar markiert: Shopify meldet seinen Page-Type stattdessen über Server-Timing, PrestaShop hat noch keine Ruleset.
• Discover findet die Klassennamen. Benenne eine Beispielseite je Page-Type, deine Startseite wird als Kontrast mitgelesen, und daraus lässt sich die Klasse vorschlagen, die nur dieser Page-Type trägt. Zwei Beispiele desselben Typs geben die sicherste Antwort, denn was sich zwischen ihnen unterscheidet, kann nicht das Merkmal sein. Ein Typ mit genau einem Kandidaten kommt fertig zum Speichern zurück.
• Keiner der beiden Probes schreibt etwas, beide lesen nur die eigenen Domains der Applikation, und beide sind auf zehn Läufe pro Organisation und Stunde begrenzt.
• Der Read bleibt, was er war: ein Token pro Pageview, nur wo du die Klasse benannt hast oder eine Ruleset sie kennt, und nie das volle class-Attribut. OXID-Shops melden außerdem die Bestellabschluss-Seite (cl-thankyou) jetzt als checkout.

Doku: Tracker → pagetype_rules.

Eine Query, die nach Zeit und nach einer Dimension gruppiert, verlor bisher das Ende ihrer Achse, weil das Zeilenlimit das Ergebnis abschnitt, bevor das Fenster abgedeckt war. Sechs Stunden im Minutentakt über zwanzig Fehlersignaturen zeichneten die ersten zwei Stunden und sahen vollständig aus.

• group_by.top_n begrenzt, wie viele Dimensionswerte eine Query liest, sortiert nach Pageview-Volumen über das angefragte Fenster. Setz es bei jeder Query, die nach Zeit und nach einer Dimension gruppiert, dann konkurriert das Zeilenlimit nicht mehr mit der Zeitachse.
• Gruppieren von /analytics/query nach einer errors.*-Dimension funktioniert wieder. Die Zeilenzahl, die das Ergebnis paginiert, fragte ClickHouse nach einer Spalte, die die Query nicht selektiert hatte, jede solche Query schlug also fehl, statt Daten zu liefern.
• Eine gruppierte Query meldet den Wert, nach dem sie gruppiert hat. Beide strukturierten Dimensionen wurden unter dem falschen Namen gelesen: errors.* kam leer zurück, und eine Map-Dimension wie third_parties ließ den Request scheitern.

Doku: API → Analytics (nur auf Englisch).

Die Karte der aktiven Stunden war so breit wie die Woche, die sie zeichnet, auf dem Handy schob sie damit die Stundenachse und den Schalter Pageviews / Besucher aus dem Viewport, ohne dass sich etwas scrollen ließ. Das Raster scrollt jetzt innerhalb der Karte. Ein Tipp auf das Info-Icon einer KPI-Kachel wechselt nicht mehr die Metrik des Charts, und die Fehlerliste behält Anzahl und Anteil auf einem 390 px breiten Screen, statt sie abzuschneiden.

Wer die App-Wurzel angemeldet öffnete, wurde auf die Login-Seite geworfen. / stand noch auf der Liste der öffentlichen Marketing-Seiten, aus der Zeit, als dort die Landingpage lag, die Session wurde also nie geprüft, bevor der Route-Guard lief, und nur ein Reload brachte einen ins Dashboard.

Jedes Fenster, das im Minutentakt bucketet, also 15 Minuten bis 6 Stunden, zeichnete an jedem Tick dasselbe Datum und gar keine Uhrzeit. Das Chart nutzt jetzt das gemeinsame Tick-Raster der App: Schritte, an lokaler Mitternacht ausgerichtet, und das Datum auf dem Tick, der auf Mitternacht fällt.

Die Liste der fehlgeschlagenen Ressourcen konnte Hosts und Pfade sortieren und sonst nichts, und ein Tracker, den jeder Ad-Blocker killt, besetzte die oberen Zeilen.

• Die Liste gruppiert nach Host, jeder mit seinem Anteil an allen fehlgeschlagenen Ladevorgängen, und ein geöffneter Host zeigt die einzelnen Ressourcen darunter. Eine zweite Ansicht sortiert Seiten nach dem Anteil ihrer Pageviews, die eine Ressource verloren haben.
• Einen Host auszublenden macht die Liste lesbar. host und exclude_hosts grenzen auch die Summen ein, anders als bucket, die Anteilsbalken und die große Zahl bleiben also mit den Zeilen konsistent.
• Eine geöffnete Ressource lässt sich aufschlüsseln wie eine geöffnete Fehlersignatur: die Datei, eine Zeitreihe, Breakdowns nach Seite, Browser, Gerät, Betriebssystem und Land, betroffene Besucher und Beispiel-Beacons. POST /analytics/failed-resources/detail, mit dem fingerprint, den jede Zeile jetzt trägt.
• Die Beacon-Detailansicht hält die zwei Populationen auseinander. errors trägt JavaScript-Fehler, failed_resource_loads die fehlgeschlagenen Ladevorgänge mit Host, Pfad und Eigentümer, und failed_resources ist eine Spalte, die du projizieren und mit >= 1 eingrenzen kannst. error_fingerprint nimmt ein error_fingerprint_kind (error oder failed_resource), denn beide Listen vergeben Keys aus einem Raum.
• Der Assistent und der MCP-Server haben get_failed_resource_detail bekommen, das Gegenstück zu get_error_detail für die andere Population.

Doku: Analytics → Fehlgeschlagene Ressourcen.

Nachrichten, die fastmon-Mitarbeiter schreiben, erscheinen jetzt als Streifen oben im Dashboard, an derselben Stelle und in derselben Form wie der Abrechnungsstreifen „Aktion erforderlich". Die beiden lesen sich damit als ein System.

• Ein Hinweis richtet sich an alle oder an eine Organisation, liest sich als Info, Warnung oder kritisch, und erscheint nur, solange er veröffentlicht ist und in seinem Zeitfenster liegt. Die Hinweise einer Organisation sieht jeder, der sie öffnen darf, auch Agenturmitarbeiter, die über eine Partnerschaft daran arbeiten.
• Ein Titel allein ist ein vollständiger Hinweis. Die Beschreibung ist optional, und Zeilenumbrüche darin bleiben so, wie sie getippt wurden.
• Ein weggeklickter Hinweis bleibt pro Person auf dem Server gespeichert, er bleibt also auf jedem Gerät und in jedem Browser weg.
• Mehrere gleichzeitig blättern einzeln durch, mit Pfeil und Zähler („2/3") statt zu stapeln. Der schwerwiegendste steht vorn, und nichts bewegt sich von allein.
• Deutsch, wo es geschrieben wurde. Ein Hinweis kann einen deutschen Titel und eine deutsche Beschreibung tragen; wer Deutsch als Kontosprache hat, liest diese Fassung, alle anderen den Basistext.

Überall, wo das Dashboard danach trennt, auf wessen Host etwas lag, schreibt es das Wort aus. Deutsch heißt das „Eigene" und „Dritte", Englisch „First-party" und „Third-party". Das betrifft das Fetch/XHR-Panel, die Fehlerliste, die Balken der Fehler-Herkunft, den Block der fehlgeschlagenen Ressourcen, die Dimension Fehler-Herkunft im Explorer und die Lighthouse-Ressourcentabelle.

• Wo eine Zeile für ein Wort zu eng ist, wird nur die Dritt-Seite markiert, und eine unmarkierte Zeile ist deine eigene. Der Fetch/XHR-Wasserfall und die Skriptlisten auf den INP- und TBT-Seiten lesen sich dadurch deutlich ruhiger.
• Aufrufe auf denselben Origin erscheinen im Fetch/XHR-Panel nicht mehr als „1P" vor einem Pfad. Ein Pfad ohne Host ist deine eigene Domain, so wie eine URL sich liest.
• Unverändert: „First-Party-Proxy" und das Party-Badge des Collectors im Setup. Dort benennt das Wort einen Konfigurationsmodus und nicht, wem ein Host gehört.

Er gruppierte nach dem ausliefernden Knoten aus dem optionalen Server-Timing-Key fm-host, auf jeder Site, die diesen Header nicht sendet, war der Tab also eine einzige Zeile „(nicht gemeldet)". Er listet jetzt die Domains aus den Seiten-URLs und heißt Domains. Der ausliefernde Knoten steht weiterhin im Explorer und auf der Backend-Zeit-Seite, wo er eine Performance-Frage beantwortet.

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.