GA4 para eCommerce: los eventos que de verdad necesitas medir

Antes de discutir estrategia de campañas con un cliente nuevo, reviso su implementación de GA4. Casi siempre encuentro el mismo patrón: la propiedad está creada, el purchase «dispara» y aparentemente todo funciona, pero cuando profundizas hay eventos duplicados, transacciones contadas dos veces, o simplemente faltan los eventos intermedios que explican por qué no se completa la venta. Los datos existen, pero no son fiables — y tomar decisiones de presupuesto sobre datos no fiables es peor que no tener datos, porque generan una falsa sensación de certeza.

Esto no es una guía de cómo instalar Google Tag Manager. Es la lista de lo que reviso y priorizo cuando audito (o monto desde cero) el ecommerce tracking de GA4 para un cliente, y los errores que más veces me he encontrado corrigiendo en cuentas ajenas.

Los eventos que realmente necesitas

Google documenta un conjunto de eventos recomendados para ecommerce en GA4, y de todos ellos hay cinco que considero mínimos innegociables:

• view_item — se dispara al ver una ficha de producto. Es el punto de partida del embudo.
• add_to_cart — la primera señal clara de intención de compra, y el punto medio del embudo estándar de ecommerce.
• begin_checkout — inicio del proceso de pago. Separa la fricción de «decidir comprar» de la fricción de «completar el pago».
• purchase — la conversión final. Es evento clave (conversión) por defecto en propiedades nuevas de GA4, y alimenta tanto los informes de monetización como las conversiones de Google Ads si tienes las cuentas vinculadas.
• refund — casi siempre olvidado, y crítico si vendes en sectores con devoluciones habituales (moda, por ejemplo): sin este evento, tu dato de ingresos está sistemáticamente inflado.

Con estos cinco eventos bien implementados tienes el esqueleto del embudo completo: puedes ver dónde se pierde el usuario entre «ver producto» y «añadir al carrito» (problema de producto) y entre «añadir al carrito» y «comprar» (problema de checkout). Sin la secuencia completa, según explica la propia documentación de Google, no puedes distinguir un problema de producto de un problema de checkout — solo ves que «algo falla», que no es accionable.

El error de intentar medir «todo» desde el primer día

GA4 admite eventos adicionales como view_item_list, select_item, add_to_wishlist, add_shipping_info o add_payment_info. Son útiles, pero no son el punto de partida. He visto implementaciones donde se prioriza configurar diez eventos secundarios y se descuida que el purchase principal tenga el transaction_id bien montado. Es al revés de como debería ser: primero los cinco eventos troncales, verificados y fiables, y solo después se añade granularidad.

El parámetro que evita ventas fantasma: transaction_id

Este es, con diferencia, el error más caro que he corregido en cuentas ajenas. Si el evento purchase no lleva un transaction_id único y estable, cada vez que un cliente recarga la página de «gracias por tu compra» (algo que ocurre más de lo que parece, sobre todo en móvil), GA4 registra una segunda venta idéntica que nunca existió. El resultado es un dato de ingresos y de número de transacciones inflado, de forma silenciosa, sin ningún error visible en ningún informe — simplemente números que no cuadran con lo que dice la pasarela de pago.

Lo primero que compruebo en cualquier auditoría es justamente esto: comparar el número de transacciones y el ingreso total que reporta GA4 contra el que reporta la pasarela de pago o el propio backoffice del ecommerce en el mismo periodo. Si no coincide, casi siempre es un problema de transaction_id mal implementado, no un problema de atribución.

Eventos duplicados: GTM y la etiqueta global a la vez

Otro patrón habitual: la propiedad de GA4 tiene el tag instalado directamente en el código de la web (etiqueta global) y, además, Google Tag Manager dispara el mismo evento por su cuenta. El resultado es que cada evento se cuenta dos veces, de forma consistente, lo cual es más difícil de detectar que un fallo puntual porque el dato «parece» coherente — simplemente está sistemáticamente duplicado. La comprobación es sencilla con la extensión Tag Assistant de Google o con el modo DebugView de GA4: si ves el mismo evento disparándose dos veces en la misma interacción, tienes una fuente duplicada que hay que eliminar.

Dimensiones personalizadas: verlas en tiempo real no es lo mismo que poder informarlas

GA4 no registra automáticamente los parámetros personalizados que envíes en tus eventos como dimensiones utilizables en informes. Si mandas un parámetro como «tipo_de_cliente» o «categoría_producto» en el dataLayer, tienes que darlo de alta explícitamente en Admin → Definiciones personalizadas para poder usarlo en informes o en Looker Studio. Es habitual ver implementaciones donde el parámetro sí llega correctamente (se ve en DebugView) pero nadie lo ha registrado como dimensión, así que meses después, cuando alguien lo necesita para un informe, resulta que no hay datos históricos utilizables — se han estado enviando pero no capturando.

Consistencia de moneda si vendes en varios mercados

Si tu ecommerce vende en distintos países con distinta divisa, usar siempre el mismo código de moneda en el parámetro currency del evento (o gestionar bien la conversión antes de enviarlo) evita que GA4 sume peras con manzanas al calcular ingresos totales. Es un detalle que parece menor hasta que alguien reporta una cifra de facturación agregada que no tiene sentido con ningún tipo de cambio real.

add_shipping_info y add_payment_info: diagnóstico fino del checkout

Los cinco eventos troncales te dicen si el problema está en producto o en checkout, pero no en qué paso concreto del checkout. Para eso, dos eventos adicionales marcan una diferencia real: add_shipping_info (cuando se completan los datos de envío) y add_payment_info (cuando se introduce el método de pago). Con estos dos, además de begin_checkout y purchase, puedes ver si la fuga se concentra en «rellenar datos de envío» o en «el paso de pago» — que suelen tener causas y soluciones completamente distintas. Si te interesa el análisis de checkout en detalle, más allá del tracking, tengo un artículo específico sobre dónde se abandona el carrito de verdad que complementa esto desde el lado de la optimización, no solo de la medición.

Estos dos eventos suelen quedarse fuera de las implementaciones «básicas», precisamente porque no son obligatorios para que el purchase funcione. Pero son los que más valor aportan cuando ya tienes el embudo principal resuelto y necesitas afinar dónde actuar dentro del propio checkout.

Client-side vs server-side: una decisión que no es solo técnica

Todo lo descrito hasta aquí funciona con tracking del lado del cliente (el navegador envía los eventos directamente a GA4), que es la implementación estándar y la que recomiendo como punto de partida para la inmensa mayoría de negocios. Existe una alternativa de tracking del lado del servidor, que mejora la fiabilidad del dato frente a bloqueadores de anuncios y restricciones de navegador, pero añade complejidad de infraestructura y mantenimiento que no todos los negocios necesitan todavía. No es una decisión que tomaría antes de tener resuelto lo básico: no tiene sentido migrar a una arquitectura más compleja si el transaction_id del tracking actual ni siquiera está bien implementado.

Consent Mode: la variable que no controlas del todo

Si operas en la Unión Europea, el consentimiento de cookies afecta directamente a cuántos datos puedes medir: sin una implementación correcta de Consent Mode, una parte significativa de las visitas (las que rechazan cookies analíticas) queda fuera de tus informes, no porque no existan, sino porque no se pueden medir con las herramientas estándar. Es un tema con suficiente profundidad como para tratarlo aparte, pero conviene tenerlo en cuenta como parte del diagnóstico: si tu volumen de eventos parece bajo comparado con el tráfico real de la web, la tasa de rechazo de cookies puede ser parte de la explicación, no solo un problema de implementación.

Cómo verifico que una implementación es fiable antes de confiar en ella

1. DebugView de GA4, navegando yo mismo por la web con el modo debug activado, para ver en tiempo real qué eventos se disparan y con qué parámetros, en cada paso del embudo.
2. Una compra de prueba real (o lo más cercana posible a real) para verificar que el purchase se dispara una sola vez, con transaction_id único, y que recargar la página de confirmación no genera una segunda transacción.
3. Comparar el ingreso total de GA4 contra el backoffice del ecommerce en un periodo cerrado (por ejemplo, el mes anterior completo), para detectar duplicados o eventos que faltan.
4. Revisar Definiciones personalizadas en Admin, para confirmar que los parámetros que se están enviando también se pueden usar en informes.

El array de items: por qué un purchase mal formado no siempre «se nota»

El evento purchase en GA4 no lleva solo un valor total y una moneda: lleva un array de items, donde cada producto de la transacción va con su propio id, nombre, categoría, precio y cantidad. Es habitual que este array llegue incompleto — por ejemplo, con el precio unitario pero sin la cantidad correcta, o con productos que no coinciden con lo que realmente había en el carrito porque el dataLayer se generó desde una versión en caché de la página en vez de desde el estado real del pedido. El síntoma no es un error visible: es que el ingreso total del purchase «cuadra» pero los informes de rendimiento por producto no tienen sentido (productos que aparecen vendidos en cantidades imposibles, o que faltan por completo). Si vas a apoyarte en GA4 para decisiones de catálogo, no solo de inversión en ads, este nivel de detalle en el array de items importa tanto como el transaction_id.

Value vs revenue: un matiz que genera confusión en el reporting

En el evento purchase, el parámetro value debería reflejar el importe total de la transacción, coherente con la suma de price × quantity de los items enviados. Un fallo que he visto repetirse: enviar el value con el importe final ya con impuestos y envío incluido, pero enviar los items con precios sin impuestos, o al revés. GA4 no lo va a marcar como error — simplemente vas a tener un ingreso agregado que no se corresponde exactamente con la suma de tus productos, y cuando alguien intente reconciliar ese dato con la contabilidad real del negocio, aparecerán diferencias que cuesta explicar si no se documentó el criterio desde el principio.

Vincular GA4 y Google Ads: por qué las conversiones importadas pueden no coincidir con tu purchase

Si vinculas tu propiedad de GA4 con Google Ads e importas purchase como conversión, es habitual que el número de conversiones que ves en Google Ads no coincida exactamente con el número de transacciones que ves en GA4. Las causas más frecuentes no son un error de configuración, sino diferencias de criterio entre plataformas: las ventanas de atribución no siempre son iguales, Google Ads puede aplicar su propio modelo de atribución (basado en datos, por ejemplo) distinto al «último clic» que ves por defecto en algunos informes de GA4, y los tiempos de procesamiento de datos no son idénticos entre ambas herramientas. Antes de asumir que hay un fallo de tracking cuando estos números no cuadran al céntimo, merece la pena revisar si la diferencia se explica por estos motivos de criterio antes de ponerte a depurar código que probablemente no tiene ningún error.

Informes de exploración: para ver la fuga real, no solo el resumen

Los informes estándar de GA4 (la sección de Monetización, por ejemplo) te dan una foto agregada, útil para seguimiento pero limitada para diagnóstico. Cuando quiero ver exactamente en qué paso del embudo se concentra la fuga — y para qué segmento de usuarios, dispositivo o fuente de tráfico — uso el informe de exploración de embudo, construido manualmente con la secuencia de eventos que interesa (view_item → add_to_cart → begin_checkout → purchase). A diferencia del informe estándar, aquí puedes segmentar por dispositivo o canal de adquisición dentro del propio embudo, lo cual suele revelar que la fuga no es homogénea: es habitual, por ejemplo, que la caída entre begin_checkout y purchase sea mucho más pronunciada en tráfico de Meta Ads que en tráfico de búsqueda orgánica, simplemente porque llegan con niveles de intención de compra distintos — y eso cambia por completo qué se debería optimizar y dónde.

Cupones y descuentos: el parámetro que casi nadie envía

El evento purchase admite un parámetro coupon, tanto a nivel de transacción como a nivel de item, que casi nunca veo implementado. Sin él, no puedes responder con datos a una pregunta habitual de negocio: qué porcentaje de tus ventas se están cerrando con descuento, y si ese porcentaje está subiendo con el tiempo (señal de que tu base de clientes se está acostumbrando a comprar solo cuando hay promoción, algo que afecta directamente al margen real, no solo al volumen de ventas). Es un parámetro barato de añadir si ya tienes el resto de la implementación resuelta, y aporta una capa de análisis que de otra forma solo se puede reconstruir a mano cruzando datos con el backoffice.

Checklist rápido antes de dar por buena una implementación

1. ¿Están los cinco eventos troncales (view_item, add_to_cart, begin_checkout, purchase, refund) disparándose correctamente en DebugView?
2. ¿Lleva el evento purchase un transaction_id único que no se duplica al recargar la página de confirmación?
3. ¿Coincide el ingreso total de GA4 con el del backoffice o la pasarela de pago en un mes cerrado?
4. ¿Hay algún tag duplicado entre GTM y una etiqueta global instalada directamente en el código?
5. ¿Están registradas en Definiciones personalizadas las dimensiones que estás enviando y necesitas usar en informes?
6. ¿Es consistente el parámetro de moneda si vendes en más de un mercado?

Si la respuesta a cualquiera de estas preguntas es «no lo sé», ese es literalmente el primer punto de la auditoría, antes de discutir nada de estrategia de campañas o presupuesto. No tiene sentido optimizar decisiones de inversión sobre datos que no has verificado.

Lo que esto no resuelve

Tener el ecommerce tracking bien montado en GA4 te da datos fiables sobre qué pasa en tu web. No te dice, por sí solo, qué canal de marketing merece el crédito de cada venta — eso depende del modelo de atribución que uses, y es una capa de complejidad distinta que conviene tratar por separado una vez que la base de datos es sólida. Construir sobre datos poco fiables, sea cual sea el modelo de atribución que elijas después, solo multiplica el error.

Si ya tienes el tracking resuelto y quieres ver cómo lo traduzco en reportes para cliente, tengo un artículo sobre dashboards de Paid Media en Looker Studio. Y si el problema de fondo es la configuración de conversiones en Google Ads a partir de estos eventos, puedes ver cómo lo trabajo en gestión de Google Ads.