Internet está plagada de ejemplos de sitios web cuidadosamente diseñados en los que, sin embargo, los usuarios se pierden, no encuentran aquello que buscan, existiendo en la web o peor aún, buscan algo que debiera estar y no está. 

Por otra parte los gestores del sitio web desconocen en muchos casos lo que hacen sus usuarios dentro de la web así como si encuentran lo que buscan, si buscan conceptos que no están en la web pero que podrían estar o si simplemente se pierden y se aburren abandonando el sitio. Sin conocer el impacto que tienen nuestra campañas de marketing en un website de comercio electrónico, difícilmente lo podremos hacer progresar en la dirección adecuada. 

En los artículos 65, 66 y 67 comentamos ya sobre algunas de las soluciones para analizar los logfiles de nuestra web, monitorizar el tráfico en nuestra web y la importancia de la visualización para interpretar los resultados.  Por aquel entonces (noviembre de 2001) eran pocas las aplicaciones gráficas que mostraban los resultados del análisis de los logfiles. Hoy esto todavía es así.

La estructura de un logfile es extremadamente simple. Cada vez que alguien descarga un elemento de la web, como por ejemplo una página o una imagen, el servidor escribe una línea en el fichero histórico o logfile. Esta línea puede adoptar uno entre varios formatos pero puede ser de esta forma:

IP	Identity check	ID de usuario	Fecha y hora	Método recurso  y protocolo	Status	Tamaño	Referrer	Agente (Browser, S.O., etc)
127.0.0.1	-	frank	[10/Oct/2005:13:55:36 -0700]	"GET /apache_pb.gif HTTP/1.0"	200	2326	"http://www.example.com/start.html"	"Mozilla/4.08 [en] (Win98; I ;Nav)"

No vamos a entrar en el detalle de lo que significa cada elemento ni en las diversas variantes de formatos. Para ello podemos consultar el formato del popular servidor Apache o las especificaciones del W3C.

Lo importante es que a pesar de lo elemental que es, el estudio estadístico de la agregación de las muchas peticiones que hacen los navegadores de los usuarios al servidor permite conocer una gran cantidad de información derivada de estas simples líneas. Entre ellas, al menos aparentemente, se puede conocer el número de páginas servidas por día, semana, mes o unidad de tiempo que se quiera, los sitios que apuntan a nuestra web y nos redirigen tráfico (referrer), las palabras que se buscan más habitualmente en nuestra web y un largo etcétera.

Si nos paseamos por las especificaciones de muchos analizadores de logfiles de un servidor web veremos que conocer el número de visitas únicas, de visitantes, cuánto tiempo han estado en la web o incluso en una página parece pan comido para estos productos. 

Nada más lejos de la realidad. Mucha de esta información es de fiabilidad reducida debida principalmente a dos causas, entre muchas otras (véase la discusión sobre qué se puede conocer y qué no analizando un logfile)

• HTML es un "stateless protocol". Cada petición resulta en una nueva conexión independiente que se abre y se cierra para la ocasión y no se puede relacionar de un modo fiel con otra hecha por la misma dirección IP. Aun más, si la IP es dinámica, es decir si la pueden usar distintos usuarios. 
  
  Muchas "visitas" se crean con un "generador de sesiones" (sessionizer) que encuentra todas las entradas que pertenecen a una misma dirección IP y las considera parte de una misma sesión si todas están alejadas entre sí menos de un cierto lapso de tiempo.
  
  Es imposible asegurar que todas pertenecen a la misma visita de la misma persona. Por lo mismo es imposible saber cuanto tiempo ha estado una página siendo vista ni cuál ha sido la secuencia real de su trayectoria dentro de nuestra web.
  
  
• Muchas páginas se reciben desde caches de servidores intermedios, sin que nuestro servidor llegue a enterarse nunca de que alguien ha visto esa página guardada en otro servidor. El uso de caches en Internet no sólo es conveniente sino la única manera de no colapsar ante un tráfico creciente, pero limita nuestro conocimiento del uso real de nuestra web. 
  
  Así pues, es imposible conocer de verdad cuantas páginas han sido vistas.

En resumen. Atendiendo simplemente al análisis de un logfile, no se puede conocer el número de visitantes, no se puede determinar cuantas visitas ha habido, no se puede conocer la identidad de los visitantes ni se pueden establecer fidedignamente las rutas que han seguido. Tampoco se puede saber cuanto tiempo han estado usando nuestra web.

Sin embargo ello no significa que las informaciones que se derivan del análisis de logfiles, aunque incompletas, no sean valiosas. 

• Para empezar, a falta de un sitio web en el que obliguemos a nuestros usuarios a identificarse mediante un "login" y un "password", la información de los logfiles es probablemente todo lo que tenemos.
  
  
• Aunque la información sea incompleta, se puede llegar a una gran cantidad de conclusiones estudiando un logfile. Por ejemplo.
  
  
  • Qué conceptos buscan nuestros usuarios que no están en la web
    
    
  • Qué conceptos que sí que están no son encontrados.
    
    
  • Qué zonas de nuestra web registran más actividad.
    
    
• La aparición de patrones regulares y repetitivos en los caminos que encuentran los "sesionizadores" suele corresponder a patrones reales de comportamiento.

En definitiva, no se puede vender la idea de que los analizadores de logfiles encuentran visitas  y visitantes "unicos", trayectorias de los mismos y hasta el sistema operativo que usan, como nos quieren hacer creer algunos fabricantes.

Sin embargo si se es consciente de lo que nos dice un logfile y de sus limitaciones, disponemos de herramientas poderosas para comprender nuestro sitio web y el uso que de el hacen nuestros usuarios, abriendo una puerta a las decisiones que pueden mejorar su rendimiento.

Enlaces de este artículo: