Diagnóstico de Google Analytics 4

El Cliente:

Una tienda con USD 145.000 en ventas y cero revenue en Analytics. El cliente es una empresa de distribución industrial con ecommerce activo, más de 75.000 usuarios mensuales y ventas reales funcionando. Se dieron cuenta que sus datos de GA4 “no cerraban” pero no sabían que hacer.

Qué encontramos:

Al auditar su implementación de GA4, el panorama era crítico. Cuatro problemas principales estaban haciendo que todos sus datos fueran inútiles:

1. Revenue real en la tienda: USD 145.000 — Revenue en GA4: USD 0 El negocio estaba vendiendo activamente, pero GA4 no registraba ningún ingreso. Los eventos de compra existían pero los parámetros de valor estaban mal configurados, haciendo invisible cada transacción para cualquier análisis de ROI.

2. Cero eventos de “agregar al carrito” con 75.000 usuarios activos A pesar de tener un carrito funcionando, GA4 no registraba ningún evento de agregar al carrito, con lo cual era imposible saber cuántos usuarios consideraban comprar pero no completaban la compra, ni en qué productos o en qué momento del proceso los perdían.

3. Más de 20.000!!!!! nombres de eventos únicos cuando deberían ser ~20 En lugar de un conjunto limpio de eventos, tenía más de veinte mil “eventos” ( que en realidad eran nombres de productos), URLs internas y referencias de órdenes capturadas por error como si fueran eventos. Esto hacía que los modelos de machine learning de GA4 fueran completamente inútiles y que las campañas de Google Ads no pudieran optimizar hacia conversiones reales.

4. El funnel de conversión estaba, lógicamente, completamente roto La tasa de “add to cart” aparecía en 1.8% cuando la real era significativamente mayor. La tasa de “cart to purchase” aparecía en 30%, un número completamente imposible para cualquier ecommerce normal. No había manera de tomar una decisión basándose en éstos datos.

El problema de fondo:

Todos estos problemas tenían una causa raíz técnica: el contenedor de Google Tag Manager se estaba cargando cuatro veces por página, duplicando y corrompiendo cada evento. A eso se sumaban parámetros mal mapeados y triggers demasiado amplios que disparaban eventos en páginas donde no correspondía.

Lo importante: ninguno de estos problemas requería rediseñar el sitio. Todos eran corregibles desde GTM.

Las correcciones:

Trabajamos en un plan de acción priorizado en tres niveles:

Crítico: eliminar el contenedor GTM duplicado, corregir el evento “add to cart” y configurar el cálculo de valor en los eventos de ecommerce.

Alto: corregir el formato de precios y restringir los triggers a las páginas correspondientes.

Medio: limpiar nombres de eventos malformados.