fastmon Docs

Analytics

Traffic, Besucher, Fehler und der Experience Score. Die Felddaten-Dashboards über deinen Beacons.

Analytics ist die Erkundungsebene über allem, was dein Tracker sammelt: Wer ist gerade auf der Site, woher kommt der Traffic, welche Seiten werden aufgerufen, welche Fehler treten auf, und wie verlaufen ganze Besuche.

Das Dashboard

Die Analytics-Hauptansicht einer Site zeigt:

  • Aktuelle Besucher: eindeutige Besucher der letzten 5 Minuten, aufklappbar zu einem Pro-Minute-Chart der letzten Viertelstunde plus den Seiten, die gerade angesehen werden, und den Quellen, über die die Besucher kommen. Bei Shops zeigt die Karte zusätzlich, wie viele davon gerade im Warenkorb, im Checkout oder auf der Abschlussseite sind.
  • Zentrale Kennzahlen: Besucher, Pageviews, Pageviews pro Besucher und bei einem Shop Bestellungen und Conversion, jeweils mit Sparkline und Veränderung zur Vorperiode. Die Vorperiode sind dieselben Wochentage und Uhrzeiten, so wenige ganze Wochen früher, wie das Fenster braucht. Die Zähl-Kacheln zeigen außerdem einen Durchschnitt pro Minute über den gewählten Zeitraum. Ein Klick auf die Kachel erklärt, was sie zählt.
  • Trend-Chart: die gewählte Kennzahl über den Zeitraum, optional mit Vorperioden-Overlay. Die Auswahl steht in der URL (?metric=), ein geteilter Link öffnet also dieselbe Kennzahl. Die Legende steht darüber, zusammen mit dem Umschalter für Balken und Fläche, und jede Serie lässt sich einzeln abschalten und trägt ihren eigenen Vorperioden-Wert.
  • Breakdowns: vier Panels für Quellen, Seiten, Standorte und Geräte, jedes mit Unter-Tabs zum Reinzoomen (Channel vs. UTM-Quelle, Länderlisten, Browser vs. Betriebssystem und so weiter). Der dritte Tab des Seiten-Panels listet die Domains aus den Seiten-URLs. Jedes Panel erklärt am Titel, was es zählt, nennt in der Fußzeile, wie viele Werte hinter den acht angezeigten Zeilen stecken, und führt über „Alle anzeigen" in den Explorer. Einzelne Zeilen öffnen sich dort ebenfalls direkt.
  • Geografische Verteilung: Globus, flache Karte oder Länderliste. Der Globus öffnet dort, wo dein Traffic ist, Ziehen dreht ihn und das Mausrad zoomt. Die gewählte Ansicht steht in der URL, und ein Klick auf ein Land bietet seine Filter an.
  • Aufschlüsselungs-Raster: auf der eigenen Seite einer Metrik ist jede Dimension eine Karte, alle gleichzeitig sichtbar, jede mit einem Share-Link, der genau diese Karte wieder öffnet. Jeder Balken ist grau und sagt wie viel, die Zahl daneben trägt die Farbe, und jede Liste sagt, wie viel der Antwort sie zeigt, bevor sie mit den Filtern der Seite in den Explorer führt.
  • Checkout-Funnel: eine Leiste je Stufe an gemeinsamer Kante, dazu der Anteil an der Stufe davor, damit sichtbar wird, wo Leute abbrechen. Darunter die Warenkorb-Requests nach Art. Siehe Checkout-Funnel.
  • Bots im Zeitverlauf: „Bots“ neben dem Chart-Typ teilt das Pageview-Chart in Menschen und Bots, einzelne Bots oder Bot-Typen. Der Bot-Filter oben zieht mit und springt zurück, wenn du die Ansicht wieder ausschaltest. Ein Cmd- oder Strg-Klick auf einen Legendeneintrag zeigt nur diesen.
  • Traffic-Qualität: Pageviews gestapelt nach Menschen, Wahrscheinlich Bots und Bots, die Besucher als Linie darüber. Darunter die Bot-Klassifizierung als eine Leiste, dann als klickbare Zeilen.
  • Aktive Stunden: Stunde des Tages nach Wochentag, damit sichtbar wird, wann auf der Seite wirklich etwas passiert. Das Raster zeigt nur die Wochentage, die der gewählte Zeitraum erreicht hat.
  • Engagement: Anteil der Besucher mit nur einer Seite, darunter die Verteilung der Seiten pro Besucher mit Median. Keine Bounce-Rate: ob jemand danach gegangen ist, steht nicht in den Daten.

Besucherzahlen sind anonym per Konstruktion; was ein „Besucher" hier bedeuten kann und was nicht, steht unter Privacy.

Shopfloor

Der Shopfloor unter Analytics (/shopfloor) zeigt deinen Shop live von oben.

  • Die Zonen sind die Seitentyp-Gruppen deiner Plattform: Home, Kategorie (PLP), Suche, Produkt (PDP), Checkout, Konto, Content und Sonstiges. Ihre Färbung zeigt, wie schnell ihre Seiten sind.
  • Jeder Besucher ist ein Punkt in der Zone der Seite, auf der er gerade ist. Ein Tab im Hintergrund wird blass gezeichnet. Ein Käufer läuft zum Ausgang, und dort zählt die Bestellung sofort.
  • Das Zeitfenster ist 5, 15, 30 oder 60 Minuten. Unter der Hauptzahl stehen Besucher, Bestellungen und Conversion Rate von heute ab deiner Mitternacht, jeweils neben dem gleichen Wochentag der Vorwoche. Bestellungen zählen bis zur Sekunde und sagen das („Stand 14:32“), die Vorwoche läuft bis zur gleichen Uhrzeit.
  • Ein Klick auf eine Zone zoomt hinein: ihre Seitentypen und ihre Top 10 URLs der letzten 30 Minuten mit Pageviews und LCP.
  • Für einen Wandbildschirm setzt ?window=60&sound=1&kiosk=1 Zeitfenster, Kassenklingeln pro Bestellung und Kiosk-Modus. Ton ist per Default aus.
  • Filtern kannst du nach Land, Gerät, Seitentyp und Traffic. Ein Filter von einer anderen Seite bleibt als blasser Chip mit dem Hinweis, dass er hier nicht greift.
  • Er braucht store_stitch. Eine Site ohne zeigt niemanden und sagt das auch.

Die API dazu: POST /analytics/live und POST /analytics/live-summary.

Zeitraum

Die Zeitraum-Pille im Header legt das Fenster für alle Charts der Seite fest.

  • Zoom: Minus verdoppelt das Fenster, Plus halbiert es, auch mit den Tasten - und +. Ein Live-Fenster bleibt mit seinem Ende bei jetzt.
  • Zieh über ein Trend-Chart, um in diesen Abschnitt zu zoomen. Die Charts laden in der Auflösung neu, die dazu passt.
  • Zu jetzt springen: Liegt das Fenster in der Vergangenheit, schiebt ein Button es bei gleicher Länge in die Gegenwart.
  • Auflösung ist eine Reihe Kacheln, jede mit der Zahl der Intervalle, die sie ergibt. „Minütlich" kürzt ein Fenster über 6 Stunden auf seine letzten 6 Stunden.
  • Datum und Uhrzeit sind eigene Felder und greifen sofort. Das Ausdrucksfeld nimmt auch eine Uhrzeitspanne wie 14:00-16:30.
  • Die Zeitleiste oben im Picker zeigt das Fenster auf den Tagen drumherum. Zieh es, zieh an einer Kante oder scroll zum Zoomen.

Filtern

Neben dem Zeitraum-Picker sitzt eine Filterleiste, auf dem Dashboard, der Übersicht und jeder Metrik-Detailseite. Tipp eine Dimension und einen Wert (zum Beispiel country = DE) und drück Enter, um einen Filter-Chip hinzuzufügen; das Wertefeld vervollständigt mit den echten Werten des aktuellen Zeitraums und zeigt, wie viele Pageviews je Wert anfallen. Die Dimensionsauswahl listet die meistgenutzten zuerst (Seite, Land, Gerät), dann den Rest: Browser, Betriebssystem, Verbindung, Viewport, Referrer-Quelle und -Medium, UTM-Felder, Click-ID-Label, Domain, Navigationstyp, Protokoll und die Checkout-Stufe (Warenkorb, Checkout, Bestellt).

Filter leben in der URL, überstehen also ein Neuladen, sind teilbar und wandern beim Wechsel zwischen Views mit. Mehrere Chips werden mit UND verknüpft; ein Komma in einem Wert bedeutet „eines von". Klick einen Chip zum Bearbeiten, das X entfernt ihn. Der „Filter"-Button trägt ein Badge mit der Anzahl aktiver Filter.

Jede Seite startet ohne Bot-Traffic, die Zahlen beschreiben also echte Besucher, solange du nichts anderes sagst. Die Traffic-Auswahl im Filtermenü wechselt zwischen Keine Bots, Nur Bots und Alle, und der Seitenkopf sagt neben dem Zeitraum, was gerade gilt. Der gewählte Bereich zählt nicht als Filter und überlebt „Alle entfernen".

Jeder Chip hat außerdem einen Ein/Aus-Schalter. Ausgeschaltet behält der Chip seine Werte und bleibt an seinem Platz, durchgestrichen dargestellt, und die Abfrage läuft ohne ihn. Ein ausgeschalteter Filter grenzt nichts ein und zählt nicht im Badge, und ein Klick auf dasselbe Land in der Karte schaltet ihn wieder ein, statt einen zweiten anzulegen. Auch dieser Zustand steht in der URL, ein geteilter Link öffnet also mit denselben ein- und ausgeschalteten Filtern.

Der Explorer

Der Explorer gruppiert Pageviews nach jeder Dimension und chartet die Metriken, oder zeigt die Rohzeilen. Maximieren gibt ihm das ganze Fenster samt Sidebar. „Alle anzeigen" und die Zeilen-Links aus den Dashboard-Panels tragen die Filter der Seite mit hinein, samt Ausschlüssen, Metrik-Bereichen und Bot-Schaltern, und er öffnet mit den Zahlen, um die es auf der Seite geht (Pageviews und Besucher, bei Seiten zusätzlich LCP p75). Ein Klick auf eine Gruppe öffnet ihre Pageviews direkt, und die Leiste darüber springt zur nächsten Gruppe oder zurück zu allen.

Die Beacon-Zeilen zeigen den HTTP-Status der Seite, und HTTP-Status >= 400 im Filter listet die Pageviews von Fehlerseiten. Firefox, Safari und Soft Navigations melden keinen Status, ihre Zeilen zeigen deshalb einen Strich und treffen keinen Filter. Gruppiert nach HTTP-Status bilden sie die Gruppe „Nicht gemeldet". Die Gruppierungsauswahl hat ein Suchfeld.

Neben der Tabelle sitzt eine Events-Seite, eine Zeile pro Checkout-Event, filterbar nach Typ und mit einem Sprung zum Besucher der Zeile. Eine Spalte zeigt, ob die Zeile aus einem Pageview oder vom Shopify-Pixel stammt.

Ein Pageview öffnet sich in einer Detailansicht mit festen Plätzen. Oben stehen acht Eckdaten und sechs Vitals-Kacheln, darunter neun einklappbare Abschnitte mit je einer Zusammenfassung in einer Zeile. Die Feldsuche öffnet den Abschnitt, in dem ein Wert steht, etwa ttfb, und ein geteilter Link öffnet dieselben Abschnitte wieder.

Ergebnisse lassen sich als Markdown kopieren oder als CSV herunterladen: dieselben Zeilen in derselben Reihenfolge, Werte unformatiert, die Einheit im Header, damit eine Tabellenkalkulation damit rechnen kann.

Navigieren mit dem Befehlsmenü

Drück Cmd/Ctrl+K (oder den Befehls-Button oben), um ein durchsuchbares Befehlsmenü zu öffnen, das die ganze App steuert: zu jeder Seite springen, Organisation oder Site wechseln, Zeitraum und Auflösung ändern sowie Filter hinzufügen, entfernen oder löschen. Tipp einfach los, um alles auf einmal zu durchsuchen, oder geh mit Enter oder → in eine Kategorie; ← oder Backspace geht zurück, Esc schließt.

Getippt wird über alle Organisationen gesucht, die du erreichst: eigene Mitgliedschaften, die Kunden-Organisationen jeder Agentur, zu der du gehörst, und die Applikationen und Domains darin. Jeder Treffer nennt die Organisation, in der er liegt. Applikationen stehen zuerst, bei gleich guten Treffern Prod vor Dev, und eine Auswahl setzt den Applikations-Filter auf der Seite, auf der du bist. Inaktive Sites und Applikationen werden gelistet und gekennzeichnet.

Jede Seite ist mit ihrer Gruppe gelistet, tippst du eine Gruppe („Netzwerk"), erscheint alles darunter, und eine Seite wird auch unter ihrem anderen Namen gefunden („API" findet Fetch/XHR). Öffnest du eine Organisation, stehen ihre Applications über ihren Domains.

Dieselbe Suche gibt es für Skripte als GET /search.

Fehler-Analytics

Fehler ist eine Gruppe in der Sidebar mit vier Seiten: JavaScript-Fehler, Fehlgeschlagene Ressourcen, Network Error Logging und Content Security Policy. Jede hat eine eigene Adresse, Überschrift, Chart und Liste. Bei JavaScript-Fehlern:

  • Betroffene Seitenaufrufe über Zeit: Pageviews mit mindestens einem JavaScript-Fehler, als Anteil aller Pageviews oder unter „Absolut“ als Anzahl. Top 5 legt die fünf Fehler mit den meisten betroffenen Pageviews als Linien dazu, die Legende verlinkt auf jeden. Ziehen über das Chart zoomt hinein.
  • Die eigene Seite eines Fehlers hat denselben Umschalter zwischen Anteil und Anzahl.
  • Die Liste filtert nach Herkunft: Alle, Eigene (deine eigenen Hosts) oder Dritte. Die Auswahl steht im Link, Chart und Fehlerrate zählen weiter jeden Fehler.
  • Die Liste zeigt eine Zeile pro Fehler. Browser melden dieselbe Wurfstelle ein paar Zeichen versetzt, und ein zweiter Aufrufer ist ein zweiter Stack, eine Zeile zählt also alle Varianten und sagt, für wie viele Signaturen sie steht. Auf der API ist das group_variants auf POST /analytics/error-types.
  • Eine Zeile beginnt mit dem, was kaputt ist, als Satz: was passiert ist, wessen Code es ist, die Datei, wie oft und minutengenau wann zuletzt. Jede Zeile trägt eine Sparkline und ein Abzeichen „Neu" oder „Steigend", sortiert wird nach häufigste, neu, steigend oder zuletzt gesehen.
  • Sortiert nach erreichten Pageviews, nicht nach Häufigkeit. Ein einzelner Besuch in einer Schleife ist als Schleife markiert, statt die Liste anzuführen, und „Häufigste" bleibt wählbar.
  • Jeder Fehler hat seine eigene Seite unter /org/<org>/errors/<fingerprint>, zugleich sein Share-Link. Bestehende ?error=-Links leiten dorthin weiter.
  • Seiten mit den meisten Fehlern: sortiert danach, wie viele Fehler eine Seite geworfen hat, nicht nach ihrer Fehlerrate. Eine Seite mit einem Pageview, der einmal geworfen hat, hat eine Rate von 100 % und ist nicht der kaputte Checkout.
  • Fehler-Herkunft: wie sich Pageviews mit Fehler auf eigene und fremde Hosts verteilen. Der dritte Balken enthält Pageviews ohne Fehler plus Fehler ohne zuordenbaren Host.

Was kaputt ist, und wo

Ein Fehler sagt in einem Satz, was kaputt ist, auch wo die Site keine Fehlermeldungen behält. Der Tracker erkennt die Formulierung des Browsers und sendet ihre Form statt des Texts. Eine Zeile liest sich also als „uc.setServiceAlias wurde aufgerufen, aber uc existiert an dieser Stelle nicht", statt nur einen Stack zu zeigen.

„Stack auflösen" liest die minifizierte 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. Das Snippet ist in Zeilen umbrochen und die werfende Zeile markiert, eingefügt wird nur Whitespace, die gemeldete Spalte zeigt also weiter auf ihren Code.

  • Mehrere aufeinanderfolgende Frames aus demselben Vendor-Bundle klappen zu einer Zeile zusammen, die die Library nennt. Sind alle Frames Library, sagt das Panel das: Der Aufruf, der den Fehler gemacht hat, wurde bei fünf Frames abgeschnitten.
  • Ein Frame, der den Fehler nur weiterreicht, ist als Rethrow markiert, die Ursache sitzt dann weiter unten. Der oberste Frame eines minifizierten Stacks ist regelmäßig ein Rethrow in einem Promise-Polyfill.
  • Ein Frame, der sich nicht lesen lässt, sagt warum: kein Pfad gespeichert, die Datei liegt auf fremdem Host, die Datei ist der fastmon-Tracker, oder du hast unter demselben Dateinamen neu deployt und die Position ist weg.
  • Der Endpunkt ist POST /analytics/error-types/symbolicate. Dasselbe Panel steckt in der Zeilen-Detailansicht des Explorers: Pageview öffnen, Fehler aufklappen, und der Stack löst sich auch dort auf.

„Wo es auftritt" ist das Aufschlüsselungs-Raster der Metrikseiten: Seite, Seitentyp, Domain, Land, Gerät, Browser, Betriebssystem, Verbindung, Navigation, Caches, Bots und Netzwerk. Bots und Netzwerk sind dabei, du siehst also, ob ein Fehler echte Besucher erreicht oder nur Crawler.

Ein Fehler ohne Inhalt sagt, warum. Eine Signatur kann mit fünfstelliger Zahl, ohne Message und ohne Stack ankommen: Messages oder Frames für diese Application abgeschaltet, ein Drittanbieter-Skript ohne CORS-Opt-in, oder es kam trotz Erfassung nichts an. Chart und Aufschlüsselung funktionieren trotzdem.

„AI-Prompt" übergibt den ganzen Fall an einen Assistenten: was kaputt ist, die Zahlen, der aufgelöste Stack mit dem Code an der Wurfstelle, wo es auftritt, und Beispiel-Vorkommen. Er schreibt dazu, was deine Site nicht erfasst, damit nichts als Null gelesen wird, was in Wahrheit eine Einstellung ist.

Welche API-Calls daneben fehlschlagen. POST /analytics/error-types/correlated-requests sortiert die fetch/XHR-Endpunkte, die in denselben Pageviews scheitern, jeweils gegen ihre Fehlerquote in Pageviews ohne diesen Fehler. Die Antwort sagt, dass etwas gemeinsam auftritt, nie dass eines das andere verursacht.

Eine Fehlersignatur ist ein Filter wie jeder andere. Jede Fehlerzeile führt in den Explorer, eingegrenzt auf die Pageviews, die sie getragen haben, und „Fehlersignatur" steht in der Filterliste. LCP, Browser, Länder oder der Checkout-Funnel lassen sich also über den Traffic lesen, auf dem eine Sache kaputt ist. filters.error_fingerprint_kind sagt, aus welcher Liste der Key stammt (error oder failed_resource). Eine Query damit liest die Rohzeilen statt eines Rollups und kostet entsprechend.

Eigene Subdomains zählen als eigene. First Party heißt: dieselbe registrierbare Domain wie die Seite, und zwar in der Fehlerrate, in der Fehler-Herkunft, im Fetch/XHR-Split und in der Ressourcen-Liste gleichermaßen.

ScriptError ist eine nicht abgefangene Exception in einem Skript von einem anderen Origin, geladen ohne CORS-Opt-in, der Browser verbirgt also Dateiname, Zeile und Meldung. Lädst du das Skript mit crossorigin="anonymous" von einem Host, der Access-Control-Allow-Origin sendet, meldet der Browser den echten Fehler. Siehe Tracker → Was als Fehler zählt. Wo ScriptError vorkommt, listet die Fehlertypen-Antwort own_subdomain_hosts, dort fehlt der Header meist.

Wie viel Detail du siehst, hängt von den Tracker-Einstellungen der Site ab: Fehlertyp, Anzahl und Message-Form kommen immer. Die Fehler-Message braucht collect_error_messages, volle Stack-Frames brauchen collect_error_frames.

Fehlgeschlagene Ressourcen

Ein fehlgeschlagenes <img>, <script> oder <link> ist ein eigenes Signal, mit eigener Rate (failed_resource_rate), eigenem Tab und eigener Kurve neben der Fehlerrate. Es wird in zwei Buckets geteilt:

  • Eigene Hosts: die Hälfte, an der du etwas tun kannst. Ein kaputter Bildpfad, ein Bundle, das nach einem Deploy 404 liefert.
  • Fremde Hosts: dominiert von Ad-Blockern und Tracking-Schutz, also kein Defekt der Seite.

Für die Zuordnung gilt die Regel der registrierbaren Domain von oben. Die Liste gruppiert nach Host, jeder mit seinem Anteil an allen fehlgeschlagenen Ladevorgängen; ein geöffneter Host zeigt die einzelnen Ressourcen darunter. Eine zweite Ansicht sortiert Seiten nach dem Anteil ihrer Pageviews, die eine Ressource verloren haben.

Blende einen Host aus, und die Liste wird lesbar. host und exclude_hosts grenzen auch die Summen ein, anders als ownership, 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. Übergib den fingerprint der Zeile an POST /analytics/failed-resources/detail. Die Fehler-Detailansicht weist einen Ressourcen-Key ab.

Fehlgeschlagene Ressourcen ist ein eigener Filter und eine eigene Metrik: >= 1 grenzt jede Ansicht auf Pageviews ein, bei denen etwas nicht geladen hat. In der Pageview-Detailansicht haben die fehlgeschlagenen Ladevorgänge einen eigenen Block, getrennt von den JavaScript-Fehlern.

Der Pfad ist häufig leer, weil er collect_error_frames braucht. Ein fehlgeschlagener Ladevorgang kann auch eine wackelige Verbindung oder ein abgebrochener Request auf Besucherseite sein, nicht zwangsläufig etwas Kaputtes auf deinem Server.

Ad-geblockte Requests an bekannte Tracker-Hosts bleiben als Teilmenge des fremden Buckets sichtbar, ausgewiesen als blocked_count: zu lesen als „N als ad-geblockt ausgeschlossen", nicht als Fehler.

Der Listen-Endpunkt ist POST /analytics/failed-resources. Der Fehlertypen-Endpoint weist error_type: ["ResourceLoadError"] mit einem 400 ab, der hierher verweist, denn eine leere Liste würde sich wie „du hast keine" lesen.

Besucher

Die Besucher-Seite listet eindeutige Besucher mit Startzeit, Dauer, Seitenanzahl, Land, Gerät, durchschnittlichem LCP und Fehlern. Zwei Spalten zeigen auf einen Blick, wie der Besuch lief:

  • Ausgang: bestellt, Checkout verlassen, Warenkorb, gestöbert oder abgesprungen.
  • Verlauf: ein Block pro Seite, die Breite ist die Verweildauer, die Farbe der Seitentyp. Eine rote Marke steht für Fehler, ein Haken für eine Bestellung.

Die Zusammenfassung über der Liste gilt für den ganzen Zeitraum: Besucher, Seitenaufrufe pro Besucher und der Anteil mit JavaScript-Fehler, langsame Besucher (durchschnittlicher LCP über 4 s) und Käufer. Segment-Chips (mit Fehlern, langsam, bestellt, Checkout erreicht, Warenkorb-Aktivität, nur eine Seite) setzen die Verhaltensfilter und zeigen, wie viele Besucher sie listen. „Verhalten anpassen“ öffnet alle Filter: Seiten, Fehler, Dauer, LCP, Seitentyp und Funnel-Stufe. Bestellungen, Checkout und Warenkorb erscheinen nur bei einem Shop.

Ein Besucher öffnet sich überall, wo er verlinkt ist, in einem Dialog: in dieser Liste, bei NEL- und CSP-Reports, im Explorer und bei Checkout-Events. Auf dem Handy ist er ein Sheet von unten, und ?visitor= verlinkt direkt darauf.

  • Die Journey zeigt jeden Pageview der Reihe nach mit Web Vitals, Fehlern, Seitentyp und bei Shops der Checkout-Stufe und den Warenkorb-Aktionen. Checkout-Events und NEL- und CSP-Reports stehen dazwischen, abgebrochene Ladevorgänge erst, wenn du sie einschaltest.
  • Ohne Pageviews im Zeitraum listet sie nur die Reports und Events des Besuchers.
  • Ein Klick auf eine Seite öffnet ihr volles Detail, und „Im Explorer öffnen“ listet dort alle Pageviews des Besuchers.
  • Aktualisieren holt neue Seiten eines laufenden Besuchs nach. Der Live-Schalter macht das alle 7 Sekunden.
  • Ein Cmd- oder Strg-Klick auf einen Besucher-Link öffnet die Visitors-Seite in einem neuen Tab.

Gezählt wird entlang einer Identitätsachse: stitch oder session, und die count_visitors_by der Application legt den Standard fest. Neue Sites starten auf Standard, das stitch speichert; das Preset Minimal speichert keine der beiden und lässt die Liste leer. Das Replay je Besucher braucht die session-Identität. Siehe Besucher und Sessions.

Fetch/XHR und Server-Timing

Der Fetch/XHR-View hat einen aggregierten Wasserfall (Start-Offsets je Endpunkt, Dauer-Histogramme und -Perzentile, eine Statusfehler-Verteilung) plus ein Per-Beacon-Detail. Der Server-Timing-View schlüsselt die Metriken deines Backends auf. Beide lesen Felder, die der Tracker jedem Beacon hinzufügt (siehe der Beacon).

Ein aufgeklappter Endpunkt zeigt seinen eigenen p75 oder p95 im Zeitverlauf mit Aufrufen und Release-Markern und steht in der URL. Eine Seite mit mehr als 24 API-Endpunkten behält 24 davon benannt, der Rest summiert sich in eine namenlose other-Zeile. Von Adblockern geblockte Calls zählen darin nicht als Fehler.

Die Fetch/XHR-Fehlerrate zählt Fehler auf deinen eigenen Hosts, nach derselben Regel der registrierbaren Domain wie die Fehlerrate. Fehler auf fremden Hosts stehen als eigene Zahl daneben, überwiegend aus dem Ad-Blocker des Besuchers. Der 1P/3P-Filter des Panels folgt derselben Regel.

Der Beacon liest den Header bei jedem Pageview, und die Dashboards darüber werden noch optimiert. Wie du den Header sendest und wie fastmon ihn in Backend-Phasen, Cache-Status und Custom-Keys zerlegt, steht unter Server-Timing-Header.

Experience Score

Das Experience-Score-Panel schlüsselt den Score nach Segment auf (alle Besucher, Desktop, Mobile und langsame Verbindungen), jeweils mit Note, Zahlenwert und den Metriken dahinter.

API

Jedes Panel entspricht einem Query-Endpunkt unter /organizations/{org_id}/analytics/…: ein flexibler Query-Endpunkt für Zeitreihen und Breakdowns, dazu dedizierte Endpunkte für Histogramme, Fehlertypen und -details, Besucher, Fetch/XHR, Server-Timing, Ressourcen- und Third-Party-Breakdowns, LoAF, den Checkout-Funnel und den Experience Score. Siehe die Analytics-Endpunktreferenz (nur auf Englisch).

Weiterlesen

Auf dieser Seite