Kurzfassung
Real-time Analytics bedeutet, Daten mit minimaler Verzögerung (Sekunden, Minuten) anzuzeigen. Dafür braucht es Event-Streaming (z. B. WebSockets, SSE) oder häufiges API-Polling plus effiziente Aggregation. Es eignet sich für Betrieb, Monitoring, Support und Kampagnen – für strategische Reports nicht immer nötig.
Für wen ist das
- Product Owner und operative Teams
- Entwickler von Panels und Dashboards
- Verantwortliche für Monitoring und Reaktion auf Ereignisse
Keyword (SEO)
real-time analytics, live dashboard, echtzeit-daten, real-time analytik
Wann ist Echtzeit sinnvoll?
- Betrieb – Support, Vertrieb, Erkennung von Vorfällen (z. B. Fehler, Konversionsrückgänge)
- Monitoring – Server-Metriken, Logs, Alerts
- Kampagnen – Live-Ergebnisse von A/B-Tests, Werbung (z. B. während eines Events)
- UX – „X Nutzer sehen gerade“, Echtzeit-Zähler
- Nicht immer – Monatsberichte, strategische KPIs reichen oft mit „Aktualisierung stündlich oder täglich“
Datenquellen
- App-Events – Klicks, Konversionen, Fehler (an Event-Pipeline gesendet)
- Datenbank – Aggregationen (COUNT, SUM) – bei hohem Traffic besser nicht jede Sekunde abfragen; Stream oder Cache nutzen
- Logs und Metriken – z. B. Prometheus, Grafana, Log-Aggregation (ELK, Loki)
- Externe APIs – z. B. Werbung, Zahlungen – oft Polling alle 1–5 Min
Daten zum Frontend bringen
1. Polling
Frontend ruft alle X Sekunden die API auf (z. B. „letzte Metriken“). Einfach, bei vielen Nutzern belastet es das Backend. Sinnvoll bei Aktualisierung alle 30–60 s.
2. Server-Sent Events (SSE)
Server schickt Updates über einen HTTP-Stream. Einseitig, einfach umzusetzen, gut für „Event-Stream“ im Dashboard.
3. WebSockets
Vollduplex – Server und Client senden, wann sie wollen. Geeignet für interaktive Panels, Chat, geteilte Sessions. Erfordert mehr Infrastruktur (Sticky Sessions, Skalierung).
4. Vor-Aggregation und Cache
Statt bei jedem Refresh „live“ zu rechnen: Pipeline (z. B. Kafka + Worker) aggregiert Events in Zeitfenster (z. B. pro Minute) und schreibt in Cache (Redis) oder DB. Frontend liest fertige Aggregate; Auslieferung per SSE oder kurzem Polling.
Tools
- GA4 – „Live“-Daten mit meist 1–2 Min Verzögerung; ausreichend für groben Traffic-Überblick
- Metabase, Superset, Redash – Dashboard aus DB; Echtzeit = häufige Abfrage-Aktualisierung (Belastung beachten)
- Grafana – Metriken (Prometheus, InfluxDB usw.) mit Aktualisierung alle paar Sekunden
- Eigener Stack – Events → Queue → Aggregation → Redis/DB → API + SSE/WebSocket → Frontend
Best Practices
- Datenbank nicht jede Sekunde abfragen – Event-Stream und Vor-Aggregation nutzen
- Begrenzung – wie viele Daten angezeigt werden (z. B. letzte 100 Events, letzte Stunde)
- Fallback – bei Verbindungsabbruch (SSE/WS) – automatische Wiederverbindung oder Wechsel zu Polling
- Berechtigungen – Echtzeit-Daten oft sensibel; gleiche Auth wie bei Reports
Checkliste
- Festlegen, welche Metriken Echtzeit sein müssen
- Wahl: Polling vs SSE vs WebSocket
- Event-Pipeline und Aggregation (wenn nicht „rohe“ Logs)
- Cache / Lese-Schicht für Dashboard
- Tests bei vielen gleichzeitigen Nutzern
FAQ
GA4 „Real-time“ – wirklich live?
Ja, aber mit meist 1–2 Min Verzögerung und begrenzten Dimensionen. Für operatives „was passiert gerade“ oft ausreichend; für sekundengenaue Events (z. B. App-Fehler) eigener Pipeline nötig.
Braucht Echtzeit immer WebSockets?
Nein. SSE oder sogar Polling alle 5–10 s reicht in vielen Fällen. WebSockets sind für Zwei-Wege-Interaktion oder sehr hohe Update-Frequenz.
Wie die DB bei Echtzeit-Dashboard nicht überlasten?
In einer Pipeline aggregieren (Worker liest aus Queue) und Ergebnisse in Redis oder separate Tabelle schreiben. Dashboard liest nur voraggregierte Werte, rechnet nicht bei jedem Refresh live.