Direkt zum Hauptinhalt

Realtime-Dashboard nutzen

Das Realtime-Dashboard ist der Live-Blick auf deinen gerade laufenden Stream. Route: /dashboard/analytics-realtime (Komponente , Backend über GET /v1/analytics/realtime).

Woher die Zahlen kommen

Alle Live-Zähler sind rollierende Minuten-Buckets in Redis, keine Live-Datenbank-Abfrage. Bei jedem Ereignis (Follow, Sub, Alert, Chat-Nachricht, Command, Engagement-Spike) inkrementiert dein Worker sofort einen Redis-Zähler unter dem Schema rt:metric:<metric>:<channel>:<minute-bucket>. Jeder Bucket lebt 2 Stunden (TTL 7200s), danach fällt er automatisch raus. Das Standard-Auswertungsfenster ist 60 Minuten, maximal abfragbar sind 1440 Minuten (24 Stunden).

Aktiver-Viewer-Wert liegt separat unter rt:viewers:<channel> mit nur 120 Sekunden TTL — kommt vom Helix-Poller, also direkt von Twitch, nicht aus deinem Chat-Traffic abgeleitet.

Was du siehst

Die Seite zeigt sieben Live-Kennzahlen-Karten. Sechs davon sind auf Minuten-Rate umgerechnet (count / window_min); Active Viewers ist ein Punktwert ohne Rate-Umrechnung:

  • Active Viewers — aktueller Twitch-Viewer-Count (Punktwert, kein Rate-Wert)
  • Follows/Min
  • Subs/Min
  • Alerts/Min — ausgelöste Alert-Overlays
  • Chat-Velocity — Nachrichten pro Minute
  • Commands/Min — Bot-Command-Aufrufe
  • Engagement Spikes — Gesamtzahl erkannter Aktivitäts-Ausschläge im Fenster

Das sind die sechs Metriken, die RealtimeAnalytics::METRICS im Backend definiert — es gibt aktuell keine weiteren Live-Kennzahlen auf dieser Seite (keine Smart-Shield-Karte, keine Combo-Live-Anzeige, keine Action-Queue-Auslastung — falls du das aus einer älteren Doku-Version kennst: das ist nicht (mehr) Teil dieser Seite).

Aktualisierung

Das Dashboard läuft nicht über WebSocket oder Server-Push. Das Frontend fragt GET /v1/analytics/realtime alle 10 Sekunden per setInterval neu ab. Für die meisten Stream-Situationen reicht das, aber erwarte keine Sekunden-Genauigkeit — ein Spike kann bis zu 10 Sekunden brauchen, bis er in der Anzeige auftaucht.

Spike-Erkennung

Zusätzlich gibt es einen Endpunkt GET /v1/analytics/realtime/spike. Die Heuristik dahinter (detectSpike()): ein Engagement-Spike wird erkannt, wenn die Chat-Nachrichten der aktuellen Minute mindestens das Doppelte des Durchschnitts erreichen ODER den Durchschnitt plus 10 überschreiten (max(2 × avg, avg + 10)). Das ist eine einfache Schwellenwert-Regel, kein ML-Modell — entsprechend kann sie bei sehr niedriger Grund-Chat-Aktivität schon bei kleinen Ausschlägen anschlagen.

Der Endpunkt POST /v1/analytics/realtime/record existiert ebenfalls, ist aber Worker-only — er dient der internen Ereignis-Erfassung, nicht dem Dashboard-Aufruf durch dich.

Viewer-Verlauf (24 Stunden)

Unterhalb der Live-Karten gibt es einen separaten Verlauf über GET /v1/analytics/viewer-timeseries, parametrisiert nach Stunden-Fenster und Plattform (Twitch oder YouTube). Diese Sektion lädt einmal beim Öffnen der Seite bzw. beim Kanalwechsel — sie pollt nicht mit den 10-Sekunden-Zyklus der Live-Karten, weil die Auflösung ohnehin stündlich ist. Angezeigt werden aktueller Wert, Peak, Durchschnitt, Minimum und eine Sparkline über den Zeitraum.

Wenn du gerade nicht live bist

Ohne aktiven Stream zeigt die Seite trotzdem die Kartenstruktur, aber mit leeren oder Nullwerten — es ist kein separater „Vorschau-Modus" mit Beispieldaten, sondern schlicht das reale (leere) Ergebnis der Redis-Abfrage für einen Kanal ohne aktuelle Ereignisse.

Praktischer Einsatz

  • Auf dem Zweitmonitor offen lassen, während du streamst — 10-Sekunden-Takt stört nicht beim Nebenherschauen.
  • Wenn Chat-Velocity plötzlich hoch geht, aber Alerts/Min bei 0 bleibt, ist das ein Hinweis, dass deine Automations/Alerts nicht auf den aktuellen Trigger reagieren — Check wert in „Automations".
  • Nach dem Stream: den Viewer-Verlauf nutzen, um Peak-Zeitpunkt und Abfall-Kurve zu sehen, dann in die Heatmap wechseln (siehe „Heatmap + Growth Insights"), um zu prüfen, ob deine Regeln zu diesen Zeitpunkten überhaupt gefeuert haben.