TL;DR
Real-time analytics to wyświetlanie danych z minimalnym opóźnieniem (sekundy, minuty). Wymaga strumieniowania zdarzeń (np. WebSockets, SSE) lub częstego odpytywania API i wydajnego agregowania. Sprawdza się w operacjach, monitoringu, wsparciu klienta i kampaniach – nie zawsze jest konieczny przy raportach strategicznych.
Dla kogo to jest
- Product ownerów i zespołów operacyjnych
- Deweloperów budujących panele i dashboardy
- Osób odpowiedzialnych za monitoring i reakcję na zdarzenia
Fraza (SEO)
real-time analytics, dashboard na żywo, dane w czasie rzeczywistym, analityka real-time
Kiedy real-time ma sens?
- Operacje – support, sprzedaż, wykrywanie incydentów (np. błędy, spadki konwersji)
- Monitoring – metryki serwerów, logi, alerty
- Kampanie – live wyniki A/B testów, reklamy (np. w trakcie eventu)
- UX – „X osób ogląda teraz”, licznik w czasie rzeczywistym
- Nie zawsze – raporty miesięczne, strategiczne KPI często wystarczą w wersji „odświeżanej co godzinę lub dzień”
Źródła danych
- Zdarzenia z aplikacji – kliknięcia, konwersje, błędy (wysyłane do pipeline’u zdarzeń)
- Baza danych – agregacje (COUNT, SUM) – przy dużym ruchu lepiej nie odpytywać co sekundę; lepiej stream lub cache
- Logi i metryki – np. Prometheus, Grafana, log aggregation (ELK, Loki)
- Zewnętrzne API – np. reklamy, płatności – często polling co 1–5 min
Techniki dostarczania danych do frontendu
1. Polling
Frontend co X sekund wywołuje API (np. „daj mi ostatnie metryki”). Proste, ale przy wielu użytkownikach obciąża backend. Sensowne przy odświeżaniu co 30–60 s.
2. Server-Sent Events (SSE)
Serwer pushuje aktualizacje jednym strumieniem (HTTP). Jednokierunkowe, proste w implementacji, dobre do „strumienia zdarzeń” na dashboardzie.
3. WebSockets
Pełny duplex – serwer i klient wysyłają dane kiedy chcą. Odpowiednie przy interaktywnych panelach, czatach, współdzielonych sesjach. Wymaga więcej infrastruktury (sticky sessions, skalowanie).
4. Pre-agregacje i cache
Zamiast liczyć „na żywo” przy każdym odświeżeniu – pipeline (np. Kafka + worker) agreguje zdarzenia do przedziałów czasowych (np. co minutę) i zapisuje do cache (Redis) lub bazy. Frontend czyta gotowe zagregowane dane; można je serwować przez SSE lub krótki polling.
Narzędzia
- GA4 – dane „na żywo” z opóźnieniem zwykle 1–2 minuty; wystarczy do ogólnego podglądu ruchu
- Metabase, Superset, Redash – dashboardy z bazy; real-time = częste odświeżanie zapytania (uwaga na obciążenie)
- Grafana – metryki (Prometheus, InfluxDB itd.) z odświeżaniem co kilka sekund
- Własny stack – zdarzenia → kolejka → agregacja → Redis/DB → API + SSE/WebSocket → frontend
Best practices
- Nie odpytywać bazy co 1 s – użyj strumienia zdarzeń i pre-agregacji
- Limitowanie – ile danych pokazujesz (np. ostatnie 100 zdarzeń, ostatnia godzina)
- Fallback – przy zerwaniu połączenia (SSE/WS) – automatyczne ponowne połączenie lub przełączenie na polling
- Uprawnienia – dane real-time często wrażliwe; te same zasady autoryzacji co dla raportów
Checklista
- Określ, które metryki muszą być real-time
- Wybór: polling vs SSE vs WebSocket
- Pipeline zdarzeń i agregacja (jeśli nie „surowe” logi)
- Cache / warstwa odczytu pod dashboard
- Testy przy większej liczbie równoczesnych użytkowników
FAQ
GA4 „real-time” – czy to naprawdę na żywo?
Tak, ale z opóźnieniem zwykle 1–2 minuty i z ograniczonymi wymiarami. Do operacyjnego „co się dzieje teraz” często wystarczy; do sekundowych zdarzeń (np. błędy w aplikacji) potrzebny własny pipeline.
Czy real-time zawsze wymaga WebSockets?
Nie. SSE lub nawet polling co 5–10 s wystarczy w wielu przypadkach. WebSockets są potrzebne, gdy potrzebna jest interakcja w dwie strony lub bardzo duża częstotliwość aktualizacji.
Jak nie przeciążyć bazy przy real-time dashboardzie?
Agreguj dane w pipeline’ie (worker odczytujący zdarzenia z kolejki) i zapisuj wyniki do Redis lub osobnej tabeli. Dashboard odczytuje tylko gotowe zagregowane wartości, nie liczy na żywo przy każdym odświeżeniu.