¿Qué eventos de GA4 debe medir tu tienda online?

Por qué una analítica mal configurada lleva a malas decisiones en un e-commerce, qué eventos de comercio electrónico recomienda Google para GA4, qué datos deben viajar con cada uno y cómo comprobar que funcionan.

Por , Desarrollador full stack

En esta página

Una tienda online genera datos con cada visita: qué productos se miran, cuáles se añaden al carrito, dónde se abandona la compra y qué campaña trajo a quien acabó pagando. Con ellos se decide en qué anuncios invertir y qué parte del pago hay que arreglar.

El problema es que una analítica mal montada no avisa. Los informes siguen mostrando cifras, gráficos y tendencias, solo que no corresponden a lo que pasa en la tienda. Y una cifra equivocada con aspecto de fiable es peor que no tener cifra, porque invita a actuar.

Google Analytics 4 (GA4) tiene un conjunto de eventos recomendados para comercio electrónico, documentado en su guía oficial de medición de e-commerce. Este artículo los traduce a lenguaje de negocio: qué mide cada uno, qué datos tienen que acompañarlo y qué se rompe cuando falta.

¿Qué decisiones se toman mal con una analítica mal montada?

Los fallos más comunes se repiten en tiendas de todos los tamaños:

  • Ingresos duplicados. Si la compra se registra al cargar la página de gracias y esa página se recarga, se comparte o se abre desde el historial, la venta puede contarse dos veces. El remedio es el parámetro transaction_id, obligatorio en el evento de compra: con un identificador único por pedido, GA4 puede reconocer que se trata del mismo pedido. Sin él, los ingresos del informe crecen más que los de la caja.
  • Moneda ausente o equivocada. El valor de una venta sin currency es un número sin unidad. Una tienda que cobra en pesos colombianos y envía los importes sin moneda, o con la de otro país, acaba con informes de ingresos que no cuadran con nada.
  • Embudo roto. Si se mide el carrito y la compra pero no el inicio del pago (begin_checkout), no hay forma de saber si la gente abandona en el carrito o en el formulario de envío. Son dos problemas distintos, y el informe los mezcla.
  • Campañas sin atribuir. Las ventas aparecen, pero como tráfico directo o sin asignar. El boletín que funcionó y el anuncio que no se ven iguales, y el presupuesto se reparte a ciegas.

El embudo de una tienda, evento por evento

Cada paso del recorrido de compra tiene su evento recomendado. Puestos en orden, forman un mapa del embudo:

Momento Evento Qué te permite saber
Ve un listado o una categoría view_item_list Qué listados reciben atención
Elige un producto del listado select_item Qué posiciones y productos atraen el clic
Abre la ficha del producto view_item Qué productos se miran y cuáles se compran
Lo añade al carrito add_to_cart La intención real de compra por producto
Lo guarda para después add_to_wishlist Interés que todavía no se convierte
Revisa el carrito view_cart Cuánta gente llega a plantearse pagar
Quita algo del carrito remove_from_cart Qué productos se descartan al final
Empieza el pago begin_checkout El punto donde empieza el proceso de pago
Elige el envío add_shipping_info Qué opción de envío se elige (shipping_tier)
Elige el medio de pago add_payment_info Qué medio se usa (payment_type)
Completa la compra purchase Ingresos, pedidos y productos vendidos
Se devuelve el pedido refund Ingresos que hay que descontar

Las promociones tienen dos eventos propios: view_promotion, cuando se muestra un banner o una oferta, y select_promotion, cuando alguien hace clic en ella. Con los dos sabes si la promoción de la portada mueve ventas o solo ocupa espacio.

No hace falta implementarlo todo el primer día. Lo mínimo para tener un embudo legible es view_item, add_to_cart, begin_checkout y purchase. Cada evento que añadas después afina el diagnóstico de un tramo concreto.

¿Qué datos viajan con cada evento?

El nombre del evento dice qué pasó. Los parámetros dicen cuánto, de qué y en qué condiciones.

Parámetros del evento. Los importantes son value (el valor) y currency (la moneda): Google recomienda enviar siempre la moneda cuando se envía un valor. La compra y el reembolso exigen además transaction_id. Opcionalmente se pueden enviar coupon, tax y shipping. En los eventos de promoción se identifican con creative_name, creative_slot, promotion_id y promotion_name.

El array items. Es la lista de productos implicados en el evento, y aquí está buena parte del valor del informe:

  • Cada artículo necesita item_id o item_name. Se recomiendan los dos.
  • Si no se indica quantity, GA4 asume 1.
  • Caben hasta 200 artículos por evento y hasta 27 parámetros personalizados por artículo.
  • Además del identificador y el nombre, cada artículo admite price, quantity, item_brand, item_variant, item_category (y hasta item_category5 para jerarquías), discount, coupon, affiliation, index, item_list_id, item_list_name, location_id, promotion_id y promotion_name.

La recomendación de Google es enviar todo parámetro del que tengas datos, aunque sea opcional. Cuesta algo más al implementar, y a cambio puedes cruzar las ventas por marca, por categoría o por variante sin volver a tocar el código. Lo que no se envió no se puede recuperar después.

Un ejemplo: el evento de compra

Así se ve un purchase enviado con gtag.js en la página de confirmación del pedido:

gtag('event', 'purchase', {
  transaction_id: 'PED-10482',
  currency: 'COP',
  value: 245000,
  shipping: 12000,
  coupon: 'BIENVENIDA',
  items: [
    {
      item_id: 'CAM-021',
      item_name: 'Camiseta de algodón',
      item_variant: 'azul',
      item_category: 'Ropa',
      price: 85000,
      quantity: 2
    },
    {
      item_id: 'GOR-007',
      item_name: 'Gorra',
      item_category: 'Accesorios',
      price: 75000,
      quantity: 1
    }
  ]
});

Tres cosas que conviene mirar: el transaction_id sale del número de pedido real de la tienda, no se inventa en el navegador; la moneda va explícita; y cada producto lleva identificador, nombre, precio y cantidad.

Los reembolsos usan el evento refund con el mismo transaction_id del pedido original. Si la devolución es total, basta con el identificador. Si es parcial, se añade items con el item_id y la quantity de lo que se devolvió. Sin este evento, los ingresos del informe se quedan con ventas que ya no existen.

¿Cómo comprobar que funciona?

Un evento que no se ha comprobado es una suposición. GA4 tiene dos herramientas para verificarlo antes de fiarse de los informes:

  • El modo de depuración (DebugView). Muestra los eventos de tu sesión de prueba en el orden en que ocurren, con todos sus parámetros. Haz un recorrido completo: abre un listado, entra en un producto, añádelo al carrito, inicia el pago y completa una compra de prueba. Revisa que cada evento aparece y que lleva lo que debe: moneda, valor, identificador de transacción y productos.
  • El informe en tiempo real. Confirma que los eventos llegan a la propiedad correcta y que no se disparan dos veces.

Hay pruebas que merecen hacerse a propósito: recargar la página de gracias, comprar con un cupón, comprar varias unidades del mismo producto y comparar el total del informe con el del pedido en la tienda. Si no cuadran, lo sabrás antes de tomar decisiones con esos datos.

Repite la comprobación cada vez que cambie el proceso de compra, el tema o la plataforma: es ahí donde un evento deja de enviarse sin que nadie lo note. Y como cada script que se añade a una tienda tiene un coste, conviene vigilar también que la medición no ralentice las páginas: está explicado en qué son los Core Web Vitals.

Consentimiento y datos personales

Medir el comportamiento de los visitantes implica tratar datos, y eso tiene reglas. Google ofrece el modo de consentimiento (Consent Mode), que permite ajustar el comportamiento de sus etiquetas según lo que la persona haya aceptado en tu aviso de cookies. Cada país tiene además su normativa: en Colombia, la Ley 1581 de 2012 regula el tratamiento de datos personales, y otros mercados tienen la suya.

Qué aviso necesitas y cómo configurarlo depende de dónde vendes y a quién, y es una pregunta para un asesor legal, no para un artículo de blog. Sí hay una regla técnica que vale en cualquier caso: no envíes a GA4 datos que identifiquen a personas, como correos o nombres, ni en los parámetros de los eventos ni en las URL.

¿Cómo llegan bien etiquetadas las campañas?

Los eventos cuentan qué pasa dentro de la tienda. Para saber qué campaña trajo cada venta, las visitas tienen que llegar con su origen declarado, y para eso están los parámetros UTM. Cómo funcionan y qué convención de nombres seguir está en qué son los parámetros UTM.

Con el generador de enlaces UTM armas los enlaces de tus anuncios, boletines y publicaciones con la fuente, el medio y la campaña bien escritos, y te avisa de lo que partiría los informes de GA4: mayúsculas, espacios o un medio que falta. Así, cuando una compra llegue con su purchase completo, también llegará con el nombre de la campaña que la provocó.


Una analítica de e-commerce bien montada no es la que tiene más eventos, sino la que cuenta cada pedido una vez, en la moneda correcta, con sus productos y su origen. Eso se configura una vez, se comprueba con una compra de prueba y se revisa cada vez que la tienda cambia.

¿Hablamos de e-commerce headless & cotizadores?

Cuéntanos tu caso y te respondemos con una primera lectura del alcance en menos de 24 horas hábiles.

Respondemos en menos de 24 horas hábilesBogotá · UTC−5

Escríbenos por WhatsApp (se abre en una pestaña nueva)