Analytics server-side vs JavaScript analytics.

A diferença de arquitetura

Analytics JavaScript funciona assim:

1. Navegador do visitante requisita /page.html
2. Servidor retorna HTML contendo <script src="ga.js">
3. Navegador parseia, baixa ga.js, executa
4. Script dispara um beacon pros servidores do GA com metadados da visita

Esse pipeline falha quando:

• O "visitante" é um script que não roda JS (bots, crawlers, atacantes)
• O visitante usa uBlock Origin / Ghostery / similar (bloqueia o domínio do GA)
• O visitante tem conexão que dá timeout antes do ga.js carregar
• A request nunca retornou HTML (responses de REST API, hits de imagem, download de arquivo)
• JavaScript dá erro silencioso antes do beacon disparar

Analytics server-side funciona diferente:

1. Request do visitante bate no seu servidor (Apache / Nginx / PHP-FPM)
2. Seu código aplicação (ou um beacon server-side) captura a request e encaminha metadados pra camada de analytics
3. Captura acontece independente do que o visitante faça depois

Esse pipeline não liga pra JavaScript, ad-blockers, quirks do browser ou tipo de response. Se a request bateu no seu servidor, foi contada.

O que cada camada captura

O SysWP Radar usa as duas camadas: pixel JavaScript pra visitantes humanos (Web Vitals + UTM + engagement) E beacon server-side (via plugin PHP no WordPress, ou snippet de uma linha em qualquer plataforma) pra tudo que JS não vê. As duas são complementares, não competidoras.

Quando JavaScript-only basta

• Você só se preocupa com funnels de conversão humanos (checkout de e-commerce, signup de SaaS)
• Você aceita ignorar 30-60% do tráfego total
• Você não roda um site de conteúdo que AI crawlers se importem
• Você não está no WordPress (a maioria dos ataques mira WP especificamente)
• Você não precisa saber quais bots estão comendo sua banda

Nesse caso, Plausible ou Fathom são ótimos. São focados, rápidos, privacy-first, e fazem o trabalho deles bem dentro do escopo.

Quando você precisa de analytics server-side

• Site de conteúdo / blog / docs: AI crawlers agora são parcela significativa do "tráfego". Você quer otimizar pra citação em respostas do ChatGPT / Claude / Perplexity. Não dá pra otimizar o que não mede.
• Site WordPress: /wp-login.php, /xmlrpc.php, /wp-json/ são superfícies de ataque constantes. Analytics JS não vê nenhum ataque. Server-side captura todos.
• E-commerce / SaaS com API pública: requests API (GET /api/products) não rodam JS. Captura server-side mostra quais endpoints são chamados, por quem, com que frequência.
• News / publicação: leitores RSS (Feedly, Inoreader, NewsBlur) consomem /feed/ sem browser. Você fica totalmente cego pros seus assinantes mais fiéis com JS-only.
• Equipes preocupadas com segurança: scanners batendo em /.env, /.git/config, probes de vulnerabilidade, tentativas de injeção sqlmap — invisíveis pra analytics JS, visíveis na camada server.

Como o SysWP Radar implementa as duas camadas

Uma plataforma, duas camadas de captura:

1. Pixel JavaScript (uma tag <script> async, ~2 KB) — atende sessões humanas em browser. Captura Web Vitals usando PerformanceObserver, params UTM, scroll, rage clicks, erros JS. Roda em qualquer plataforma.
2. Beacon server-side — pra WordPress, é o plugin SysRadar que hooka em shutdown e envia requests via fastcgi_finish_request() + blocking=false (zero latência ao visitante). Pra não-WP, um webhook HTTP ou shipper de log do Apache.

O classifier (modelo de scoring server-side estilo Bayesiano + regras curadas) categoriza cada request capturada em 9 categorias em tempo real: humanos, bots verificados, AI crawlers, SEO crawlers, leitores RSS, health checks, WP interno, atacantes, desconhecidos. O dashboard mostra agregados, drillable, com timeseries horária.

Perguntas frequentes