Vedere quante persone stanno navigando sul tuo sito in questo esatto momento sembra una funzionalità da pannello premium, ma si può realizzare con pezzi che hai già. La parte interessante non è il contatore: è interpretare il segnale senza ingannarti. Andiamo al montaggio reale.
Passo 1: scegli la fonte di dati prima di toccare qualsiasi cosa
Ci sono tre vie e non sono intercambiabili:
- Tag del fornitore di analytics (GA4, Matomo, Plausible). Zero sviluppo, ma la latenza di aggregazione fa sì che il “tempo reale” di GA4 non sia istantaneo: secondo la documentazione ufficiale di Google, i report in tempo reale riflettono l’attività degli ultimi 30 minuti e i dati possono richiedere tempo per consolidarsi.
- Log del server. È il dato più fedele, include bot e download che il JavaScript non vede mai. Richiede accesso al log e un parser.
- Streaming dal sito stesso (WebSocket o Server-Sent Events). Controllo totale, ma sei tu ad assumerti il costo dell’infrastruttura.
Per una PMI con WordPress, la via 1 è sufficiente. Per verificare il crawling dei bot o picchi di traffico anomali, la 2 è obbligatoria.
Passo 2: attiva la vista in tempo reale in GA4 e verificala
- Vai su Amministrazione → Flussi di dati e conferma che il tag stia scattando (estensione del browser o il report DebugView).
- Apri Report → Tempo reale e naviga tu stesso su un URL con parametro ?utm_source=test.
- Verifica di apparire con quella fonte. Se non appari, il problema quasi sempre sta in una condizione di consenso che blocca il tag, non nel tag.
L’errore che quasi tutti commettono la prima volta
Un caso tipico: installi lo snippet nell’header, il contatore degli utenti attivi mostra 0 e vai nel panico. In realtà il blocco dei cookie ha rifiutato lo script oppure un plugin di cache sta servendo HTML con il tag duplicato e disattivato. Prima di reinstallare qualsiasi cosa, apri la console del browser e cerca la richiesta a collect o all’endpoint del tuo strumento. Se non compare, il problema è di caricamento; se compare con 204, la misurazione funziona e il guasto è nel filtraggio interno.
Passo 3: realizza un pannello tuo con i log (opzionale ma rivelatore)
Se vuoi vedere richieste al secondo senza dipendere da terzi, un comando da terminale basta per iniziare:
tail -f /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
Questo ti dà gli IP con più richieste nella finestra che lasci aperta. Serve per individuare uno scraper aggressivo in pochi secondi, ma non distingue utenti da bot né sessioni: per quello ti servono aggregazioni per finestre temporali e un pannello tipo Grafana che legga il log.
Cosa non ti dirà il tempo reale
Qui conviene essere onesti: il traffico in tempo reale non serve per misurare conversioni né attribuzione. Un utente che acquista può essere arrivato tre giorni fa da un altro canale. Inoltre non distingue bene tra una visita umana e un bot con user-agent falsificato. E se il tuo sito ha molto traffico, aggiornare ogni secondo consuma risorse e ti mostra rumore, non tendenza.
Secondo studi del settore dell’analytics web, una parte rilevante del traffico classificato come “diretto” nei pannelli in tempo reale corrisponde a traffico interno, strumenti di monitoraggio e link mal etichettati. Filtra il tuo IP e quello del tuo team prima di trarre conclusioni.
Checklist di configurazione minima
- Tag in caricamento su tutti i template, incluso quello di ringraziamento.
- Filtro IP interno attivo.
- Evento personalizzato per i clic sui CTA, visibile anche nel report in tempo reale.
- Avviso (email o Slack) quando il flusso di dati si interrompe per più di 30 minuti: la caduta del tag è più frequente della caduta del server.
- Revisione settimanale del log per confrontarlo con lo strumento: se divergono molto, ci sono bot o blocco degli script.
Con questo hai un monitoraggio in tempo reale funzionante e, soprattutto, sai quando diffidare di ciò che vedi.