Analytics

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. Es ergänzt das Web-Vitals-Dashboard: gleiche Daten, andere Frage. Web Vitals fragt „wie schnell ist die Site?", Analytics fragt „was passiert auf ihr?".

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: Unique Visitors, Pageviews, Views per Visit und Checkouts, jeweils mit Sparkline und Veränderung zur Vorperiode. Die Zähl-Kacheln zeigen außerdem einen Durchschnitt pro Minute über den gewählten Zeitraum, damit sich ein Tag und ein Monat vergleichen lassen. 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 über dem Chart, in einer Reihe mit dem Umschalter für Balken und Fläche, und jede Serie lässt sich einzeln abschalten: bei Checkouts liegt der Warenkorb eine Größenordnung über den abgeschlossenen Käufen, und ohne ihn skaliert die Achse auf den Rest. Jede Serie hat ihren eigenen Vorperioden-Wert und ihren eigenen Schalter dafür.
• 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). 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.
• 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.
• Traffic-Qualität: die Aufteilung aus der Bot-Klassifizierung, zuerst 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. Bewusst 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.

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, Abgeschlossen).

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.

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: der schnellste Weg, „wie sieht das ohne den Länderfilter aus?" zu beantworten und ihn danach wieder einzuschalten. Ein ausgeschalteter Filter grenzt nichts ein und zählt nicht im Badge; ein Klick auf dasselbe Land in der Karte oder dasselbe Gerätesegment schaltet ihn wieder ein, statt einen zweiten Filter anzulegen. Auch dieser Zustand steht in der URL, ein geteilter Link öffnet also mit denselben ein- und ausgeschalteten Filtern.

Der Explorer

Der Explorer ist die Tabelle unter allem anderen: Pageviews nach jeder Dimension gruppieren und die Metriken charten, oder die Rohzeilen lesen. „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 Zeile ergänzt ihren Wert in den Filtern statt die anderen zu verwerfen: aus einer auf Deutschland gefilterten Seite heraus wird also eingeengt und nicht die Tabelle geleert.

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, nicht nur über die gerade geöffnete: 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. Eine Domain in einer anderen Organisation zu erreichen heißt also nicht mehr, sich zu erinnern wo sie liegt und vorher dorthin zu wechseln. 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. Inaktive Sites und Applikationen werden gelistet und gekennzeichnet, denn eine wieder zu aktivieren fängt damit an, sie zu finden.

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

Fehler-Analytics

Die Fehleransicht verfolgt JavaScript-Fehler über die ganze Site:

• Fehlerrate über Zeit: der Anteil der Pageviews mit mindestens einem JavaScript-Fehler. Ein fehlgeschlagenes Bild, Skript oder Stylesheet ist hier kein Fehler, sondern zählt zu den fehlgeschlagenen Ressourcen und läuft als eigene Kurve im selben Chart.
• Fehlertypen: Fehler gruppiert nach Fingerprint (Typ + Meldung + Stack-Form), sortiert nach Häufigkeit.
• Detailansicht: pro Fingerprint: Gesamtzahl, betroffene Besucher, erstes/letztes Auftreten, eine Zeitreihe, Breakdowns nach URL, Browser, Gerät, Betriebssystem und Land sowie Beispiel-Pageviews mit Stack-Frames.
• Fehler-Herkunft: wie sich Pageviews mit Fehler auf eigene und fremde Hosts verteilen. Der dritte Balken, „Kein Fehler oder nicht zuordenbar", enthält Pageviews ohne Fehler plus Fehler, die ohne zuordenbaren Host angekommen sind.

Eigene Subdomains zählen als eigene. First Party heißt: dieselbe registrierbare Domain wie die Seite. Ein Bundle von cdn.shop.example auf einer Seite unter www.shop.example ist also dein eigenes Skript, und zwar in der Fehlerrate, in der Fehler-Herkunft, im Fetch/XHR-Split und in der Ressourcen-Liste gleichermaßen.

ScriptError ist eine Gruppe, die man kennen sollte: eine nicht abgefangene Exception in einem Skript von einem anderen Origin, geladen ohne CORS-Opt-in. Der Browser verbirgt Dateiname, Zeile und Meldung, die Gruppe lässt sich also keiner Datei zuordnen. Auflösen lässt sie sich, 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. Wo ScriptError vorkommt, listet die Fehlertypen-Antwort zusätzlich own_subdomain_hosts: Hosts auf der eigenen Domain, die in diesem Zeitraum Skripte ausgeliefert haben. Dort fehlen Attribut und Header meist.

Wie viel Detail du siehst, hängt von den Tracker-Einstellungen der Site ab: Fehlertyp und Anzahl 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), eigener Kurve neben der Fehlerrate und eigenem Block am Ende der Seite. 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 sortiert Hosts und Pfade nach fehlgeschlagenen Ladevorgängen und nach betroffenen Pageviews; die Summen gelten für den ganzen Zeitraum, die oberen Zeilen addieren sich also nicht dazu auf. Der Pfad ist häufig leer, weil er collect_error_frames braucht.

Ad-geblockte Requests an bekannte Tracker-Hosts bleiben als Teilmenge des fremden Buckets sichtbar, und das Fehlertypen-Panel weist sie als blocked_count aus: zu lesen als „N als ad-geblockt ausgeschlossen", nicht als Fehler.

Der Endpoint 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

Der Besucher-Explorer listet eindeutige Besucher (Start- und Endzeit, Dauer, Seitenanzahl, Land mit Flagge und Name, Geräteinfo, durchschnittliches LCP/FCP, Fehlerzahl) mit Filtern, dazu eine Detailansicht pro Besucher: jeder Pageview in Reihenfolge, jeweils mit seinen Web Vitals, Fehlern, seinem Page-Type und, bei Shops, seiner Checkout-Stufe und seinen Warenkorb-Aktionen. Die Zusammenfassung über der Liste beschreibt den ganzen gewählten Zeitraum, nicht die geladene Ergebnisseite: Besucher, Besucher mit nur einer Seite und der Median der Seiten pro Besucher. Verhaltensfilter grenzen die Liste ein auf Besucher mit mindestens so vielen Seiten, Fehlern, so viel Dauer oder LCP, mit einem bestimmten Page-Type in der Journey, oder auf solche, die eine Funnel-Stufe erreicht oder eine Warenkorb-Interaktion ausgelöst haben. Ein Besucher lässt sich per ?visitor= direkt verlinken; der Kopf der Journey sagt dann, wer der Besucher war (Land, Gerät, Betriebssystem, Browser), und listet auf, was variiert, wenn ein gestitchter Besucher das Gerät wechselt. In der Liste lässt sich die volle ID per Hover kopieren, eine Zeilenaktion grenzt die Seite auf diesen Besucher ein (bei einem Stitch als echter Filter-Chip, bei einer Session-ID über das Suchfeld), und Land, Gerät, Betriebssystem und Browser tragen dasselbe Hover-Plus und -Minus wie die Pageview-Tabelle des Explorers.

Ein Besucher wird entlang einer Identitätsachse gezählt: stitch (vorhanden, wenn store_stitch an ist) oder session (die seitenübergreifende session_id, vorhanden, wenn collect_sessions an ist). Die count_visitors_by der Site legt den Standard fest. Neue Sites starten auf Standard, das stitch speichert, der Besucher-Explorer funktioniert also von Anfang an; das Preset Minimal speichert keine der beiden Identitäten und lässt ihn leer. Das Replay je Besucher braucht die session-Identität. Das ganze Modell steht unter Besucher und Sessions.

Fetch/XHR und Server-Timing

Über Seitennavigationen hinaus zeigt das Dashboard auch In-Page-Request-Telemetrie: einen Fetch/XHR-View mit aggregiertem Wasserfall (Start-Offsets je Endpunkt, Dauer-Histogramme und -Perzentile sowie eine Statusfehler-Verteilung), dazu ein Per-Beacon-Detail, und einen Server-Timing-View, der die Server-Timing-Metriken deines Backends aufschlüsselt. Beide speisen sich aus Feldern, die der Tracker jedem Beacon hinzufügt (siehe der Beacon).

Die Fetch/XHR-Fehlerrate zählt Fehler auf deinen eigenen Hosts, nach derselben Regel der registrierbaren Domain wie die Fehlerrate. Ein Aufruf von www.shop.example an api.shop.example ist also deiner. Fehler auf fremden Hosts stehen als eigene Zahl daneben, weil diese Population überwiegend aus dem Ad-Blocker des Besuchers stammt. Der 1P/3P-Filter des Panels folgt derselben Regel.

Der Server-Timing-View ist neu: Der Beacon liest den Header bereits 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. Praktisch für den Klassiker: Die Gesamtnote sieht gut aus, aber Mobile über 3G fällt durch.

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

• Checkout-Funnel: wie Pageviews ihre Stufe Warenkorb, Checkout oder Abschluss bekommen, und was die Zahlen bedeuten.
• Tracker-Einstellungen: was der Tracker pro Einstellung sammelt, und warum die Session-Identität oder Stack-Traces fehlen können.
• Besucher und Sessions: wie aus Pageviews Besucher und Sessions werden.
• Synthetic Monitoring: das Labor-Gegenstück zu diesen Feld-Dashboards.