Todos los eventos de e-commerce de GA4 en KO en staging, antes de salir a producción.
Schema de item incompleto, variantes incorrectas en add_to_cart, purchase bloqueado por la arquitectura del checkout externo.
Guía de implementación evento a evento con especificación exacta para el equipo de desarrollo y convención de nombres estandarizada.
De fallo total a validación completa. El caso "antes/después" más fácil de visualizar.
Contexto
Detectarlo en staging, antes del lanzamiento, es la parte que marcó la diferencia — el mismo fallo detectado ya en producción habría significado semanas o meses de datos de e-commerce inservibles, con el coste añadido de tener que explicar retroactivamente por qué no cuadraban las cifras.
Cómo se resolvió, en detalle
Por qué "todos los eventos en KO" no es un solo bug
La tentación con un fallo total es buscar una causa única y dramática. Aquí eran tres problemas independientes que coincidían en el tiempo: el schema del objeto item no incluía todos los campos que GA4 espera como mínimos, las variantes de producto se mapeaban mal específicamente en add_to_cart (pero no en view_item, lo que descartaba una causa global), y purchase estaba estructuralmente bloqueado porque el checkout vivía en un dominio externo sin dataLayer propio.
El problema del checkout externo
Cuando el checkout final ocurre en un dominio o subdominio que no comparte el mismo dataLayer, el evento purchase no puede simplemente "seguir disparándose igual" — necesita un mecanismo explícito de traspaso de datos entre dominios (vía parámetros de URL firmados, o una llamada server-side) que sustituya lo que el dataLayer haría automáticamente en un flujo de un solo dominio.
Por qué la guía evento a evento importaba más que el fix puntual
Arreglar los tres problemas puntuales habría resuelto ese lanzamiento. La guía de implementación con especificación exacta por evento y convención de nombres estandarizada existía para que el próximo desarrollador que tocara el dataLayer no reintrodujera el mismo tipo de error por desconocer el estándar esperado.
Un fallo que afecta al 100% de los eventos rara vez tiene una sola causa — es más probable que sean varios problemas independientes coincidiendo, cada uno con su propio fix. Tratarlo como un único bug retrasa encontrar los otros dos.
Preguntas frecuentes
¿Por qué probar esto en staging y no directamente en producción?
Porque un fallo de e-commerce en producción no se limita a "no hay datos" — significa decisiones de negocio (presupuesto de medios, inventario) tomadas sobre cifras incorrectas durante el tiempo que tarde en detectarse. Staging existe exactamente para esto.
¿Este tipo de auditoría sirve para cualquier plataforma de e-commerce, no solo PrestaShop?
Sí, el método (auditar el dataLayer evento a evento contra el schema oficial de GA4) es independiente de la plataforma. Lo que cambia es dónde vive el dataLayer y cómo se genera, no qué hay que comprobar.