Analytics server-side vs JavaScript analytics.

La diferencia de arquitectura

El analytics JavaScript funciona así:

1. El navegador del visitante solicita /page.html
2. El servidor retorna HTML conteniendo <script src="ga.js">
3. El navegador parsea, descarga ga.js, ejecuta
4. El script dispara un beacon a los servidores de GA con metadatos de la visita

Ese pipeline falla cuando:

• El "visitante" es un script que no ejecuta JS (bots, crawlers, atacantes)
• El visitante usa uBlock Origin / Ghostery / similar (bloquea el dominio de GA)
• El visitante tiene conexión que da timeout antes de que ga.js cargue
• La request nunca retornó HTML (responses de REST API, hits de imagen, descarga de archivo)
• JavaScript da error silencioso antes de que el beacon se dispare

El analytics server-side funciona diferente:

1. La request del visitante golpea tu servidor (Apache / Nginx / PHP-FPM)
2. Tu código de aplicación (o un beacon server-side) captura la request y reenvía metadatos a la capa de analytics
3. La captura ocurre independientemente de lo que el visitante haga después

Ese pipeline no le importa el JavaScript, los ad-blockers, los quirks del navegador o el tipo de response. Si la request golpeó tu servidor, fue contada.

Qué captura cada capa

SysWP Radar usa las dos capas: pixel JavaScript para visitantes humanos (Web Vitals + UTM + engagement) Y beacon server-side (vía plugin PHP en WordPress, o snippet de una línea en cualquier plataforma) para todo lo que JS no ve. Las dos son complementarias, no competidoras.

Cuándo basta con JavaScript-only

• Solo te importan los funnels de conversión humanos (checkout de e-commerce, signup de SaaS)
• Aceptas ignorar el 30-60% del tráfico total
• No corres un sitio de contenido que les importe a los AI crawlers
• No estás en WordPress (la mayoría de los ataques apuntan a WP específicamente)
• No necesitas saber qué bots se están comiendo tu ancho de banda

En ese caso, Plausible o Fathom son geniales. Son enfocados, rápidos, privacy-first, y hacen su trabajo bien dentro del scope.

Cuándo necesitas analytics server-side

• Sitio de contenido / blog / docs: los AI crawlers ahora son una porción significativa del "tráfico". Quieres optimizar para citación en respuestas de ChatGPT / Claude / Perplexity. No puedes optimizar lo que no mides.
• Sitio WordPress: /wp-login.php, /xmlrpc.php, /wp-json/ son superficies de ataque constantes. El analytics JS no ve ningún ataque. Server-side captura todos.
• E-commerce / SaaS con API pública: las requests API (GET /api/products) no ejecutan JS. La captura server-side muestra qué endpoints son llamados, por quién, con qué frecuencia.
• News / publicación: los lectores RSS (Feedly, Inoreader, NewsBlur) consumen /feed/ sin navegador. Te quedas totalmente ciego para tus suscriptores más fieles con JS-only.
• Equipos preocupados por seguridad: scanners golpeando /.env, /.git/config, probes de vulnerabilidad, intentos de inyección sqlmap — invisibles para el analytics JS, visibles en la capa del servidor.

Cómo SysWP Radar implementa las dos capas

Una plataforma, dos capas de captura:

1. Pixel JavaScript (una etiqueta <script> async, ~2 KB) — atiende sesiones humanas en navegador. Captura Web Vitals usando PerformanceObserver, params UTM, scroll, rage clicks, errores JS. Corre en cualquier plataforma.
2. Beacon server-side — para WordPress, es el plugin SysRadar que se engancha en shutdown y envía requests vía fastcgi_finish_request() + blocking=false (cero latencia al visitante). Para no-WP, un webhook HTTP o shipper de log de Apache.

El classifier (modelo de scoring server-side estilo Bayesiano + reglas curadas) categoriza cada request capturada en 9 categorías en tiempo real: humanos, bots verificados, AI crawlers, SEO crawlers, lectores RSS, health checks, WP interno, atacantes, desconocidos. El dashboard muestra agregados, drillable, con timeseries horaria.

Preguntas frecuentes