Analytics

Analytics zeigt, wer auf deiner Site ist, woher die Besucher kommen, welche Seiten und Fehler sie sehen und wie ihre Besuche verlaufen.

Das DashboardCopy Anchor Link

Die Analytics-Hauptansicht einer Site zeigt von oben nach unten:

• Live-Zeile: die Besucher, die gerade auf der Site sind. „Live ansehen" öffnet einen Ticker der neuesten Events: standardmäßig die Bestellungen mit ihrem Wert, wahlweise den ganzen Kaufweg oder jedes Event. Jede Zeile öffnet ihren Besucher.
• Kacheln: Besucher, Pageviews, Pageviews pro Besucher und im Shop Bestellungen und Conversion, jede mit einer Sparkline über den ganzen Zeitraum. Die Veränderung vergleicht mit denselben Wochentagen und Uhrzeiten, so wenige ganze Wochen früher, wie das Fenster braucht.
• Trend-Chart: die gewählte Kachel über den Zeitraum (?metric=). Bestellungen zeigt es als Linie oder als drei Bahnen für Warenkorb, Checkout erreicht und bestellt, jede mit eigener Skala.
• Bots neben dem Chart-Typ teilt das Pageview-Chart in Menschen und Bots, einzelne Bots oder Bot-Typen. Kacheln und Karten behalten den Bot-Filter der Seite.
• Aufschlüsselung: Karten für Seiten, Seitentypen, Quellen, Standorte, Geräte, Traffic-Qualität, Kampagnen und Zugriff. Ein Menü wählt die Dimension einer Karte, die Karte blättert durch ihre Zeilen, und ein Klick auf eine Zeile filtert die Seite.
• Alle Werte einer Karte öffnest du über ihren Titel, in einem Pop-up mit Suche, zweiter Dimension, sortierbaren Spalten und CSV-Download.
• Wege der Besucher: der Checkout-Funnel und der Käufervergleich in einer Karte, die Besuchstiefe und Besucherlisten, die die Besucher-Seite öffnen.
• Aktive Stunden: Pageviews nach Tageszeit und nach Wochentag als Balken. Die Heatmap ist einen Schalter entfernt.

Linien-Charts zeichnen jeden Bucket an seinem Ende. Der laufende Bucket einer Zählung ab einer Stunde läuft gestrichelt auf eine Hochrechnung zu, sobald ein Drittel davon vorbei ist. Release-Marker sind eine dünne lila Linie, Tracker-Releases blau.

Was ein „Besucher" hier bedeutet, steht unter Privacy.

ShopfloorCopy Anchor Link

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.

PartnerfloorCopy Anchor Link

Partner-Organisationen finden den Partnerfloor in der Seitenleiste unter Partner. Jeder Live-Client ist dort eine Zone.

• Größe und Farbe: Eine Zone wächst mit dem Anteil des Clients an deinem Traffic der letzten Stunde. Ihre Farbe zeigt seinen LCP p75.
• Jede Zone zeigt die Leute darin, Warenkorb und Checkout, die Bestellungen von heute und die Veränderung zur Vorwoche.
• Ein Klick öffnet den Shopfloor des Clients direkt hier.
• Bedienung: Filtern kannst du nur nach Traffic-Klasse. Zeitfenster, Pause, Kiosk-Modus und Ton funktionieren wie auf dem Shopfloor.
• Live ist ein Client, dessen Organisation aktiv und freigegeben ist und der eine aktivierte, aktive Site auf einer aktiven Production-Application hat.

Die API ist POST /organizations/{org_id}/partner/live, abgefragt im Takt von meta.next_poll_ms. Sie braucht direkte Mitgliedschaft in der Partner-Organisation mit partner:read und analytics:read. Sie nimmt nur bot_class, und data_total, client_count und site_count zählen nur die gelisteten Clients.

ZeitraumCopy Anchor Link

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.
• Datum und Uhrzeit sind eigene Felder und greifen sofort. Das Ausdrucksfeld zeigt den aktuellen Zeitraum, etwa now-7d, und nimmt auch ein Fenster in der Vergangenheit (7d-3d) oder eine Uhrzeitspanne (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.

AuflösungCopy Anchor Link

Picker und Befehlsmenü bieten jede Bucket-Breite mit der Zahl der Buckets an, die sie ergibt. Eine Breite braucht 4 bis 1500 Buckets im Fenster.

Auto nimmt die kleinste Breite mit höchstens 300 Buckets, ab 28 Tagen Tage. Die letzten 24 Stunden bekommen 5-Minuten-Buckets, 48 Stunden 15-Minuten-Buckets und 7 Tage stündliche.

Buckets ab 6 Stunden beginnen nach deiner Uhr: 6-Stunden-Buckets um 00, 06, 12 und 18 Uhr Ortszeit, ein Tag um Mitternacht, eine Woche am Montag. Über eine Zeitumstellung hat ein Tag 23 oder 25 Stunden.

FilternCopy Anchor Link

Neben dem Zeitraum-Picker sitzt auf jeder Analytics-Seite eine Filterleiste. Tipp eine Dimension und einen Wert, etwa country = DE, und drück Enter für einen Filter-Chip. Das Wertefeld schlägt die echten Werte des Zeitraums mit ihren Pageviews vor.

Die Dimensionsauswahl listet zuerst Seite, Land und Gerät, dann Browser, Betriebssystem, Verbindung, Viewport, Referrer, UTM-Felder, Click-ID-Label, Domain, Navigationstyp, Protokoll und die Checkout-Stufe. Leere Werte wie „Direkt / keine" lassen sich noch nicht filtern.

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 ExplorerCopy Anchor Link

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 laden, mit Rohwerten und der Einheit im Header.

Navigieren mit dem BefehlsmenüCopy Anchor Link

Cmd/Ctrl+K öffnet ein Befehlsmenü für die ganze App: Seiten, Organisationen, Sites, Zeitraum, Auflösung und Filter. Enter oder → öffnet 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.

Tippst du eine Gruppe („Netzwerk"), erscheint jede Seite darunter, und „API" findet Fetch/XHR.

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

Fehler-AnalyticsCopy Anchor Link

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. Eine Zeile zählt alle Varianten einer Wurfstelle 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.
• 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 woCopy Anchor Link

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. Die werfende Zeile ist markiert.

• 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.
• 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 Message und Stack sagt, warum: Messages oder Frames abgeschaltet, ein Drittanbieter-Skript ohne CORS-Opt-in, oder es kam 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.

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. filters.error_fingerprint_kind sagt, aus welcher Liste der Key stammt (error oder failed_resource).

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 ein Fehler in einem fremden Skript ohne CORS, dessen Details der Browser verbirgt. Lade es mit crossorigin="anonymous" von einem Host, der Access-Control-Allow-Origin sendet. 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 RessourcenCopy Anchor Link

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: überwiegend Ad-Blocker und Tracking-Schutz.

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.

Ein ausgeblendeter Host fehlt auch in den Summen: host und exclude_hosts grenzen sie ein, ownership nicht.

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.

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.

BesucherCopy Anchor Link

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

• Ausgang: bestellt, Checkout verlassen, Warenkorb, gestöbert oder abgesprungen.
• Quelle: woher der Besucher kam, etwa Google-Suche, Newsletter oder direkt.
• 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.
• Der Einstieg und jede Rückkehr von außen stehen auf der Zeitleiste und vor der jeweiligen Seite, mit Kampagne, wenn es eine gibt. Siehe arrival.
• 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.

Gezählt wird nach stitch oder session, je nach count_visitors_by. Das Preset Minimal speichert keins von beiden und lässt die Liste leer. Siehe Besucher und Sessions.

Fetch/XHR und Server-TimingCopy Anchor Link

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.

Wie du den Header sendest und wie fastmon ihn zerlegt, steht unter Server-Timing-Header.

Experience ScoreCopy Anchor Link

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.

APICopy Anchor Link

Jedes Panel hat einen Endpunkt unter /organizations/{org_id}/analytics/…, die meisten den Query-Endpunkt. Eigene Endpunkte gibt es für Histogramme, Fehler, Besucher, Fetch/XHR, Server-Timing, LoAF, den Checkout-Funnel und den Experience Score. Die Referenz gibt es nur auf Englisch.

Nur ein Fenster von höchstens 6 Stunden, das höchstens 10 Minuten vor jetzt endet, liest Live-Beacons. Jedes andere liest die finalisierten Pageviews.

WeiterlesenCopy Anchor Link

• Checkout-Funnel: wie Pageviews ihre Stufe bekommen, und was die Zahlen bedeuten.
• Tracker-Einstellungen: was der Tracker pro Einstellung sammelt.
• Besucher und Sessions: wie aus Pageviews Besucher und Sessions werden.
• Synthetic Monitoring: das Labor-Gegenstück zu diesen Feld-Dashboards.