Calidad del dato y automatización de validaciones en GA4

La inestabilidad del ecosistema de datos web y app nos obliga a validar.

El efecto «Dev»: La Desviación estándar validable (una pequeña broma para romper el hielo) es el causante de una necesidad indiscutible. En webs vivas las mediciones se rompen. A veces drásticamente, otras con una simple variación de alguna variable que desmonta por completo nuestros informes y nuestra estadística.

En un mundo plagado de «Fake News» los negocios digitales se ven amenazados por el «Fake Data», a veces tan evidente como grandes picos y valles en las tendencias, otras muy sutil y peligroso.

Seamos claros: con datos falsos, nuestro trabajo no es solo inútil: es peligroso. Por eso resulta imprescindible validar el dato una y otra vez. Una validación que, a medida que el proyecto crece y se complica, es cada vez más lenta y tediosa.

No es raro, y esto lo validamos durante la charla con todos los asistentes, que cuando observamos el tiempo destinado a estos ejercicios descubramos horrorizados que puede llegar a ser más del 40% de nuestra dedicación. Una dedicación que nadie quiere que suceda. El negocio o cliente no la valora (la da por hecha) y el analista ve cómo pierde oportunidades de generar valor por culpa del tiempo que pierde validando en el día a día.

Sin embargo, este trabajo no es una elección. Validar y, sobre todo, cualificar los datos, es obligado y debe hacerse antes que cualquier otra tarea. ¿No todos validan? No. Gente vaga existe y existirá siempre. Pero las consecuencias de no hacerlo son demasiadas y con un impacto demasiado grande como para que puedas planteártelo:

• Cambios que pasan desapercibidos
  
• Gaps (brechas) en los datos.
  
• Mediciones incorrectas que se mantienen en el tiempo
  
• KPIs que se distribuyen erróneamente entre las dimensiones
  
•  Incapacidad para creerte comparaciones temporales (MoM, YoY, etc.)
  
• Datos decorados
  
• Fake Insights
  

El momento no ayuda. GA4 y sus nuevas tecnologías lo complican todo.

Que el ecosistema digital, con la entrada de GA4, se ha tecnificado es más que evidente. Consent Mode, Cookies, Modelados, apps móviles. Y ahora, ¿por qué no? La entrada del inevitable mundo del server-side tagging.

No acabas de dominar una nueva tecnología que otra ya está compitiendo por ser nuestra nueva pieza esencial de medición.

Esto nos lleva a un flujo de envío de datos hacia GA4 con demasiados pasos. Un dato debe ser impreso en una web o pantalla, debe formalizarse en un dataLayer, que es leído e interpretado por un Tag Manager de cliente, que genera un hit de datos a medir, que se lee por un tag manager server-side, que vuelve a interpretarlo, lanzando varios hits desde servidor hacia las distintas herramientas, para que el colector de GA4 por fin lo capte, lo almacene y lo procese. Esto te lo cuentan sin contexto y hasta parece un mal chiste. Pero es el mundo en el que muchos estamos y en el que todos estaremos en no mucho tiempo.

Cada herramienta y proceso aportan su valor, esto es indudable. Si no fuese así, no los usaríamos. Pero tantos pasos también provocan que se debilite el sistema, aumentando el número de puntos donde el dato podría fallar y corromperse.

El funnel de pérdida de datos.

Si cada paso de un proceso lineal provoca fugas y errores. Lo que tenemos al observar este proceso es un bonito embudo. Un sistema con el que los analistas sabemos lidiar bien: Un funnel. Solo que en lugar de conversión, este es para obtener datos de calidad.

Viendo este proceso como tal, sabemos que podemos entrar a cada paso, calcular su impacto y, sobre todo, encapsular los problemas de calidad del dato en puntos concretos del funnel que son los que lo provocan.

Una vez estructurado todo, aplicamos nuestra suite de herramientas. Una colección que poco a poco ha ido estandarizándose y que nos aporta información al detalle para cada paso del funnel de pérdida de datos.

La consola del navegador.

La que es sin dudas la más potente, pues nos permite (con algo de práctica) ver y provocar cualquier comportamiento. Pero que por otro lado es lenta y especialmente técnica.

Las propias herramientas que nos da Google o el ecosistema

GTM config, GTM debug (tanto para cliente como para servidor, que no son iguales pero se parecen en formato), GA debug o el tiempo real de GA4.

Son herramientas muy útiles que además nos ofrecen información de primera mano y por lo tanto debemos controlar.

Los sniffers y proxies

Que en forma de plugins de navegador o aplicaciones de escritorio, nos permiten validar dataLayers y hits hacia GA4 (y otros trackers). Entre ellos destacan las 2 grandes aplicaciones de David Vallejo:

• Analytics debugger (la reina de la validación web)
• y IOS/Android debugger (la reina y salvadora de la validación app)

Los informes de GA

Que nos permiten observar evento a evento todos los datos capturados de cada uno de ellos y como las tendencias se rompen cuando se cambia algo.

Demasiado trabajo, demasiado repetitivo

Estos sistemas son geniales y necesarios. Pero todos ellos son manuales. Requieren de que una persona navegue por cada página y vaya mirando datos uno a uno. Se realicen pruebas, compras falsas y cualquier interacción que el usuario pudiese realizar.

No solo eso. Además, estas validaciones no son un punto suelto y aislado de nuestro trabajo. Son una actividad repetitiva que podemos llegar a estar realizando cada semana.

• En cada proyecto
  
• Para cada evento
• En cada subida a produccion
• Cada vez que dudamos el dato o vemos cambios de tendencia
• Cada vez que afrontamos un nuevo foco de análisis 
• Cada maldito día de nuestra vida
  

No podemos dejar de validar. Pero sí debemos procurar como sea perder menos tiempo en validaciones.

Una primera aproximación es entender que se trata de un embudo y, por lo tanto, al estar los datos conectados, no estamos obligados a ver todos los pasos del mismo. Un embudo se ataca por el final. En este caso por la captura de datos en GA4 y solo cuando estos denotan problemas es cuando vamos a mirar pasos clave del mismo. Luego ya sí iremos a por el resto de pasos, pero ya solo esta perspectiva nos va a permitir dejar de mirar mucha información inútil y centrar nuestro día a día en pocas herramientas: las más eficaces y veloces.

Aun así, este tiempo sigue siendo demasiado. Demasiadas repeticiones. Demasiadas capturas manuales de datos. ¿No puede agilizarse? Para ello es para lo que entran las técnicas de validación automatizada.

Automatizando la toma de datos para validaciones.

La idea es simple. Validar hay que validar. Pero, ¿no puede haber sistemas que nos aporten una visión rápida automática y/o nos permitan validar muchísimas interacciones de golpe?

Sí. ¡Los hay! Al igual que antes, podemos dibujar una suite de herramientas que tiendan a automatizar las validaciones o al menos su toma de datos.

Crawlers y RPAs

Sistemas automáticos que naveguen por tu web de forma absoluta, siguiendo todos los links (crawlers) o mediante la programación de una secuencia de acciones de navegación (RPA). Ambos sistemas te van a permitir obtener de golpe multitud de datos para validar. Cientos o miles de ellos. Esto cambiará tu forma de validar: ya no mirarás dato a dato, sino que trabajarás sobre sheets o mejor aún, dashboards con los datos totales.

Entre las opciones que no implican desarrollo propio y que estén disponibles para todos destacamos dos:

La grabación de sesiones de Chrome.

No es el mejor RPA que existe. Pero es uno al que todos tenemos acceso. Entramos en la pestaña record de la consola de Chrome. Grabamos una sesión compleja de validación y, a partir de entonces, con darle a un botón ya se repetirá entera. Esto, con plugins de sniffers (como el citado debugger de Vallejo) nos permitirá iteraciones rápidas en las validaciones.

Screaming Frog con captura JS personalizada.

Screaming Frog es el crawler más famoso del mundo. La herramienta de crawling SEO por excelencia. Sí, todo screaming gira alrededor del SEO, pero eso no significa que los analistas no podamos aprovecharnos de ello.

A partir de la versión 20, Screaming Frog ha incorporado el scraping de elementos a medida con JS. En cada página que visita el crawler se inyectan los fragmentos Javascript que definas, ya sea para interactuar con la web o para conseguir datos. Esto en la práctica es muy similar al tipo de funciones que usarías en GTM. Es decir: si sabes crear etiquetas personalizadas en GTM, sabrás sacarle partido a esta funcionalidad.

Como ejemplo os dejo un regalito: 3 scripts ya creados dedicados a scrapear el dataLayer de una web.

1. Copiar el dataLayer completo, con todos sus eventos y parámetros de cada uno. El más completo, pero el más complejo para observar luego el resultado.
2. Recoger todos los parámetros acumulados (tal y como lo hace GTM) para un evento determinado.
3. Recoger un solo parámetro en un evento concreto (por ejemplo, recoger «page_type» en el evento page Load («gtm.js»).

Ya solo mediante estos 3 sistemas podréis recoger todos los dataLayers de un negocio con miles o cientos de miles de URLs (algún millón también, pero prepárate para dejar el ordenador encendido unos cuantos días).

Descárgalos aquí: https://ikaue.com/recursos/fragmentos-custom-js-para-screaming-frog 

Algunas ideas más para poder realizar con esta técnica:

• Usar las acciones JS para hacer clicks en productos, carritos, scrolls, etc.
• Realizar envíos de formulario de prueba y capturar sus resultados.
• Trazar los datos de los propios hits de GA4 (o de cualquier tracker) – esto es más complejo.
  
• Realizar auditorías del etiquetado de la competencia.
• Validar migraciones y subidas a producción de forma automática.
• Colaborar con IT para que ellos mismos se hagan las evaluaciones de cambios.

Provocar Hits de validación.

Esta técnica lo que hará es permitirnos disponer de una pequeña base de datos que facilite la validación de datos reales en eventos que sean críticos para nuestro negocio. Lo que hacemos básicamente es enviar hits hacia nuestra base de datos (Sheets, BigQuery, lo que quieras) con información clave de lo que está sucediendo en nuestra web.

Esta visión, al compararla con bases de datos reales o con el propio GA4, nos permitirá descubrir el problema real que provoca que en ciertos usuarios no se guarden datos o se guarden de forma incorrecta.

Realizar esto de forma profesional requiere simplemente crear una variable personalizada en GTM y un endpoint (una URL) capaz de recibir estos datos y almacenarlos.

Lo suyo sería crear esto con herramientas en la nube. Un ejemplo técnico pero sencillo: Crear el endpoint con Google Cloud Functions (que nos dará directamente la URL y se conectará él solo a la API de Google) y almacenar en Google BigQuery.

Otra fórmula más chapucera pero mucho más rápida: Crear un Google Forms, y aprovechar la URL de destino del formulario para almacenar todos los datos que llegan. Como Google Forms se puede conectar a Google Sheets y Google Sheets se puede conectar a BigQuery, el resultado será bastante similar sin tener por qué lidiar con código.

Puedes ver como crear este tipo de soluciones con Google Forms en este hilo que publique en X hace algún tiempo: https://x.com/ikhuerta/status/1136200670007169027

Estas soluciones te permitirán evitar muchísimas pruebas repetitivas. Tan solo implántalas y captura tú mismo lo que desees de tus usuarios.

Trackers JS y Proxies

Muy parecido a los sniffers y proxies que usábamos manualmente, pero ahora aplicado a la navegación real de la web. Para hacer esto se cuenta con interceptores JS o un proxy de envío en la APP. Se realiza la implementación de GTM y GA de la forma normal, pero mediante estos sistemas se captura todo hit hacia GA (o hacia cualquier herramienta) antes de que este ocurra.
Es decir, creamos un espía de toda la analítica que deseemos auditar. Mediante estos datos, a través de dashboards y de BigQuery, podremos llegar a crear tipologías de análisis automatizado realmente sorprendente.

Lo que sigue es una captura de un análisis que hacemos en IKAUE. Se trata de un panel de Looker Studio con el que vemos todos los dataLayers, errores y envíos de datos hacia GA ordenados por tiempo de envío. Con él podemos ver cómo se suceden los hits y si algunos se duplican o llegan demasiado tarde. Algo que manualmente requeriría de un experto en QA de GA y bastante tiempo de análisis.

Como ejemplo de trackers comerciales destacamos la gran opción que puede suponer Tracking Plan. Una herramienta que realiza este mismo proceso y además crea modelos predictivos que les permiten saber si hay incoherencias o gaps en las implementaciones de forma automática (es decir, te pueden avisar de que te han quitado el add_to_cart o de que en cierta zona de la web falta un parámetro).

Informes de GA/Looker y BigQuery

Con los informes de datos de GA podemos hacer auténticas maravillas para validar. Al final, esta es la visión que cuenta: si no tenemos un dato en donde esperábamos tenerlo es señal de que hay que ir a revisar el resto del embudo. Nuestro consejo: crea informes solo para validar GA4.

Puedes empezar usando nuestro dashboard de validación de GA4. Un dashboard creado para auditar los datos y no tanto para ver tendencias o conversiones.