Ver quantas pessoas estão navegando pelo seu site neste exato momento parece funcionalidade de painel premium, mas dá para montar com peças que você já tem. A parte interessante não é o contador: é interpretar o sinal sem se enganar. Vamos à montagem real.
Passo 1: escolha a fonte de dados antes de mexer em qualquer coisa
Há três caminhos e eles não são intercambiáveis:
- Tag do provedor de analytics (GA4, Matomo, Plausible). Zero desenvolvimento, mas a latência de agregação faz com que o “tempo real” do GA4 não seja instantâneo: segundo a documentação oficial do Google, os relatórios em tempo real refletem atividade dos últimos 30 minutos e os dados podem demorar a se consolidar.
- Logs do servidor. É o dado mais fiel, inclui bots e downloads que o JavaScript nunca vê. Requer acesso ao log e um parser.
- Streaming a partir do próprio site (WebSocket ou Server-Sent Events). Controle total, mas é você quem assume o custo de infraestrutura.
Para uma pequena empresa com WordPress, o caminho 1 é suficiente. Para auditar rastreamento de bots ou picos de tráfego anômalos, o 2 é obrigatório.
Passo 2: ative a visualização em tempo real no GA4 e confira
- Entre em Administrar → Fluxos de dados e confirme que a tag está disparando (extensão de navegador ou o relatório DebugView).
- Abra Relatórios → Tempo real e navegue você mesmo por uma URL com o parâmetro ?utm_source=test.
- Verifique se você aparece com essa origem. Se não aparecer, o problema quase sempre está em uma condição de consentimento que bloqueia a tag, não na tag.
O erro que quase todo mundo comete na primeira vez
Um caso típico: você instala o snippet no cabeçalho, o contador de usuários ativos mostra 0 e você entra em pânico. Na realidade, o bloqueio de cookies rejeitou o script ou um plugin de cache está servindo HTML com a tag duplicada e desativada. Antes de reinstalar qualquer coisa, abra o console do navegador e procure a requisição para collect ou para o endpoint da sua ferramenta. Se não aparecer, o problema é de carregamento; se aparecer com 204, a medição funciona e a falha está na filtragem interna.
Passo 3: monte um painel próprio com os logs (opcional, mas revelador)
Se você quer ver requisições por segundo sem depender de terceiros, um comando de terminal basta para começar:
tail -f /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
Isso te dá os IPs com mais requisições na janela que você deixar aberta. Serve para detectar um scraper agressivo em segundos, mas não distingue usuários de bots nem sessões: para isso você precisa de agregação por janelas de tempo e um painel tipo Grafana lendo o log.
O que o tempo real não vai te dizer
Aqui convém ser honesto: o tráfego ao vivo não serve para medir conversões nem atribuição. Um usuário que compra pode ter chegado há três dias por outro canal. Também não distingue bem entre uma visita humana e um bot com user-agent falsificado. E se o seu site tiver muito tráfego, atualizar a cada segundo consome recursos e mostra ruído, não tendência.
Segundo estudos do setor de analytics web, uma parte relevante do tráfego classificado como “direto” nos painéis ao vivo corresponde a tráfego interno, ferramentas de monitoramento e links mal etiquetados. Filtre o seu próprio IP e o da sua equipe antes de tirar conclusões.
Checklist de configuração mínima
- Tag carregando em todos os templates, incluindo o de agradecimento.
- Filtro de IP interno ativo.
- Evento personalizado para cliques em CTA, visível também no relatório em tempo real.
- Alerta (email ou Slack) quando o fluxo de dados parar por mais de 30 minutos: a queda da tag é mais frequente que a queda do servidor.
- Revisão semanal do log para comparar com a ferramenta: se divergirem muito, há bots ou bloqueio de scripts.
Com isso você tem monitoramento ao vivo funcional e, acima de tudo, sabe quando desconfiar do que vê.