Configurar ecommerce en GA4: la checklist del evento purchase

Configurar ecommerce en GA4 consiste en reportar el momento de la venta como un único evento purchase, con cuatro parámetros obligatorios (value, currency, transaction_id, items) y un disparador que no pueda contar el mismo pedido dos veces. El trabajo no acaba cuando el evento se envía. Acaba cuando DebugView muestra exactamente un evento, cuando los ingresos del informe cuadran con los pedidos del backend 24-48 horas después y cuando el desglose de canales cuenta la misma historia que tus plataformas publicitarias. Esta lista comprueba esos tres umbrales.

¿Qué es exactamente la medición de ecommerce en GA4?

La medición de ecommerce en GA4 consiste en reportar cada paso del recorrido de compra con nombres de evento y parámetros estándar. Trátalo como un contrato, no como una etiqueta: los informes de GA4 esperan exactamente esos nombres. Si la nomenclatura se desvía, el evento llega igual, pero los informes de ingresos, productos y conversiones se quedan vacíos.

• view_item: se vio una ficha de producto. Mide el interés en el producto.
• add_to_cart: producto añadido al carrito. Aquí nace el denominador del abandono de carrito.
• begin_checkout: entrada al proceso de pago. La pérdida dentro del flujo de pago se ve aquí.
• purchase: pedido completado. Es la única fuente de ingresos, ROAS y desglose de canales.

Los cuatro aportan, pero solo el último decide la inversión publicitaria. Si vas justo de tiempo, deja purchase impecable primero y completa el resto después.

¿Qué parámetros son obligatorios en el evento purchase?

Cuatro parámetros sostienen todo el evento: value (importe del pedido), currency (código ISO), transaction_id (identificador único del pedido) e items (array de productos). Si falta uno, GA4 registra el evento pero el informe correspondiente queda en blanco: sin currency no hay cálculo de ingresos, sin transaction_id no hay deduplicación y sin items no existe rendimiento de producto.

• value: el importe total. Decide si incluye impuestos y envío y mantén esa decisión idéntica a la del backend, o cada comparación acabará en discusión.
• currency: código ISO 4217 (EUR, USD, MXN), enviado a nivel de evento. En tiendas multidivisa cada evento lleva su propio código.
• transaction_id: único por pedido. Nunca lo generes al azar: derívalo del número de pedido del backend para que la conciliación sea posible.
• items: por producto, al menos item_id e item_name. price, quantity, categoría y variante son recomendados y dan profundidad a los informes de producto.

¿Por qué se cuenta el mismo pedido dos veces?

Los duplicados nacen de colgar el evento de compra de la página de gracias. Una recarga, la vuelta con el botón atrás o un enlace de confirmación compartido lo disparan de nuevo. GA4 descarta un segundo evento con el mismo transaction_id dentro de una ventana de 24 horas, pero esa protección se cae si el identificador se genera al azar en cada disparo, y los ingresos se inflan.

1. Deriva transaction_id del número de pedido del backend. Nada de números aleatorios, marcas de tiempo o identificadores de sesión.
2. Dispara el evento solo con el pago confirmado y desde un único punto. Átalo al estado del pedido, no a la carga de la página.
3. Guarda el identificador enviado en el almacenamiento de sesión del navegador y bloquea el segundo envío. Es el seguro más barato contra recargas.
4. Si envían a la vez el navegador y el servidor, apaga uno o asegúrate de que ambos usan el mismo transaction_id. De lo contrario, dos registros parecen dos pedidos.

¿Cómo afectan las devoluciones y cancelaciones a los ingresos?

GA4 no descuenta las devoluciones por su cuenta. Cuando se devuelve o se cancela un pedido hay que enviar además un evento refund. Si no lo haces, los ingresos de GA4 se separan poco a poco del neto del backend y cualquier cálculo de ROAS construido encima queda optimista. En categorías con mucha devolución, como moda y calzado, esa desviación cambia decisiones de forma directa.

• Devolución total: el mismo transaction_id del pedido original, el importe devuelto como value positivo y currency. No envíes valores negativos.
• Devolución parcial: el mismo transaction_id junto a un array items con solo los productos y cantidades devueltos. GA4 resta únicamente esas líneas.
• Cancelación: una cancelación antes del envío que revierte ingresos debe tratarse como devolución. La contabilidad puede separarlas, la medición no.
• Desfase: las devoluciones llegan días después de la venta. Por eso el ROAS de ayer y el del mes pasado no tienen la misma madurez: compara periodos con el mismo desfase.

¿Cómo se alinea el desglose de canales con las decisiones publicitarias?

No basta con contar el número correcto de compras por el importe correcto. Cada compra debe atribuirse además al canal correcto. Cuando el desglose se rompe, el total de ingresos parece bueno pero la distribución es falsa, y el presupuesto se mueve al canal equivocado. La causa más habitual es una pasarela de pago que parte la sesión y se apunta la conversión.

• Exclusión de referencias: añade pasarelas de pago y dominios de autenticación 3-D Secure a la lista de referencias no deseadas. Puedes definir hasta 50 dominios por flujo de datos.
• Medición entre dominios: si carrito, pago y confirmación viven en dominios distintos, decláralos como un mismo recorrido. Si no, cada salto crea una sesión y una fuente nuevas.
• Disciplina de UTM: activa el etiquetado automático en canales de pago y, donde etiquetes a mano, elige utm_source y utm_medium de un vocabulario fijo. La escritura libre fragmenta el desglose.
• Qué significa directo: directo casi nunca es alguien tecleando tu dirección; suele ser falta de información. Un peso anormalmente alto del tráfico directo es la primera señal de un problema de configuración.

Incluso con el desglose arreglado, GA4 y la plataforma publicitaria no cuadrarán uno a uno: los modelos de atribución, las ventanas de conversión y la definición de clic difieren. Analizamos ese hueco en detalle en la discrepancia de conversiones entre GA4 y Google Ads. Para la parte técnica de la pérdida de señal, mira el seguimiento del lado del servidor.

¿Qué validas, paso a paso, cuando la configuración está lista?

Valida en tres capas: en el momento del evento con DebugView, tras el procesamiento a las 24-48 horas y a nivel de canal. No te saltes el orden, porque una configuración impecable en DebugView puede seguir equivocada en la capa de informes por devoluciones ausentes o una fuente rota. Recorre estos seis pasos en secuencia.

1. DebugView: haz un pedido de prueba real y confirma que ves exactamente un evento purchase. Ábrelo y comprueba que value, currency, transaction_id e items están rellenos.
2. Coincidencia de identificador: ¿el transaction_id del evento es carácter por carácter el número de pedido del backend? Corrige ahora prefijos o diferencias de formato.
3. Prueba de recarga: recarga la página de confirmación y vuelve con el botón atrás. No debe enviarse un segundo evento purchase.
4. Prueba de devolución: devuelve parcialmente el pedido de prueba y verifica que el evento refund lleva los productos correctos.
5. Conciliación de informes: espera 24-48 horas y compara transacciones e ingresos con los pedidos del backend del mismo rango de fechas. En la práctica unos pocos puntos de diferencia son normales; una brecha persistente y creciente es un problema de implementación.
6. Control de canal: revisa fuente y medio de las sesiones que compran. Si aparece una pasarela de pago como fuente, la lista de exclusiones está incompleta.

¿Cómo se convierten unos datos limpios de GA4 en decisiones?

Llegados aquí tienes una tabla fiable de ingresos y canales, pero las decisiones siguen siendo manuales. Ahí entra Ads Sensor: une los datos de tráfico, conversión y desglose de canales de GA4 con la inversión de Meta Ads, Google Ads, TikTok Ads y Criteo en un solo panel, lee las campañas con inteligencia artificial y produce acciones priorizadas con su razonamiento. Seamos claros: Ads Sensor no configura tu GA4, lee el GA4 que ya tienes. La configuración la cierras tú con esta checklist.

• Tabla unificada: la inversión de plataforma junto a los ingresos y el desglose de canales de GA4 en una pantalla.
• Análisis con IA: riesgos y oportunidades por campaña, cada recomendación con su razonamiento.
• Aprobar y aplicar: las recomendaciones aceptadas se aplican por las API de las plataformas y el antes y después se registra automáticamente.
• Vigilancia de anomalías: desviaciones de inversión, conversiones e ingresos monitorizadas las 24 horas, con umbrales ajustables.
• Modo informe: informe mensual presentable al cliente para agencias.

Cuando la checklist esté completa, el siguiente paso es que los datos generen decisiones. Puedes unirte a la beta, conectar tus cuentas y ver el primer análisis.