El problema. ¡Faltan datos en mi analítica!

Detecto un conjunto de páginas bastante amplio en las que no se están enviando los datos del datalayer instalado en WordPress, que hace llegar categorías, parámetros y demás información de cada página.

detección de páginas sin categoría asignada

No se ve bien, pero en la imagen aparecen páginas sin caregorizar, con guinoes; y que el 13,15% de las visitas de ese período, 1196 concretamente, llegan de esta forma a la herramienta analítica. Y en la parte inferior de la imagen se puede ver la “URL” de la página. Lo pongo entre comillas porque dónde irían las barras inclinadas aparece un punto en su lugar.

Esta sería su análoga en el formato habitual, enviada de forma correcta:

Formato normal de nombre página en la analítica

En la herramienta analítica que se está empleando, Webtrekk Analytics (ahora Mapp Intelligence), el formato con puntos es el formato predefinido.

Por ese motivo y por que los datos superiores en el árbol de la primera imagen aparecen sin valor, con un guion (-), es por lo que detectamos que estas páginas se están enviando forma predefinida y sin la capa de datos adicional, también conocido como datalayer, lo cual es un problema debido a que se genera un agujero negro en los datos.

Esta clase de problemas suelen ser derivados por cuestiones de timming, es decir, de los tiempos que tardan los navegadores en cargar cada uno de los elementos de la página y de la disponibilidad de los recursos en el momento que otros los necesitan.

Aplicado a este ejemplo quiere decir que el píxel de la herramienta analítica “se cansa” de esperar al datalayer y envía la página de forma automática.

Ante esto hay varias posibles soluciones y formas de atacar.

  1. Configurar el pixel para que espere más tiempo. En el caso de Mapp Intelligence, se puede indicar que el envío de las páginas siempre sea manual y entonces esperará siempre a la carga de los datos.

Esta solución no es del todo óptima, porque cuando queramos hacer otras cosas en tiempo real en la misma página, como obtener una audiencia para modificar el contenido según el usuario conectado, la llegada de esta información se retrasará más de lo normal, generando problemas de flickering o retrasos en los tiempos de carga de los elementos que se sustituyen.

  1. Tratar de hacer que el datalayer se cargue antes. En el caso de esta web está en el footer. Seguramente este es el motivo por el que se genera este problema, ahora veremos por qué.
  2. Hacer adaptaciones en el código para los tipos de usuario que generan conflicto. Para esto debemos…

Tirar del hilo. Caso práctico de analítica para encontrar la solución

Con herramientas de analítica potentes, podemos visualizar datos de varias dimensiones en un mismo informe. Esto es genial para casos como este.

El objetivo es detectar si hay algo en común en los casos en los que no se envían los datos a tiempo. Para ello, he agregado las 4 dimensiones que se ven en la primera imagen, con las que podemos ver el tipo de página (ámbito), la categoría del blog de la que forma parte cada página, las URLs de las páginas y los navegadores desde los que se accedió.

Veamos parte del informe desplegado, concretamente algunas de las páginas que generan el problema:

Están ordenadas por número de impresiones y podemos observar cómo se repite Chrome 38 y otros navegadores desactualizados. Si continuáramos desplegando las sucesivas páginas veríamos que se repite el patrón.

Comparemos ahora con páginas que están entrando con normalidad, con todos los datos del datalayer:

Ya tenemos el patrón. Los navegadores obsoletos son el problema, y más particularmente la versión 38 de Chrome, cuando actualmente estamos ya por la 70 y pico.

Modificando la última de las dimensiones del análisis podemos obtener más información útil, como los países o dispositivos desde los que se generan estas visitas.

A raíz de ello aparece nueva información interesante, ya que, mientras lo normal en este sitio web es recibir visitas desde dispositivos de escritorio. Veamos las visitas normales:

En ellas, la mayoría del tráfico proviene de dispositivos de escritorio, como decía, normal en este sitio web debido a su contenido. Usuarios que buscan información sobre cómo hacer algo relacionado con el marketing online o el desarrollo web, normalmente cuando están trabajando o estudiando.

Observemos lo que ocurre con las anómalas:

La mayor parte procede de Smartphone, lo cual refuerza la los datos anteriores y podemos concluir que de trata de usuarios con dispositivos Smartphone sin actualizar o algo obsoletos.

También está la opción de que sea tráfico producido por algún tipo de robot o crawler (rastreador). Veamos lo que ocurre si echamos un vistazo las métricas Visitas, Visitantes, tiempo medio de visita e impresiones por visita, agregando además la dimensión Origin Type, que nos indica la procedencia del tráfico:

Los robots típicamente producen visitas de 0 segundos de duración y un 100% de tasa de rebote, cosa que en este caso no es así porque de lo contrario las Impresiones por visita (última columna, páginas vistas por visita) tendrían el valor 1.

Por otro lado, las visitas y visitantes sí coinciden, es decir, que cada visitante ha realizado exactamente una visita y además está entrando en tráfico directo (No referrer). Estos dos datos sí dan a pensar que sean robots.

Ya tenemos información suficiente para trabajar.

Lo primero será activar el log en la herramienta analítica para ver más información a cerca de esas conexiones y si no podemos comprobar que esas visitas sean robots, habrá que investigar un poco sobre esa versión de Google Chrome 38.