Cuando en cualquier proyecto estamos examinando el comportamiento de los usuarios es inevitable caer en la necesidad de examinar el flujo de páginas que siguen los usuarios durante sus visitas. Para esto hay muchas herramientas especializadas en el mercado: mapas de clicks, seguimientos de visitas, mapas de flujos, pero la realidad es que la mayor parte de las veces nos encontramos con que disponemos de Google Analytics y ahí tenemos un precioso informe de flujo de páginas que es muy bonito, pero con tanta información que cuesta seguirlo y sobretodo llevarlo luego a un cuadro de mando o informe de cualquier tipo.

En este post voy a comentar como trabajar con flujos de páginas vistas en el complejo mundo de las dimensiones y las métricas de Google Analytics, no solo ya por si puedo ayudar a alguien a poner orden en sus informes sino para tenerlo como apuntes ya que es un tema que si no lo conoces al dedillo te hace perder mucho tiempo con pruebas y consultas erróneas. Vamos a trabajar consultas de analytics sobre flujos de paginas vistas de nuestras visitas.

Nociones previas

Reconozco que el contenido de post puede resultar un poco difícil de entender para aquellos que no conozcan unos mímimos de Google Analytics. Debes entender que estamos hablando de consultas algo complejas y por lo tanto deberías ya haber asimilado estos conceptos:

• Qué son las dimensiones y las métricas en Google Analytics
• Cómo funcionan los filtros y los segmentos en la herramienta
• Cómo crear un informe personalizado
• Que nombres reales tienen las dimensiones en la API de analytics

Intentaré ser lo más descriptivo posible durante el post pero si no conoces nada de esto es difícil que puedas llevar a la práctica este tipo de extracciones.

Peculiaridades de las dimensiones en Google Analytics y el trabajo con páginas vistas

Google Analytics usa un sistema de métricas (indicadores numéricos) y dimensiones para ofrecer sus datos. Esto significa que cuando miras un informe realmente no estás consultando cada visita y página vista de tus usuarios sino que lo que te muestra es esta información después de haber sido transformada en este sistema de datos.

Las dimensiones son agrupaciones del total de los datos que se han ido recibiendo. Estos han sido clasificados mediante algún criterio que es el que marca la propia dimensión. Así la dimensión «ga:medium» (que en la web de analytics en español se traduce como «Medio») es una agrupación tomando como criterio los medios por los que ha podido entrar un usuario (organic, cpc, referral, etc.) y ga:landingPagePath ( traducido como «página de destino») es la página por la que llegó la visita a tu web.

Estas dimensiones toman valores para todas las métricas disponibles y así quedan asignados los valores que ves al navegar por Analytics. Por lo general, la mayoría de los datos no dan demasiados problemas pues casi todos están orientados a trabajar en el ámbito de las visitas como base y se comportan como uno esperaría: Si yo le pido a GA las visitas por campaña me las dará y todos seremos felices.

El problema aparece cuando en nuestros informes queremos reflejar datos que surgen a nivel de página vista y no de visita donde muchas veces no nos damos cuenta y al estar tan acostumbrados a trabajar con visitas le pedimos un imposible a analytics: que nos muestre datos de visitas con criterios de página vista: «Dame las visitas de esta URL» o peor aun «Las visitas de la página que vieron los usuarios antes de llegar a la página X». El problema es que como nosotros entendemos ese dato tan «simple» no es como Google Analytics lo entiende internamente y así pasamos al fantástico mundo de los datos falsos…

Las extrañas dimensiones de página

En Google Analytics existen una serie de dimensiones que están creadas para trabajar solo a nivel de página vista y no de visita

Ahí encontraríamos:

• ga:pagePath o «Página».
• ga:nextPagePath o «Rutas de la página siguiente».
• ga:previousPagePath o «Ruta de la página anterior».
• ga:pagePathLevelX o «Nivel de Ruta de página X».

Estas dimensiones en realidad guardan datos sobre la página vista y no sobre la visita por lo que al trabajarse con visitas, si no las vigilamos, nos darán resultados extraños.

¿No me crees? Solo tienes que ir a tu Analytics y cargar tus informes de contenido («Comportamiento» >> «Contenido del sitio») y verás como ninguno de los datos de estas dimensiones lo asocia Analytics a valores de visita o visitante: solo los usa para métricas de página: páginas vistas, páginas vistas únicas, tiempo en página, etc.

¿Por qué sucede esto?

El problema que hay con todo esto es que Google Analytics utiliza el mismo sistema de almacenamiento (podríamos llamarlo misma «base de datos») tanto para visitas como para páginas vistas. Esto provoca que para ciertas dimensiones (las orientadas a página vista) G.A. no tenga sitio donde guardar las visitas por lo que decide contabilizar estas visitas tan solo en una de esas páginas vistas (la primera de todas).

Pongamos un ejemplo sencillo:

1- Un usuario llega a la home.
2- Va a la página /pagina-1
3- y luego a la /pagina-2 y se marcha.

Cuando le pedimos a Analytics que nos diga cuantas páginas vistas tienen cada una de estas páginas lo tendrá fácil: cada una tiene una página vista.

– «/» = 1 página vista
– «/pagina-1» = 1 página vista
– «/pagina-2» = 1 página vista

Pero cuando le preguntamos cuantas visitas tiene cada una de esas páginas es cuando no puede responder correctamente. Hay solo una visita. ¿cuantas tiene cada una? ¿1/3 de visita? ¿1 sumando un total de 3?

Para solucionar esto Analytics presenta la información de la siguiente forma:

– «/» = 1 página vista y 1 visita
– «/pagina-1» = 1 página vista y 0 visitas
– «/pagina-2» = 1 página vista y 0 visitas

Sí, G.A. contabiliza las visitas tan solo en la primera página vista de las mismas.

En fin, dejando a un lado tecnicismos la conclusión que sacamos es que no deberíamos pedirle a Google Analytics dimensiones de página y de ellas querer sacar métricas de visita pues nos va a contabilizar solo las primeras de cada visita.

¿Y con los segmentos? ¿Tampoco podemos usar estas dimensiones?

Ahí el tema es distinto. Si bien Analytics va a almacenar la visita en solo una de las páginas vistas todos estos datos quedarán englobados dentro de la misma visita por lo que realmente se segmentará correctamente al hacer la configuración sobre la página vista.

Volvamos al ejemplo anterior. En este caso yo quiero saber cuantas visitas han pasado por la «/página-1» por lo que voy a crear un segmento en el que ga:pagePath («Página») sea igual a «/pagina-1».

Sabemos que Analytics contempla nuestra visita como decíamos antes:

– «/» = 1 visita + 1 página vista
– «/pagina-1» = 0 visitas + 1 página vista
– «/pagina-2» = 0 visitas + 1 página vista

Pero aun teniendo 0 visitas «/pagina-1» es parte de esa visita por lo que al segmentar esa visita será contabilizada; se sumarán todas las visitas de esos datos (=1 visita y 3 páginas vistas) y se mostrará esta en el resultado. Por ese motivo los segmentos sobre estas dimensiones si que funcionan como uno esperaría.

Entendida esta gran contra ya podemos empezar a tratar el tema que nos ocupa: hacer consultas a Google Analytics sobre los flujos de páginas vistas de los usuarios.

Cómo hacer pruebas de consultas en Google Analytics

Os indico dos recursos con los que podemos trabajar lo que queda de este post:

• El explorador de Consultas de Google Analytics: una herramienta que trabaja sobre la API de analytics y que resulta muy rápida si entiendes los principios de como formular una consulta vía API
• El generador de informes Personalizados de Google Analytics («Personalización» >> «+ Nuevo Informe Personalizado»): Sin duda más visual, pero también mucho más lento para ir obteniendo resultados.

Bajo estos dos sistemas podremos ir verificando las posibilidades de estas consultas.

Las dimensiones para seguir el flujo de páginas en Google Analytics

Por mucho que vayamos a realizar consultas sobre el flujo de páginas, no tenemos que olvidar que hablamos de consultas sueltas de datos: tablas donde asociaremos dimensiones a valores concretos.

Así pues más que hacer un seguimiento de flujos completos lo que podremos será consultar dos dimensiones que nos permiten ver pasos dados por el usuario de página a página y así: página a página, consulta a consulta: construir los recorridos de visita.

Yo podré ver cosas como:

• Alguien fue de «la home» a la «categoría X» un total de 25 veces
• Alguien fue de «categoría X» al «producto Y» un total de 10 veces
• Alguien fue de el «producto Y» al «proceso de compra» un total de 2 veces

Y con eso construiré mi flujo de páginas de usuario, pero donde de alguna forma deberé tener en cuenta que los 2 usuarios que pasaron del «producto Y» al proceso de compra no tienen porque ser los mismos 10 que habían pasado de la «categoría X» al «producto Y»: simplemente puedo observar pasos individuales: página a página.

Para poder sacar estos pasos Analytics nos aporta 3 dimensiones que en realidad son 2:

• ga:pagePath o «Página»: La página vista.
• ga:previousPagePath o «Rutas de la página anterior»: La página anterior vista, que adquiere el nombre «(entrance)» si es la primera página vista
• ga:nextPagePath o «Rutas de la página siguiente»: La página siguiente, pero no a la página actual sino a la anterior vista.

¿Veis la icoherencia? ga:pagePath y ga:nextPagePath son exactamente el mismo valor. Esto es porque ga:pagePath antes funcionaba de otra forma y realmente la única forma de acceder a páginas vistas concretas era mediante el combo de página anterior y siguiente. A día de hoy sin duda ga:nextPagePath (Ruta de página siguiente) es una dimensión totalmente inútil.

¿Y la página siguiente a la actual donde está?

No existe. Cuando analytics captura los datos no sabe cual va a ser la siguiente página vista y por lo tanto siempre se consulta de una página a su página anterior y no al reves, aunque luego veremos que se trata solo a nivel de concepto, que el dato se puede sacar igualmente.

Normas básicas para una consulta sobre flujos páginas

Como acabamos de ver lo primero que tenemos que tener en cuenta es que deberemos sacar siempre en nuestras consultas la métrica de páginas vistas (ga:pageviews) o nuestro informe no tendrá sentido.

Incluso puedes hacer tus propias comprobaciones de como almacena Analytics los datos y por qué resultan inútiles.

1. Extrae solo visitas y/o visitantes en una consulta con ga:previousPagePath («Ruta de la página anterior») y ga:pagePath («Página») verás como todos los ga:previousPagePath path son equivalentes a «(entrance)»
2. Extrae visitas y/o visitantes y además las páginas vistas. Verás como los datos empiezan a cobrar sentido pero el valor de visitas es siempre «0», salvo para las primeras páginas visitas (donde se almacena el contado de visitas) que tendrán su valor y el previousPagePath a «(entrance)».



Así que por enésima vez: ¡Nada de visitas!

Filtrando todos estos datos para ver solo el paso que queremos

Cuando empiezas a llevar ya un tiempo trabajabando con Google Analytics acabas por usar casi en exclusiva el fitrado de datos por Segmentos por lo que mucha gente cuando quiere filtrar sólo algunos pasos del flujo de usuarios tiene problemas.

Esto es porque los segmentos de analytics funcionan a nivel de visita o de usuario y no a nivel de página vista por lo que al usar segmentos sobre las dimensiones de página vista volvemos a cometer el error de mirar donde no toca.

Esto significa que la herramienta para filtrar datos que nos queda será entonces el filtro normal (ese que podemos lanzar al crear el informe personalizado o bien al filtrar una vez ya vemos el informe). Este filtro en realidad no va a actuar ni sobre visitas ni sobre páginas vistas sino que lo único que hace es limpiar la tabla que vemos para esconder todo lo que no queremos ver. En nuestro caso, eso ya nos vale pues esconderemos todos esos pásos de página a página que no nos interesan.

Así pues:

• Destinaremos al «filtro» de nuestra consulta las dimensiones de página (que no son de sesión): ga:pagePath («Página») y ga:previousPagePath («Ruta de la página anterior») según las necesitemos filtrar.
• Destinaremos al «segmento» de la consulta las dimensiones que si que nos hacen filtrar visitas: medios, landings, si la visita convirtió o no finalmente, etc.

Todo sigue igual, solo que usando cada dimensión donde toca.

Sacando páginas a las que va un usuario desde una página concreta

Para eso usaremos el filtro en la dimensión ga:previousPagePath («Rutas de la página siguiente») pues solo quiero ver los datos desde ciertos orígenes.

Por ejemplo si quiero saber a donde va el usuario desde la home:

• Dimensión a extraer: ga:pagePath («Página»)
• Filtro: ga:previousPagePath(«Ruta de la página anterior») == «/»

En el API Explorer:



En informes personalizados de la web:



Sacando las páginas desde las que llega un usuario a una página concreta

En este caso estamos en la sitaución contraria. Por lo que bastará con invertir las dimensiones usadas y usaremos el filtro con ga:pagePath («Página») pues la que quiero ver es en la que estoy.

Por ejemplo si quiero saber a desde donde llegan los usuarios ala home:

• Dimensión a extraer: ga:previousPagePath(«Ruta de la página anterior»)
• Filtro: ga:pagePath («Página») == «/»

En el API Explorer:



En informes personalizados de la web:



Sacando nodos concretos

Otra forma de trabajar para hacer ciertos dashboards es conociendo exactamente que paso estamos midiendo, donde lo que queremos es ver los usuarios que pasan de la página X a la Y como se dividen por otra dimensión.

Por ejemplo si queremos saber los usuarios que pasan de la home a la página «/quienes-somos»

Deberíamos sacar:

• Dimensión a extraer: Ninguna, o la que deseemos para ver sus resultados.
• Filtros:
  ga:previousPagePath(«Ruta de la página anterior») == «/»
  y ga:pagePath («Página») == «/quienes-somos»

Sacando consultas más complejas.

Dominado este tema de las consultas básicas, seguramente querremos sacar consultas un poco más complejas, como por ejemplo si yo quisiera saber desde que páginas llegan los usuarios capturados con las campañas SEO a mi embudo cuando hay conversión tendríamos una configuración como la que sigue:

• Metricas: ga:pageviews («Número de Páginas vistas»)
• Dimensiones: ga:previousPagePath («Rutas de la página anterior»)
• Filtro: ga:pagePath («Página») == /entrada-embudo
• Segmento: ga:medium («Medio») ==cpc; ga:goal1Completions («Cumplimento Objetivo 1») >0

O si no me interesa solo que midan a una página concreta sino a toda página que empiece por «/embudo-«:

• Metricas: ga:pageviews («Número de Páginas vistas»)
• Dimensiones: ga:previousPagePath («Rutas de la página anterior»)
• Filtro: ga:pagePath («Página») =@ /entrada

¿Podemos crear nuestros propios embudos con esta información?

Viendo estas posibilidades, entre las primeras cosas que podemos querer poner en práctica podríamos encontrar el crear nuestros propios embudos, sacando cada paso mediante estas consultas y luego dibujando el embudo. Tendrían la ventaja de ser retroactivos y de poder sacar distintos tipos de embudo para un mismo objetivo. Que bien suena, ¿verdad?



Sin embargo, cuando lo hagamos, veremos que los datos no coinciden con el de nuestros bonitos embudos verdes de Google Analytics. Dependiendo del tipo de proyecto la distancia que separará a unos valores más o menos de los otros cambiará pero los datos nunca serán los mismos.

¿porque sucede esto?

Pues sencillamente porque no son los mismos datos. Los embudos de Google Analytics funcionan al margen del sistema de dimensiones y métricas de analytics.

Recordemos que este sistema de consultas que estamos usando en realidad se basa en visitas y que además al pedir las páginas vistas lo estamos forzando a trabajar a nivel de página vista.

Por el contrario los embudos de analytics trabajan a nivel de visitante. Esto es: si un usuario entra por el embudo varias veces hasta completarlo la herramienta de embudos no mostrará cada recorrido sino que en ella veremos a un único usuario que ha llegado al final del embudo sin contemplar todas las veces que lo ha abandonado. Incluso si entra en distintas ocasiones (en distintas visitas) el resultado será el mismo (pues trabaja al nivel de usuario).

En cambio nuestras posibilidades con las consultas y con API son a nivel de página vista con lo que contemplaremos siempre muchos hits extras: páginas vistas que nos indican que el usuario volvió atrás, salidas y vuelta a entrar en el embudo, errores con algún dato, etc. Una gran cantidad de información que no está en el embudo de analytics pero si en nuestros informes.

Lo peor de todo no es que esto suceda por defecto sino que como no podemos consultar sobre el embudo de conversiones y tan solo disponemos de nuestras consultas de dimensiones y métricas, sencillamente: nos va a ser imposible replicar el embudo de analytics tal cual aparece en sus gráficos internos. El sistema de consultas de analytics no va a poder trabajar con visitas y/o visitantes y flujos de páginas a la vez.

Pero eso no significa que nuestros datos estén mal, solo son distintos. ¿Que es mejor? Un embudo que no nos muestra la mitad de los datos u otro que tiene tantos que pueden llegar a estorbar? Ninguno es mejor que el otro, solo tenemos que saber que son distintos para poder interpretarlos de forma distinta cuando veamos sus resultados.