¿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 Javier Tenjo, 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
currencyes 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_idoitem_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 hastaitem_category5para jerarquías),discount,coupon,affiliation,index,item_list_id,item_list_name,location_id,promotion_idypromotion_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.