Cómo comparar el tráfico en vivo de Astrina con los registros del servidor
Comparar el tráfico en vivo de Astrina con los registros del servidor parece sencillo hasta que aparece el primer desajuste. Un informe dice 18 visitas. El registro muestra 24 solicitudes. Esa diferencia suele tener una razón, y muchas veces la razón es aburrida en el mejor sentido: una redirección, un bot, un proxy o una marca de tiempo desplazada 60 segundos.
El objetivo no es hacer que ambos números coincidan a cualquier precio. El objetivo es que la comparación sea lo bastante honesta como para poder confiar en ella. Si quieres saber cómo comparar tráfico en vivo de Astrina con logs del servidor, empieza por reducir el problema antes de discutir con los números.
1. Confirma el alcance del registro del servidor antes de comparar
Primero elige los archivos de registro exactos. Muchos equipos mezclan tráfico de producción, staging y vista previa en una sola hoja de cálculo y luego se preguntan por qué Astrina muestra un patrón y el servidor otro. Mantén un solo sitio, un solo entorno y un solo tramo de tráfico. Eso significa nombrar el host, la aplicación y la fuente del registro en texto plano antes que nada.
Si tu configuración del servidor escribe varios archivos al día, anota la regla de rotación. Si tienes registros separados para el borde del CDN y el servidor de origen, elige una ruta y úsala en la primera pasada. Un alcance limpio hace que el resto del trabajo sea más pequeño. Un alcance confuso hace que cada desajuste parezca sospechoso.
Un ejemplo práctico: compara solo www.example.com en producción, solo solicitudes de página y solo las últimas 24 horas. No añadas tráfico de API, comprobaciones de estado ni URLs de administración en la misma comparación. Esas son cosas distintas.
2. Elige una ventana de tiempo exacta y normaliza las marcas temporales
El tráfico en vivo de Astrina funciona mejor cuando la ventana es exacta. Los registros del servidor funcionan mejor cuando la ventana es exacta. Usa el mismo minuto de inicio y el mismo minuto de fin en ambos lados, no “más o menos al mediodía” ni “en algún momento después de comer”. El corte a nivel de minuto importa porque una solicitud en el borde puede cambiar el recuento.
Usa una sola zona horaria para ambas partes. Si Astrina muestra UTC y tus registros del servidor están en hora local, la comparación fallará antes de empezar. Convierte las marcas temporales del registro una vez y luego mantenlas en ese formato durante todo el análisis. Un desfase de 15 minutos puede crear un pico falso. Un desfase de 1 hora puede hacer que los datos parezcan rotos.
Hay una regla pequeña que ahorra tiempo: nunca compares una ventana móvil de 5 minutos de Astrina con una extracción de registro de un día natural. Suena obvio. La gente todavía lo hace. Elige una ventana, escríbela y úsala en todas partes.
3. Filtra los registros del servidor hasta quedarte con solicitudes de páginas humanas
Los registros del servidor contienen de todo, y ese es el problema. Imágenes, CSS, paquetes de JavaScript, solicitudes de favicon, precargas y visitas de rastreadores aparecen junto a las visitas de páginas. Astrina normalmente cuenta visitas de páginas, así que el registro debe reducirse al mismo tipo de solicitud.
Primero elimina los recursos estáticos. Luego quita comprobaciones de estado, sondas de disponibilidad, endpoints de administración y herramientas internas. Si tu balanceador llama a /health cada minuto, esas líneas pueden alterar los totales rápidamente. Una página como /pricing no debería compararse con 400 solicitudes de recursos y tres pings de monitorización.
El filtrado de bots también merece atención. Algunos bots parecen humanos durante unos segundos, y algunos navegadores parecen robóticos por su user agent. No dependas de una sola señal. Usa una combinación de la ruta solicitada, el user agent y rangos conocidos de IP internas cuando puedas. Si tu registro incluye una marca de “bot” de un WAF o proxy inverso, conserva esa etiqueta. Ayuda más adelante.
4. Mapea los campos de Astrina con los campos del registro
Crea un mapa simple de campos antes de intentar emparejar registros. Astrina puede mostrar una marca temporal, la ruta de la página, el referente y un identificador parecido al de sesión. El registro puede mostrar la línea de solicitud en bruto, el código de estado, el user agent y la dirección IP. No son lo mismo y no deberían tratarse como si lo fueran.
Haz una tabla de dos columnas en papel o en una hoja de cálculo. A la izquierda: campo de Astrina. A la derecha: campo del registro. La marca temporal se mapea con la marca temporal, la ruta con la ruta de la solicitud, el referente con la cabecera de referer y el user agent con la cadena de user agent. Los identificadores parecidos a sesión son más complicados, porque el registro del servidor puede no tener ninguno. Eso no es un fallo. Es solo una limitación.
| Campo de Astrina | Campo de registro más cercano | Notas |
|---|---|---|
| Marca temporal | Hora de la solicitud | Convierte primero a una sola zona horaria |
| Ruta de la página | Ruta de la URL | Elimina las cadenas de consulta para agrupar |
| Referente | Cabecera Referer | Puede faltar o estar recortado |
| User agent | Cadena de user agent | Útil para comprobar bots |
No esperes que cada campo de Astrina tenga un campo equivalente en el registro. Algunos valores se infieren. Algunos se modelan. Algunos simplemente no están presentes en el registro del servidor. Por eso importa el mapa: te dice dónde la comparación directa es posible y dónde solo es aproximada.
5. Reconcilia el tráfico por la ruta de URL, no por la línea de solicitud en bruto
Las líneas de solicitud en bruto son ruidosas. Una visita a /docs puede aparecer como /docs, /docs/ o /docs?utm_source=newsletter. Si comparas esas cadenas literalmente, dividirás una sola página en tres. Astrina quizá ya normalice parte de esto. Tu registro probablemente no lo haga.
Usa rutas canónicas. Agrupa todas las variantes bajo la misma ruta de página antes de comparar los recuentos. Elimina las cadenas de consulta si no forman parte de la identidad de la página. Unifica las barras finales donde el sitio trate ambas versiones como la misma página. Si hay redirecciones, cuenta el destino final, no el primer salto.
Este paso suele revelar una sorpresa. Una página con 50 visitas de Astrina puede mostrar 63 entradas en el registro porque 13 solicitudes llegaron primero a la versión no canónica y luego se redirigieron. Eso no es un error en el tráfico. Es un problema de rutas. Corrige la regla de agrupación antes de cambiar la interpretación.
6. Comprueba desajustes causados por caché, proxies o CDN
Las capas intermedias cambian lo que llega al servidor de origen. Un CDN puede responder a la solicitud antes de que el origen llegue a verla. Un proxy puede reescribir cabeceras. Un acierto de caché puede servir una página a un usuario sin dejar una línea correspondiente en el origen. Eso significa que Astrina puede ver una visita mientras el registro del servidor permanece en silencio.
Lo contrario también puede ocurrir. El registro del origen puede anotar una solicitud que Astrina nunca cuenta porque el navegador no terminó de cargar la página, el script fue bloqueado o la solicitud ocurrió antes de que se ejecutara el código de seguimiento. Una página de prueba rápida puede dejar esto claro. Abre la página en un navegador, inspecciona la pestaña de red y comprueba si la solicitud de seguimiento se dispara antes de que la página termine de cargar.
Si usas un CDN, revisa si la fuente del registro es el borde o el origen. Son registros distintos. Una respuesta 304, una respuesta HTML en caché o un objeto obsoleto en el borde pueden producir diferencias falsas. Aquí es donde una nota breve en tu hoja de comparación te ahorra una hora más tarde.
Para los equipos que configuran el rastreador por primera vez, la ruta de instalación también importa. La configuración del agente es más fácil de verificar si sigues el mismo método de despliegue usado en producción, por eso muchos equipos guardan la guía de configuración junto al script de exportación de registros en su runbook.
7. Usa un registro breve de discrepancias para clasificar cada diferencia
No dejes los desajustes como celdas rojas anónimas. Escribe un registro de discrepancias con una línea por cada diferencia. Da a cada línea una categoría. Al principio suelen bastar cinco categorías: ruido de bots, cobertura de registro faltante, ingesta retrasada, clics duplicados y problema de normalización de rutas.
Este es un formato simple: ruta de la página, recuento de Astrina, recuento del registro, tamaño de la diferencia, categoría y nota. Esa nota debería mencionar una causa concreta, no una sensación. “El CDN sirvió HTML en caché” es útil. “Se ve raro” no lo es. Si una diferencia se repite en tres páginas, es una pista. Si aparece una sola vez, sigue siendo una pista, solo que más pequeña.
Un equipo puede descubrir que una diferencia de 12 solicitudes se debe a una entrega retrasada de los registros. Otro puede encontrar que una extensión del navegador bloquea el script de seguimiento en dispositivos internos. Un tercero puede aprender que el servidor escribe líneas duplicadas al reintentar. Las categorías evitan que trates cada desajuste como si fuera el mismo tipo de fallo.
Si quieres un marco operativo más profundo para este trabajo, astrina para equipos internos de producto que hacen seguimiento puede ser un buen complemento, especialmente cuando una discrepancia de tráfico resulta estar vinculada a un despliegue.
8. Vuelve a ejecutar la comparación con una muestra pequeña antes de escalar
Empieza con una página o un día. No con diez páginas. No con un mes entero. Una muestra obliga a que las reglas queden explícitas, y eso es bueno. Si la muestra incluye solo /pricing, puedes revisar a mano cada desajuste y ver si el método se sostiene.
Busca estabilidad antes que amplitud. Si el mismo filtro, la misma regla de ruta y la misma ventana de tiempo producen la misma respuesta dos veces, amplía a una segunda página. Si los números cambian al añadir otro día, detente y comprueba si hubo un despliegue, un cambio de caché o una rotación de registros en medio. Una muestra pequeña es más rápida de corregir que una grande.
Hay una disciplina útil aquí: cambia solo una variable cada vez. Pasa de una página a tres páginas, o de un día a dos días, pero no ambas cosas a la vez. Si no, no sabrás qué cambio rompió la coincidencia. Suena lento. Es más rápido que retroceder por 40 filas de suposiciones incorrectas.
Los equipos que migran desde otra herramienta de analítica suelen ver el mismo patrón durante el trabajo de transición. Si ese es tu caso, cómo migrar desde plausible es una referencia práctica que conviene tener abierta mientras verificas la primera muestra contra los registros.
Qué comprobar cuando los números siguen sin cuadrar
Si la comparación sigue pareciendo incorrecta después de los ocho pasos anteriores, inspecciona tres cosas en este orden: la fuente del registro, la regla de ruta y la ventana de tiempo. No vayas directo al script de seguimiento. Un número sorprendente de “errores de seguimiento” en realidad son errores de extracción de registros. Otra causa común es una redirección pasada por alto de /page a /page/.
Comprueba también si la sesión del navegador termina antes de que se complete la solicitud de seguimiento. Las conexiones móviles son más frágiles que las de escritorio. Una página puede cargarse visualmente mientras la llamada de analítica se cancela. Eso deja a Astrina con menos visitas que el registro del servidor. Lo contrario puede ocurrir cuando el navegador reintenta una solicitud y el servidor cuenta ambos intentos.
Un detalle más: si tu sitio tiene una página de mantenimiento o un modo de mantenimiento, trata ese tráfico por separado. Un evento de mantenimiento cambia tanto el comportamiento del usuario como la forma del registro. Si necesitas una referencia complementaria para esa situación, qué hacer cuando Astrina uptime puede ayudar a encuadrar el incidente antes de compararlo con los registros.
Las comparaciones más sólidas son pequeñas, documentadas y repetibles. Un alcance limpio, una sola ventana temporal, solicitudes de página filtradas y rutas canónicas suelen explicar la mayor parte de la diferencia. La diferencia restante es donde vive el trabajo útil. Cuando necesites comparar visitas de Astrina con registros del servidor, este método reduce el ruido y deja claro qué merece una revisión real.
