GA4 en una tienda casi siempre «funciona»: los gráficos se dibujan y llegan sesiones. La auditoría parte de otra pregunta: ¿dicen la verdad los eventos de e-commerce? Cada embudo, cada análisis y cada campaña optimizada con conversiones de GA4 es exactamente tan buena como la implementación que hay debajo. Esta guía es una lista de control de auditoría: el conjunto de eventos, los errores típicos, la cobertura frente a los pedidos reales y una rutina de validación.
Lista de control
Eventos de e-commerce en GA4: lo que tiene que funcionar
El proceso de compra en GA4 se compone de eventos estándar con nombres definidos en la documentación de Google. La auditoría empieza comprobando si se envían todos y qué llevan en sus parámetros:
| Evento | Cuándo debe enviarse | Qué debe incluir |
|---|---|---|
| view_item_list | visualización de un listado / categoría | items con item_id |
| view_item | entrada en la ficha de producto | items, value, currency |
| add_to_cart | añadir al carrito | items con cantidad y precio |
| begin_checkout | inicio del proceso de pedido | items, value |
| add_payment_info | elección del método de pago | items, payment_type |
| purchase | una vez por pedido pagado | transaction_id, value, currency, items |
Dos reglas por encima de todo: nombres estándar (inventos propios como add_to_basket no alimentan los informes de e-commerce ni los modelos de conversión) y item_id coherentes, que coincidan con los identificadores del sistema de la tienda y del feed de productos. Sin lo segundo no podrás vincular el comportamiento con productos concretos, y en eso se basa toda la analítica del embudo descrita en la guía sobre cómo cruzar las estadísticas de GA4 con las ventas.
Errores típicos
Cinco errores típicos al implementar GA4 en tiendas
Los mismos errores se repiten tienda tras tienda, sea cual sea la plataforma. Notas de auditorías:
purchase solo en la página de agradecimiento
Tras un pago con redirección, parte de los clientes nunca vuelve a ella. El pedido existe, el evento no; la cobertura cae en silencio y de forma irregular.
transaction_id ausente o repetido
Sin identificador no hay deduplicación: al recargar la página de agradecimiento, el pedido se cuenta dos veces. El número de eventos debe ser igual al de transacciones únicas.
value unas veces con IVA y otras sin él
Un valor de purchase que mezcla impuestos y envío según la plantilla infla o reduce los ingresos en GA4. Fija una única definición y compruébala con un pedido de prueba.
item_id que no coincide con la tienda
GA4 envía el SKU de la variante, la tienda informa del ID del producto y el feed, de otro distinto. Tres sistemas, tres diccionarios y ningún análisis común por producto.
Nombres propios en lugar de los estándar
Los eventos funcionan, pero tienen nombres propios, así que los informes de e-commerce aparecen vacíos y los modelos de conversión no tienen datos con los que trabajar.
Método principal
Cobertura: compara purchase con los pedidos de la tienda
La prueba más sólida de la implementación no requiere mirar el código: compara el número y el valor de los eventos purchase con los pedidos pagados del sistema de la tienda, periodo a periodo. Esa única cifra (la cobertura) indica si se puede confiar en los datos (datos ilustrativos, tienda de suplementos):
Cobertura: purchase en GA4 / pedidos pagadostienda de suplementos · datos ilustrativos
La semana 3 no la explican los clientes, sino la implementación: tras cambiar de pasarela de pago, parte de los clientes dejó de volver a la página de agradecimiento. Sin monitorizar la cobertura, esa semana habría parecido «menos tráfico» y habría llevado a malas decisiones de presupuesto.
Cierta diferencia es normal: el bloqueo de scripts, la falta de consentimiento y las rutas de pago atípicas siempre restan unos puntos porcentuales. La alarma no es la cifra en sí, sino el cambio de nivel: una cobertura estable durante meses que cae de repente indica un fallo de medición. La misma lógica se aplica al valor: suma de value de purchase frente a suma de ingresos de pedidos pagados.
El sistema de la tienda dice cuánto has vendido de verdad. GA4 dice cuánto de eso ve. La auditoría vigila que la segunda cifra no se despegue de la primera.
Rutina
Validación paso a paso: pedido de prueba y DebugView
La auditoría cualitativa se hace a mano, en la tienda en producción:
Activa DebugView y recorre el embudo de compra
Desde el listado, pasando por la ficha de producto y el carrito, hasta un pedido de prueba pagado. Cada paso debe mostrar su evento en DebugView en tiempo real.
Comprueba los parámetros de cada evento
Array items con item_id, precio y cantidad correctos; en purchase, además, transaction_id, value y currency. Compara value con el importe del pedido y con la definición acordada (con o sin IVA, con o sin envío).
Prueba los casos límite
Pago con redirección, recarga de la página de agradecimiento, vuelta desde el historial del navegador. Aquí es donde surgen las pérdidas y los duplicados, no en el recorrido ideal.
Configura una monitorización continua de la cobertura
Resumen semanal de purchase frente a pedidos pagados (número y valor). Una auditoría puntual caduca con el primer cambio de plantilla, plugin o pasarela de pago.
Riesgo real
Una implementación rota estropea algo más que los informes. Las campañas de Google Ads aprenden de los eventos de GA4; un hueco en purchase significa menos señales de conversión, peor optimización y pedidos realmente más caros. La mecánica de los desajustes entre paneles y tienda se analiza en la guía sobre conversiones y atribución.
DataOrganizer
Cómo vigila DataOrganizer la calidad de los datos de GA4
DataOrganizer obtiene los eventos de GA4 y, en paralelo, los pedidos del sistema de la tienda, así que la cobertura se calcula con los datos, sin exportaciones manuales: número y valor de purchase frente a pedidos pagados, día a día. Además, la detección automática de anomalías señala los cambios bruscos antes de que nadie abra un informe:
Cobertura de purchase en las últimas semanas:
| Semana | purchase GA4 | Pedidos pagados | Cobertura en número | Cobertura en valor |
|---|---|---|---|---|
| 18.08–24.08 | 418 | 446 | 94% | 95% |
| 25.08–31.08 | 289 | 401 | 72% | 70% |
| 01.09–07.09 | 437 | 459 | 95% | 96% |
En la semana del 25.08 al 31.08 la cobertura cayó al 72% y volvió a la normalidad a partir del 01.09, mientras que el número de pedidos pagados en la tienda apenas varió (401 frente a 446 y 459 en las semanas contiguas), así que la pérdida está en la medición. La caída coincide con el cambio de pasarela de pago; la causa más probable es el pago con redirección sin vuelta a la página de agradecimiento (pendiente de confirmar con un pedido de prueba). Los informes de GA4 de esa semana infravaloran las ventas; para comparar, usa los datos de la tienda.
Para recordar
La auditoría de GA4 solo funciona como hábito. En lo cualitativo: pedido de prueba con DebugView tras cada cambio en la tienda. En lo cuantitativo: cobertura de purchase frente a pedidos pagados cada semana. DataOrganizer hace la segunda parte automáticamente, porque tiene ambas fuentes una junto a otra.
FAQ
Preguntas frecuentes sobre la auditoría de GA4 en tiendas
¿Qué eventos de e-commerce debe tener una tienda en GA4?
El recorrido estándar: view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info y purchase, cada uno con el array items, y purchase con transaction_id, value y currency. Los nombres deben ser los estándar de la documentación de Google; los informes de e-commerce no reconocen nombres inventados.
¿Por qué GA4 muestra menos pedidos que la tienda?
Sobre todo porque purchase se dispara solo en la página de agradecimiento (parte de los clientes no vuelve a ella tras un pago con redirección), por el bloqueo de scripts y por la falta de consentimiento. Una diferencia de entre unos pocos puntos y algo más del diez por ciento es normal; una caída brusca de la cobertura es un fallo de medición, no un cambio en el comportamiento de los clientes.
¿Qué provoca los duplicados de purchase?
Recargar o volver a abrir la página de agradecimiento cuando falta transaction_id. Una implementación correcta envía purchase una sola vez por pedido, con un identificador único; la auditoría compara el número de eventos con el número de identificadores únicos.
¿Cómo comprobar que la implementación es correcta?
En lo cualitativo: pedido de prueba con DebugView y control de los parámetros de cada evento, incluidos los casos límite (redirecciones de pago, recargas). En lo cuantitativo: cobertura en número y valor de purchase frente a los pedidos pagados de la tienda, monitorizada de forma continua y no puntual.
¿Cómo ayuda DataOrganizer?
Tiene los eventos de GA4 y los pedidos de la tienda uno junto a otro, así que la cobertura se calcula automáticamente sobre totales diarios (número y valor de purchase frente a pedidos pagados), y la detección de anomalías avisa de cambios bruscos en los datos. La pregunta «¿GA4 registra todos los pedidos?» recibe en un minuto una respuesta con cifras, junto con el periodo en el que no conviene fiarse de los datos.
Resumen de toda la guía
Auditoría de GA4 en tres capas
1. Todos los eventos, con nombres estándar. El recorrido de view_item a purchase, con items, transaction_id, value y currency. Todo lo demás se construye sobre esto.
2. La cobertura como indicador permanente de confianza. Número y valor de purchase frente a los pedidos pagados de la tienda, semana a semana. Un cambio de nivel es una alerta de implementación antes de que se convierta en una mala decisión de presupuesto.
3. Validación tras cada cambio. Un pedido de prueba con DebugView después de cambiar la plantilla, un plugin o la pasarela de pago. DataOrganizer completa el proceso: la cobertura y las anomalías se calculan solas, porque los datos de GA4 y de la tienda están en el mismo sitio.
DataOrganizer · GA4 bajo supervisión continua
Conecta GA4 y el sistema de tu tienda: las sumas diarias de purchase se compararán con los pedidos pagados y las anomalías en los datos se notificarán solas. Cuenta demo al instante; solo pagas por las fuentes conectadas.
