TL;DR
Real-time analytics means showing data with minimal delay (seconds, minutes). It requires streaming events (e.g. WebSockets, SSE) or frequent API polling plus efficient aggregation. It fits operations, monitoring, support and campaigns – not always needed for strategic reports.
Who this is for
- Product owners and operations teams
- Developers building panels and dashboards
- People responsible for monitoring and reacting to events
Keyword (SEO)
real-time analytics, live dashboard, real-time data, real-time analytics
When does real-time make sense?
- Operations – support, sales, incident detection (e.g. errors, conversion drops)
- Monitoring – server metrics, logs, alerts
- Campaigns – live A/B test results, ads (e.g. during an event)
- UX – “X people viewing now”, live counter
- Not always – monthly reports, strategic KPIs often enough with “refresh every hour or day”
Data sources
- App events – clicks, conversions, errors (sent to event pipeline)
- Database – aggregations (COUNT, SUM) – with high traffic better not poll every second; use stream or cache
- Logs and metrics – e.g. Prometheus, Grafana, log aggregation (ELK, Loki)
- External APIs – e.g. ads, payments – often polling every 1–5 min
Delivering data to the frontend
1. Polling
Frontend calls API every X seconds (e.g. “give me latest metrics”). Simple, but with many users it loads the backend. Reasonable for refresh every 30–60 s.
2. Server-Sent Events (SSE)
Server pushes updates over a single HTTP stream. One-way, simple to implement, good for “event stream” on a dashboard.
3. WebSockets
Full duplex – server and client send when they want. Suited for interactive panels, chat, shared sessions. Needs more infra (sticky sessions, scaling).
4. Pre-aggregation and cache
Instead of computing “live” on every refresh – pipeline (e.g. Kafka + worker) aggregates events into time buckets (e.g. per minute) and writes to cache (Redis) or DB. Frontend reads ready aggregates; serve via SSE or short polling.
Tools
- GA4 – “live” data with usually 1–2 min delay; enough for general traffic overview
- Metabase, Superset, Redash – DB-backed dashboards; real-time = frequent query refresh (watch load)
- Grafana – metrics (Prometheus, InfluxDB, etc.) with refresh every few seconds
- Custom stack – events → queue → aggregation → Redis/DB → API + SSE/WebSocket → frontend
Best practices
- Don’t poll the DB every second – use event stream and pre-aggregation
- Limits – how much data you show (e.g. last 100 events, last hour)
- Fallback – on connection drop (SSE/WS) – auto reconnect or fall back to polling
- Permissions – real-time data is often sensitive; same auth rules as for reports
Checklist
- Decide which metrics must be real-time
- Choose: polling vs SSE vs WebSocket
- Event pipeline and aggregation (if not “raw” logs)
- Cache / read layer for dashboard
- Test with many concurrent users
FAQ
Is GA4 “real-time” really live?
Yes, but with usually 1–2 minute delay and limited dimensions. Often enough for “what’s happening now”; for second-level events (e.g. app errors) you need your own pipeline.
Does real-time always need WebSockets?
No. SSE or even polling every 5–10 s is enough in many cases. WebSockets are for two-way interaction or very high update frequency.
How to avoid overloading the DB with a real-time dashboard?
Aggregate in a pipeline (worker reading from queue) and write results to Redis or a separate table. Dashboard reads only pre-aggregated values, not computed live on every refresh.