DataLayer ecommerce y capa de datos: 4 eventos y plantillas para analistas

DataLayer ecommerce: Para medir ecommerce correctamente en GA4 necesitas implementar los eventos core en el dataLayer, enviar currency en cada evento junto con value y transaction_id, y limpiar el objeto ecommerce antes de cada push con dataLayer.push({ ecommerce: null }). Sin ese patrón, GA4 puede procesar ingresos nulos o duplicados. Valida siempre en DebugView antes de dar por cerrada cualquier implementación.

En resumen:

• Es fundamental limpiar el objeto ecommerce con dataLayer.push({ ecommerce: null }) antes de cada envío para evitar datos duplicados o erróneos.
• Los eventos mínimos necesarios para medir ingresos en GA4 son view_item, add_to_cart, begin_checkout y purchase, siempre incluyendo currency y value.
• La correcta implementación requiere validar en DebugView que currency, transaction_id y items llegan siempre completos y en el orden correcto.
• La deduplicación de compras se realiza mediante el parámetro transaction_id, que previene registros duplicados tras recargas.
• LG DataOne ofrece herramientas automáticas para auditar y monitorizar en producción la calidad de los datos de ecommerce en GA4.

Tabla de contenidos

• Eventos ecommerce imprescindibles y parámetros obligatorios
• Estructura del dataLayer y el items array: ejemplos prácticos
• Configuración práctica en Google Tag Manager
• Errores comunes que rompen los informes de ingresos y cómo solucionarlos
• Validación y pruebas: flujo recomendado con GTM Preview y GA4 DebugView
• Especificación de tracking y entrega a desarrollo (contrato de datos)
• Perspectiva: cómo LG DataOne ayuda a auditar y automatizar la capa de datos
• Conclusiones y checklist de acciones inmediatas
• No todo lo que parece complejo lo es
• Automatiza la auditoría de tu capa de datos con LG DataOne
• Fuentes
• Preguntas frecuentes

👉 Si necesitas descargarte infografías sobre DataLayer ecommerce, descuentos en cursos y herramientas y mucho más puedes hacerlo aquí: descargar infografías y recursos

Eventos ecommerce imprescindibles y parámetros obligatorios

Una capa de datos ecommerce completa cubre once eventos, pero no todos pesan igual en el negocio. Cada uno se dispara en un momento concreto del recorrido de compra y transporta parámetros específicos que GA4 necesita para reconstruir el funnel.

• view_item_list: se dispara al mostrar una lista de productos (categoría, buscador, recomendaciones).
• select_item: cuando el usuario hace clic en un producto dentro de esa lista.
• view_item: al cargar la página de detalle de producto.
• add_to_cart / remove_from_cart: al añadir o quitar unidades del carrito.
• view_cart: al visualizar el contenido del carrito.
• begin_checkout: al iniciar el proceso de pago.
• add_shipping_info / add_payment_info: al completar los pasos de envío y pago.
• purchase: al confirmarse la transacción.
• refund: cuando se procesa una devolución total o parcial.

currency y value son los parámetros que más rompen informes cuando faltan. Sin currency, GA4 no puede sumar ingresos de forma fiable y los reportes de ingresos pueden quedar a cero o directamente descartarse. transaction_id cumple otra función: es la clave que permite deduplicar compras si el evento purchase llega a dispararse dos veces, algo que ocurre a menudo tras recargas de la página de confirmación.

No todos los proyectos necesitan los once eventos desde el primer día. Si el tiempo de desarrollo es limitado, prioriza este conjunto mínimo:

Con estos cuatro eventos ya tienes visibilidad de dónde se pierde conversión. El resto (view_item_list, select_item, view_cart, add_shipping_info, add_payment_info, refund) añade granularidad, pero no es bloqueante para lanzar.

Prueba GRATIS 4 MESES LG DataOne

Analiza mejor, decide antes y haz crecer tu negocio con LG DataOne. Empieza gratis con el cupón de descuento 4MESESGRATIS y obtén 4 meses gratis.

Probar 4 meses GRATIS

Estructura del dataLayer y el items array: ejemplos prácticos

Cada push de ecommerce sigue la misma forma: un objeto ecommerce que contiene los parámetros de evento y un array items con uno o varios objetos de producto. Antes de cualquier push nuevo, hay que vaciar el namespace anterior:

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "view_item",
  ecommerce: {
    currency: "EUR",
    value: 49.90,
    items: [{
      item_id: "SKU123",
      item_name: "Zapatilla running modelo X",
      price: 49.90,
      item_category: "Calzado",
      quantity: 1
    }]
  }
});

Ese ecommerce: null previo no es un capricho estético. Sin ese paso, los datos de un evento anterior pueden quedar «pegados» y contaminar el siguiente push, inflando cantidades o mezclando productos de eventos distintos.

Dentro de cada item, los campos más consistentes en la práctica son item_id, item_name, price, item_category, item_brand y quantity. Un debate habitual es si usar item_id o sku como identificador: GA4 espera item_id, así que si tu catálogo interno usa sku, mapea ese valor a item_id en el push en lugar de crear un campo paralelo. Otro punto de fricción es si price debe incluir impuestos. No hay una única respuesta correcta, pero sí una regla de oro: sea cual sea el criterio, debe ser el mismo en todos los eventos del funnel, o los márgenes calculados en GA4 no cuadrarán con el ERP.

Ejemplos completos que puedes adaptar directamente:

• add_to_cart: mismo objeto ecommerce que view_item, con event: "add_to_cart" y quantity reflejando las unidades añadidas.
• begin_checkout: incluye el array items completo del carrito y, si aplica, coupon, a nivel de evento.
• purchase: añade transaction_id, tax, shipping y coupon, además de currency y value con el importe total de la transacción.

Representar los productos como un array de items, con todos los campos relevantes en cada push, es lo que permite reconstruir el funnel completo y analizar el rendimiento por producto, en lugar de quedarte solo con el total agregado de ingresos.

Configuración práctica en Google Tag Manager para el dataLayer ecommerce

En GTM, todo empieza por las variables que leen el dataLayer. Lo habitual es crear una DataLayer Variable apuntando a ecommerce para capturar el objeto completo, y variables individuales solo cuando necesites un campo suelto fuera del árbol de ecommerce (por ejemplo, un user_id a nivel de página).

• Al configurar la variable de ecommerce, presta atención a la versión seleccionada: usar la versión 1 en lugar de la versión 2 evita fusiones recursivas que pueden inflar el recuento de items al leer arrays anidados.
• Los triggers deben ser de tipo Custom Event, con el nombre del evento en coincidencia exacta (no «contiene» ni «coincide con RegEx»), para evitar que un trigger mal ajustado dispare la tag con el evento equivocado.
• La tag de GA4 Event debe tener activada la opción de enviar datos de ecommerce, referenciando la variable del dataLayer como fuente de los parámetros.

En sitios construidos como aplicaciones de página única, el mayor riesgo no es la configuración de GTM en sí, sino el momento en que se dispara el push. Si el array de productos se renderiza de forma asíncrona, un push prematuro puede llegar con items vacío. Sincronizar el push con el momento exacto en que los datos de producto están disponibles, usando observers o callbacks del propio framework, evita ese problema de raíz. Nuestra guía sobre dataLayer en Google Tag Manager profundiza en cómo estructurar estas variables para catálogos grandes.

Consejo profesional: Antes de dar por buena una tag de GA4, comprueba en la variable de vista previa de GTM que el objeto ecommerce llega completo justo en el momento del evento, no dos segundos después. Un retraso de renderizado es la causa más habitual de items vacíos en producción.

Errores comunes que rompen los informes de ingresos y cómo solucionarlos

La mayoría de fallos de ecommerce en GA4 no son errores exóticos: son cuatro patrones que se repiten proyecto tras proyecto.

1. Falta el parámetro currency. GA4 no puede calcular ingresos sin una moneda de referencia, y esto puede dejar el reporte en cero incluso con transacciones reales registradas. Solución: incluir currency en absolutamente todos los eventos de ecommerce, no solo en purchase.
2. El array de productos persiste entre eventos. Si no limpias el namespace, un producto de una vista anterior puede aparecer mezclado en el siguiente evento. Solución: dataLayer.push({ ecommerce: null }) siempre antes de cada push nuevo.
3. Compras duplicadas. Recargas de la página de agradecimiento o problemas de caché pueden disparar purchase dos veces para la misma transacción. Solución: usar transaction_id como clave de deduplicación y adoptar controles adicionales en el dataLayer para evitar duplicados cuando sea necesario.
4. Pushes fuera de orden o con tipos incorrectos. Un price enviado como texto en lugar de número, o un evento add_to_cart que llega antes de que exista el producto, generan errores silenciosos.

Antes de dar por cerrada una implementación, comprueba lo siguiente en cada evento:

• El array items no está vacío ni contiene objetos incompletos.
• price y value son números, no strings.
• currency está presente en todos los eventos, no solo en los de conversión.
• El orden de disparo respeta la secuencia lógica del funnel.

Los precios enviados como cadena de texto o los impuestos mal incluidos en el valor total son fallos frecuentes que provocan discrepancias de ingresos, y una validación básica de tipos antes de publicar evita gran parte de estos problemas.

Prueba GRATIS 4 MESES LG DataOne

Analiza mejor, decide antes y haz crecer tu negocio con LG DataOne. Empieza gratis con el cupón de descuento 4MESESGRATIS y obtén 4 meses gratis.

Ver demos

Validación y pruebas: flujo recomendado con GTM Preview y GA4 DebugView

Validar una implementación de ecommerce exige recorrer el funnel completo, no solo comprobar un evento aislado. El flujo que mejor funciona en la práctica sigue tres pasos:

• Simula el funnel entero (listado, producto, carrito, checkout, compra) con GTM Preview activo, revisando que cada evento dispara la tag correspondiente.
• Usa Tag Assistant para confirmar que las variables del dataLayer capturan los valores esperados antes de que la tag los envíe.
• Abre GA4 DebugView y verifica que los parámetros llegan procesados correctamente al lado del servidor: value, currency, el array items y transaction_id en el caso de purchase.

Confiar solo en GTM Preview no es suficiente, porque DebugView puede revelar errores de esquema que pasan completamente desapercibidos en la vista previa de GTM, como parámetros que llegan con el tipo de dato equivocado o que GA4 descarta silenciosamente por no ajustarse al esquema esperado.

Si detectas discrepancias entre lo que ves en Preview y lo que llega a DebugView, revisa primero el orden de ejecución de las tags: una tag de GA4 que se dispara antes de que la variable del dataLayer tenga valor definitivo es la causa más habitual. También conviene inspeccionar el Model de GTM con google_tag_manager['GTM-XXXX'].dataLayer.get('ecommerce') desde la consola del navegador. Entender que GTM lee una versión procesada del dataLayer, no el array en bruto, ayuda a diagnosticar por qué un valor aparece «pegado» de un evento anterior cuando el patrón de limpieza falla.

Consejo profesional: Guarda capturas de DebugView de cada evento validado como referencia. Cuando alguien toque el código de producto meses después y algo se rompa, tendrás una base de comparación inmediata sin repetir todo el proceso de validación desde cero.

Nuestra guía sobre DebugView en GA4 detalla cómo leer cada parámetro en la interfaz de depuración con más ejemplos por evento.

DataLayer ecommerce: Especificación de tracking y entrega a desarrollo (contrato de datos)

La mayoría de errores de producción no nacen en el código, nacen en la comunicación entre analítica y desarrollo. Una especificación clara, entregada antes de escribir una sola línea, evita reinterpretaciones costosas.

Una spec mínima pero efectiva incluye:

• Lista exacta de eventos a implementar, con su nombre literal (sin variaciones de mayúsculas ni sinónimos).
• Estructura JSON completa de cada evento, con ejemplos copy-paste ya formateados.
• Condición exacta de disparo para cada evento (qué acción del usuario, en qué momento del ciclo de vida de la página).
• Criterios de aceptación: qué debe verse en DebugView para considerar el evento «correcto».

La ausencia de un contrato de datos claro entre analítica y desarrollo suele ser el fallo más costoso de todo el proceso, y entregar ejemplos copy-paste concretos reduce drásticamente los errores de interpretación. Añade versionado a la spec (v1.0, v1.1…) y comunica cualquier cambio de campo con antelación, no como una nota al margen de un despliegue. Si el equipo tiene capacidad, incorporar tests automatizados que verifiquen la forma del push antes de cada release añade una capa extra de seguridad frente a regresiones silenciosas.

Perspectiva: cómo LG DataOne ayuda a auditar y automatizar la capa de datos

La parte más subestimada de todo este trabajo no es escribir el push correcto una vez. Es mantenerlo correcto seis meses después, cuando desarrollo ha lanzado tres nuevas versiones del checkout y nadie ha vuelto a mirar DebugView. LG DataOne nació precisamente de ver ese patrón repetirse en proyectos reales: la implementación nace bien y se degrada sin que nadie lo note hasta que el informe de ingresos ya no cuadra con el ERP.

Nuestro DataLayer Checker monitoriza de forma continua los pushes de ecommerce, detecta campos ausentes (currency, transaction_id, items vacíos) y genera alertas antes de que el problema llegue al informe mensual. En lugar de auditar manualmente cada evento en DebugView cada vez que hay un despliegue, el sistema prioriza los fallos por impacto en ingresos, no por orden de aparición.

Esa automatización no sustituye la especificación de datos que has entregado a desarrollo. La complementa, comprobando en producción que la implementación sigue respetando ese contrato con el paso del tiempo.

Conclusiones y checklist de acciones inmediatas

Una capa de datos ecommerce fiable en GA4 depende de tres cosas: eventos core bien secuenciados, currency y transaction_id presentes siempre, y el patrón de limpieza antes de cada push.

• Implementa primero view_item, add_to_cart, begin_checkout y purchase.
• Valida cada evento en GTM Preview y confirma en DebugView antes de publicar.
• Entrega una spec versionada a desarrollo con ejemplos copy-paste.
• Revisa periódicamente que currency, value e items sigan llegando completos.

No todo lo que parece complejo lo es

La implementación de ecommerce en GA4 tiene fama de compleja, y en parte es un mito autoinfligido por la industria. Once eventos suenan a mucho trabajo hasta que te das cuenta de que comparten exactamente la misma estructura de objeto: ecommerce, items, y un puñado de parámetros que se repiten en casi todos. El verdadero riesgo no está en la curva de aprendizaje técnica, sino en la falta de disciplina operativa: nadie limpia el namespace, nadie versiona la spec, nadie revisa DebugView después del primer despliegue.

Lo que la mayoría de guías subestima es el coste de mantenimiento. Una implementación validada el día del lanzamiento y nunca vuelta a auditar es, en la práctica, una implementación que caducará en algún momento del año, normalmente coincidiendo con un rediseño del checkout que nadie comunicó a analítica. Priorizar el MVP (view_item, add_to_cart, begin_checkout, purchase) no es una concesión: es la decisión correcta incluso con recursos ilimitados, porque valida el flujo de ingresos antes de invertir tiempo en granularidad adicional que nadie va a mirar si el dato base ya está roto.

— Juan

DataLayer ecommerce: Automatiza la auditoría de tu capa de datos con LG DataOne

Todo lo anterior se puede hacer a mano: revisar DebugView evento por evento, comparar la spec con lo que realmente llega a producción, perseguir por qué un currency desapareció en el último despliegue. LG DataOne existe para que esa revisión no dependa de que alguien se acuerde de hacerla cada mes.

Si gestionas varios sitios o un catálogo que cambia con frecuencia, esa priorización automática ahorra horas de revisión manual en DebugView cada vez que desarrollo despliega cambios en el checkout.

Si quieres comprobar qué está fallando en tu propia implementación de ecommerce ahora mismo, puedes empezar por una auditoría de conversión y medición con el periodo de prueba gratuito de 14 días.

Fuentes

• Measure ecommerce | Google Analytics
• DataLayer Variable versions explained | Simo Ahava
• DataLayer deep dive | TaggingDocs
• GA4 enhanced ecommerce tracking — what the data layer needs to look like | Adnan Agic

Preguntas frecuentes sobre DataLayer ecommerce

¿Qué es la capa de datos en ecommerce?

Es el objeto JavaScript (dataLayer) que actúa de puente entre la web y Google Tag Manager, transportando eventos como purchase o add_to_cart junto con parámetros de producto, precio y moneda para que GA4 pueda procesarlos.

¿Qué eventos debe enviar como mínimo una tienda online a GA4?

Como mínimo viable, view_item, add_to_cart, begin_checkout y purchase, siempre con currency y value incluidos en cada uno para evitar informes de ingresos incorrectos.

¿Cuál es la mejor base de datos para un ecommerce?

No hay una única respuesta universal: depende del volumen de catálogo y transacciones. Lo que sí es constante es que, independientemente de la base de datos elegida, la capa de datos del frontend debe enviar la información de forma consistente a GA4 a través del dataLayer.

¿Para qué se utiliza el dataLayer en una tienda online?

Se utiliza para comunicar eventos de comportamiento (vistas de producto, adiciones al carrito, compras) desde el código de la web hacia Google Tag Manager, que a su vez los reenvía a GA4 y otras plataformas de analítica sin que haya que tocar el código de cada tag por separado.

¿Qué se entiende por datos de ecommerce en GA4?

Son los parámetros estructurados en torno al objeto ecommerce y su array items: moneda, valor de la transacción, identificador único de compra y los atributos de cada producto (nombre, precio, categoría, cantidad) que permiten reconstruir el funnel completo de compra.

Recomendaciones sobre DataLayer ecommerce

• Eventos recomendados GA4
• Eventos automáticos GA4
• Eventos sin código en GA4: valida analítica
• Optimizar checkout para ecommerce