Si solo medís purchase, te perdés casi toda la historia. Yo resumiría esta guía así: en GA4 conviene usar los eventos de e-commerce que ya existen, sumar eventos personalizados solo cuando muestran fricción o intención, implementarlos con GTM cuando hace falta dataLayer, y validar todo antes de mirar reportes.
En una tienda online, esto me ayuda a responder preguntas concretas: por qué abandonan el carrito, qué canal trae consultas, qué parte del checkout falla y qué interacción previa empuja una venta. El punto no es sumar más eventos. El punto es medir lo justo, con nombres prolijos, parámetros útiles y datos limpios.
Lo más importante, en corto:
view_item, add_to_cart, begin_checkout y purchase.whatsapp_click, instagram_dm_click o coupon_applied.items, value o transaction_id, lo haría con Google Tag Manager.currency: "ARS" junto con value, usando números como 1200.50.Qué me deja esta guía en la práctica:
view_item y purchaseEn pocas palabras: GA4 por sí solo muestra el inicio y el final; los eventos bien definidos muestran lo que pasa en el medio.
Con los casos de uso ya definidos, el paso que sigue es pasarlos a eventos medibles. Antes de tocar la implementación, conviene dejar por escrito qué vas a medir, para qué y cómo lo vas a leer. Sin ese mapa, pasa lo de siempre: eventos duplicados, nombres mezclados y datos que después no sirven para tomar decisiones.
Un plan de medición une objetivos, eventos, parámetros y reportes. No hace falta armar algo gigante: alcanza con una tabla simple y un criterio claro. La idea es priorizar solo lo que mueve decisiones de negocio.
Cada evento que implementes debería contestar una pregunta de negocio concreta. Por ejemplo, "¿Por qué se abandona el carrito?" se puede traducir en view_cart con los parámetros value, currency e items. Y "¿Cuántos usuarios consultan por WhatsApp o Instagram antes de comprar?" se puede llevar a contact_click con support_channel = whatsapp o instagram, más page_location.
Dicho simple: cada fila del plan debería servir para una decisión puntual, no para meter ruido.
| Objetivo de negocio | Evento GA4 | Parámetros clave | Uso en reportes |
|---|---|---|---|
| Reducir abandono de carrito | view_cart | value, currency, items | Métrica (value) |
| Medir ingresos y volumen de ventas | purchase | transaction_id, value, currency, items, coupon | Evento clave / ingresos |
| Detectar fricción en el checkout | begin_checkout, add_shipping_info, add_payment_info | shipping_tier, payment_type, coupon, items | Exploración de embudo |
| Analizar interés en productos | view_item, add_to_cart | item_id, item_name, price, item_variant | Dimensión (ID de ítem) |
| Rastrear contacto por canales sociales | contact_click | support_channel (whatsapp/instagram), page_location | Dimensión (canal) |
| Identificar demanda no satisfecha | search | search_term | Dimensión personalizada (search_term) |
Un punto que suele pasarse por alto: los parámetros personalizados no aparecen en los reportes estándar de GA4 hasta que los registres como dimensiones o métricas personalizadas desde el panel de administración. Además, ese cambio suele tardar cerca de 24 horas en verse reflejado, así que conviene hacerlo desde el arranque.
Después de definir qué medir, aparece otro filtro igual de importante: cómo lo vas a nombrar.
GA4 distingue entre mayúsculas y minúsculas. Por eso, lo mejor es usar siempre minúsculas, formato snake_case, sin espacios y sin caracteres especiales, con nombres consistentes.
También hay límites que conviene tener presentes desde el inicio:
Además, definí un criterio único para item_id, item_name e item_category. Si no lo hacés, una diferencia mínima en el formato puede partir los datos en varias versiones del mismo producto y complicarte el análisis después.
El filtro para sumar un evento al plan es bastante directo: ¿este dato cambia una decisión? Si la respuesta es no, mejor no implementarlo.
Antes de crear un evento personalizado, revisá si esa interacción ya está cubierta por un evento recolectado automáticamente, uno de medición mejorada o un evento recomendado. En e-commerce, conviene apoyarse primero en nombres estándar como view_item_list, select_item, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info y purchase, porque hacen más simples los reportes nativos de GA4.
Los eventos personalizados tienen sentido cuando suman una decisión nueva que los estándar no cubren. Si vas a medir canales de contacto, por ejemplo, usá contact_click con support_channel y page_location.
Con este mapa ya armado, el siguiente paso es llevarlo a GA4 y Google Tag Manager para implementarlo.
Flujo de Implementación de Eventos en GA4 con GTM
Podés crear eventos simples en GA4 o armar eventos más completos con GTM. La elección depende de la interacción que querés medir. Para lo básico, arrancá en GA4. Cuando necesitás datos del dataLayer, conviene pasar a GTM.
La interfaz de GA4 te deja crear un evento a partir de page_view y page_location cuando una persona llega a la página de agradecimiento, sin tocar el sitio. Es una salida práctica para casos puntuales.
El límite aparece en e-commerce. Si necesitás usar el array items o datos del carrito, GA4 sola se queda corta. En ese escenario, GTM es la mejor opción.
GTM va mejor cuando los eventos necesitan datos de producto, carrito u orden. El flujo se divide en tres partes:
dataLayer como ecommerce.items, ecommerce.value y ecommerce.transaction_id.dataLayer reciba el evento que corresponde.Antes de publicar, validá con el modo Preview de GTM y el DebugView de GA4. Así confirmás que cada evento se dispara con los parámetros correctos y evitás duplicados.
La tabla siguiente resume eventos personalizados para canales de contacto:
| Evento | Propósito | Parámetros clave | Trigger típico |
|---|---|---|---|
whatsapp_click | Clic en botón o ícono de WhatsApp | link_url, button_location | Clic en enlace wa.me |
instagram_dm_click | Clic para escribir por Instagram | link_url, campaign_id | Clic en botón de contacto de Instagram |
cart_recovery_click | Clic desde un flujo de recuperación | source, recovery_type | Clic en enlace de mensaje de recuperación |
Para los eventos de e-commerce estándar, usá los nombres que Google recomienda, como view_item y purchase. Eso habilita los reportes nativos de GA4 sin tener que hacer nada extra.
Cuando el clic pasa fuera del sitio, la atribución depende de medirlo bien en GTM.
En tiendas que usan Burbuxa, seguir estos clics en GA4 ayuda a atribuir ventas, consultas y recuperaciones de carrito. La lógica en GTM es la misma: creá un trigger de clic en enlaces filtrado por link_url o por dominio de destino - wa.me para WhatsApp, ig.me para Instagram - y vinculalo con un tag de GA4 que tenga el nombre de evento que corresponda.
Para flujos de recuperación, el evento cart_recovery_click con los parámetros source y recovery_type te deja ver desde qué automatización llegó el clic.
Evitá URLs únicas o valores demasiado variables. Si no, GA4 puede agrupar ese exceso en (other) y perdés precisión.
Con los tags ya activos, el paso que sigue es validar que cada evento llegue con los parámetros correctos. Antes de ponerte a mirar reportes, asegurate de que los datos entren limpios a GA4. Para eso, usá Preview de GTM y DebugView para revisar disparos y parámetros. Si algo no cierra, mirá Tag Assistant y la pestaña Network.
En esta revisión, hay algunos puntos que no conviene pasar por alto. currency tiene que viajar siempre junto con value para que GA4 calcule ingresos de forma correcta. transaction_id debe ser único en cada compra para evitar duplicados. Y items tiene que incluir al menos item_id o item_name.
También conviene registrar como dimensiones personalizadas los parámetros que quieras usar después en reportes y en Exploraciones. Y ojo con un detalle que suele pegar fuerte: GA4 distingue mayúsculas de minúsculas, así que los nombres tienen que coincidir exactamente.
Uno de los errores más comunes es el doble disparo del evento purchase. Puede pasar si el usuario recarga la página de agradecimiento o si el sitio tiene GA4 instalado dos veces: por ejemplo, con un plugin y además con código manual. Para probar mejor, hacelo en un navegador sin bloqueadores de anuncios. Algunas extensiones frenan solicitudes y hacen parecer que hay fallas cuando en producción no las hay.
Con los eventos ya verificados, definí cuáles mueven decisiones de negocio. Marcá como eventos clave solo las acciones de alto valor, como purchase y generate_lead. Si marcás eventos de baja intención, como view_item o scroll, podés distorsionar las pujas de Google Ads y terminar subiendo el costo de adquisición real.
Para mirar abandonos, usá Explorar en GA4 y armá un embudo con los eventos estándar de e-commerce en este orden:
view_itemadd_to_cartbegin_checkoutadd_shipping_infoadd_payment_infopurchase Ese embudo te ayuda a ver dónde se cae la gente. Una baja fuerte entre add_to_cart y begin_checkout suele apuntar a fricción por costos de envío ocultos o por registro obligatorio. Si la caída aparece en add_payment_info, el problema muchas veces está en la falta de medios de pago o en temas de confianza.
También podés segmentar ese mismo embudo por dispositivo o por fuente de tráfico. Ahí suele aparecer la foto más clara: tal vez el problema sea de usabilidad en mobile, o quizá el tráfico que llega no tenga buena intención de compra.
Cuando los reportes de GA4 te queden cortos, llevá el análisis a BigQuery. Tiene sentido exportar cuando manejás millones de eventos por mes o cuando necesitás cruzar GA4 con CRM y datos internos para análisis más a fondo de compras, carritos y comportamiento post-compra.
Con los eventos ya validados, el paso que sigue es sostener ese trabajo sin que se desordene con el tiempo.
La gobernanza del tracking arranca con un solo diccionario de eventos: nombre, parámetro y propósito. Ahí se define qué mide cada evento y qué decisión ayuda a tomar. Si eso no queda por escrito, tarde o temprano aparecen nombres duplicados, parámetros mal usados y reportes que confunden más de lo que ayudan.
También conviene definir un catálogo de producto para que item_id, item_name e item_category se envíen siempre de la misma manera. Parece un detalle menor, pero no lo es. Cuando esos campos cambian según la página, la campaña o la persona que implementó el evento, después comparar datos se vuelve un dolor de cabeza.
En tiendas que operan en Argentina, la propiedad tiene que reflejar esa operación local. El parámetro currency debe enviarse como "ARS" junto con value, y ese valor tiene que mandarse como número con punto decimal - por ejemplo, 1200.50 - , no como texto con formato. Además, registrá los parámetros personalizados como dimensiones o métricas dentro de las primeras 24 horas desde el primer envío para no perder datos desde el arranque.
Los errores más caros suelen aparecer cuando el tracking crece sin orden. Al principio todo parece funcionar. Después, los reportes dejan de cerrar y nadie sabe bien por qué.
| Error | Solución recomendada |
|---|---|
| Tráfico interno sin filtrar | Excluí las IPs del equipo, la agencia y los desarrolladores para evitar un embudo distorsionado |
| Cambios sin documentar | Registrá cada modificación al tracking con fecha, responsable y motivo en el diccionario central |
Ese tipo de control evita problemas muy comunes. Por ejemplo, si el equipo prueba el checkout una y otra vez desde la oficina, el embudo puede mostrar compras, inicios de pago o carritos que nunca existieron. Y si alguien cambia un evento sin dejar registro, después nadie entiende por qué cayó una métrica o por qué dos paneles muestran números distintos.
Con esta base, la prioridad no pasa por sumar más eventos. Pasa por mantenerlos estables y útiles. Un tracking que sirve de verdad mezcla eventos recomendados, GTM, validación en DebugView y una gobernanza simple, sostenida en el tiempo.
Si tu tienda trabaja con WhatsApp e Instagram en flujos de recuperación de carrito o soporte automatizado con Burbuxa, cada interacción bien medida se transforma en una señal concreta para optimizar campañas y entender mejor cómo compra la gente.
Conviene crear un evento personalizado solo cuando ninguna opción predefinida de Google encaja con lo que necesitás medir.
Sirve para registrar interacciones propias de tu negocio. Por ejemplo:
Como estos eventos los define el usuario, por lo general tenés que analizarlos con informes personalizados o en Exploraciones.
En e-commerce, hay dos parámetros que mandan cuando querés medir bien ingresos y el rendimiento de tus productos: currency y value.
Si cargás value, entonces currency pasa a ser obligatorio. Y ojo con esto: los dos tienen que seguir el estándar ISO 4217.
A nivel de cada artículo, también conviene sumar item_id o item_name, junto con price, quantity e item_category. Eso te ayuda a mantener una taxonomía ordenada y datos consistentes.
Para evitar compras duplicadas en Google Analytics 4, usá un transaction_id distinto para cada transacción. GA4 usa ese dato para deduplicar los eventos de compra.
Si mandás el mismo transaction_id más de una vez, lo toma como la misma operación y no la cuenta dos veces. Por eso, conviene resolver bien esta lógica al registrar el evento purchase en tu sitio.