Si medís todo el abandono junto, no sabés dónde se frena la compra. Yo lo separaría por etapas: producto, carrito, checkout, envío, pago y compra. Así puedo ver si el problema está en la ficha, en el costo de envío, en un formulario largo o en un rechazo de pago.
En este mapa, el punto no es solo mirar una tasa global. El punto es seguir el paso a paso desde view_item hasta purchase y calcular qué porcentaje se cae en cada salto. Por ejemplo:
Yo también me quedaría con una idea simple: abandono de carrito y abandono de checkout no son lo mismo. Si uso begin_checkout como base, estoy midiendo checkout; no carrito.
Para que el mapa sirva, necesito unir eventos con datos de tienda usando IDs como session_id, cart_id, checkout_id, order_id y algún dato de persona, como email hasheado o teléfono. Y revisar que cada evento salga una sola vez, en orden, y con montos que cierren con la orden en $ ARS.
En pocas palabras, este artículo explica:
Mi resumen corto: un buen mapa de abandono no responde “cuántos carritos perdí”, sino en qué paso perdí la intención de compra. Y con eso ya puedo pasar de mirar un número suelto a corregir un problema puntual. Para ello, podés aplicar estrategias de recuperación de carritos que ataquen cada punto de fuga.
Mapa de Abandono de Carrito: Etapas, Eventos y Fugas
Antes de sacar tasas de abandono, necesitás tener bien identificado qué evento representa cada paso y qué te muestra sobre la intención del usuario. Cada evento funciona como una señal. Cuando el siguiente no aparece, ahí tenés el punto de fuga.
| Etapa | Evento | Señal de intención | Fuga |
|---|---|---|---|
| Vista de listado | view_item_list | Interés inicial, exploración | No hace clic en ningún producto |
| Vista de producto | view_item | Consideración activa de un SKU | No agrega al carrito |
| Agregar al carrito | add_to_cart | Intención explícita de compra | No abre ni revisa el carrito |
| Revisión de carrito | view_cart | Evaluación del total antes de avanzar | No inicia el checkout |
| Inicio de checkout | begin_checkout | Alta intención, listo para comprar | No completa datos de envío |
| Datos de envío | add_shipping_info | Acepta la logística | No ingresa datos de pago |
| Datos de pago | add_payment_info | Intención de pago | No confirma el pedido |
| Compra | purchase | Conversión completa | - |
Estos eventos se pueden leer en Shopify, Tiendanube y VTEX. Con ese mapa armado, el paso siguiente es cruzarlo con pedidos, clientes y carritos.
Si view_item no pasa a add_to_cart, la fuga está en la ficha de producto. Ese salto te ayuda a separar dos problemas que suelen mezclarse.
view_item_list y view_item, el problema está en la grilla.view_item y add_to_cart, el problema está en la ficha.Dicho simple: una cosa es que el usuario no entre al producto, y otra muy distinta es que entre, mire y no avance.
begin_checkout marca el momento en que el usuario decide seguir. En Shopify, este evento equivale a checkout_started; en Tiendanube, este hito se toma cuando el cliente entra al checkout y no compra.
La fuga entre begin_checkout y add_shipping_info suele tener motivos bastante claros: obligación de crear una cuenta, formularios largos o el primer golpe del costo de envío. En cambio, la caída entre add_shipping_info y add_payment_info suele aparecer por validación de dirección o desconfianza en el pago.
El tramo más sensible es el que va de add_payment_info a purchase. Quien llega hasta este punto ya cargó sus datos de pago. La intención de compra es alta.
Si igual no convierte, el problema suele ser operativo: método de pago no disponible, rechazo de tarjeta o falla del procesador.
Con el mapa listo, toca unirlo con los datos de cada plataforma.
Con el mapa de eventos ya listo, el paso siguiente es unificar todo en un solo esquema. La idea es simple: leer el abandono por etapa y medir con claridad el salto entre view_item, add_to_cart, begin_checkout y purchase.
Con esa base, ya podés definir qué campos te conviene traer de cada plataforma.
Necesitás cinco grupos de datos: producto, carrito, cliente, checkout y tiempo. No todos los sistemas muestran lo mismo, así que conviene apoyarse en lo que comparten para unir datos y usar lo propio de cada plataforma para detectar dónde se corta el recorrido.
En Shopify, el objeto de abandono de checkout trae líneas de producto con SKU, variante, descuentos aplicados y precio por línea. También suma referencias del cliente y timestamps de creación y actualización.
En Tiendanube, el recurso Abandoned Checkout muestra datos de contacto, cupón de descuento y total. Pero hay un punto clave: solo registra abandono desde el checkout. Si alguien miró un producto o dejó el carrito antes de avanzar, esa parte la tenés que cubrir con analítica propia.
En VTEX, podés reconstruir carrito, cliente y envío al cruzar items, clientProfileData y shippingData.address.
Mostrá los montos en ARS y las fechas en hora local de Argentina con formato dd/mm/yyyy hh:mm. El dato crudo, eso sí, guardalo en el warehouse.
Después de normalizar valores y tiempos, toca un paso que suele traer dolores de cabeza: unificar personas y sesiones.
El problema más común al cruzar datos de plataformas con eventos de analítica es que la misma persona aparece con IDs distintos. Pasa todo el tiempo: una cookie por un lado, un email por otro, un pedido por otro más.
Para ordenarlo, necesitás dos claves:
session_id, cookie o ID de analíticaLa conexión entre ambas se hace cuando el usuario deja sus datos en el checkout. Ahí es donde piezas sueltas pasan a formar una sola historia.
Guardá siempre order_id, session_id y las UTMs para unir evento y pedido. Ese cruce es el que te deja medir el abandono por etapa con buena precisión. También conviene usar nombres consistentes para los eventos de vista, carrito, checkout, abandono y compra.
Cuando el mapa ya te deja detectar fugas en tiempo real, podés pasar a la recuperación automática. Con el mapa y los datos unificados, Burbuxa puede activar recuperaciones automáticas por WhatsApp o Instagram cuando un checkout queda incompleto después del tiempo de corte.
Ahora convertí cada fuga en una tasa que puedas medir. Con los eventos unificados, medí cada transición como avance sobre la misma base: usuarios que pasan al paso siguiente dividido por usuarios que entran a ese paso.
Calculá cada tasa con el mismo período y la misma unidad de análisis, ya sea usuario o sesión. Y sostené la misma base de comparación en toda la serie, así las tasas se pueden comparar entre sí sin mezclar criterios.
| Transición | Fórmula | Causa principal |
|---|---|---|
| Vista de producto → Agregar al carrito | 1 - (add_to_cart / view_item) | Ficha de producto, precio o CTA |
| Agregar al carrito → Inicio de checkout | 1 - (begin_checkout / add_to_cart) | Fricción en el carrito o costo inesperado |
| Inicio de checkout → Datos de envío | 1 - (add_shipping_info / begin_checkout) | Costo de envío o formulario largo |
| Datos de envío → Datos de pago | 1 - (add_payment_info / add_shipping_info) | Métodos de pago o validación de dirección |
| Datos de pago → Compra | 1 - (purchase / add_payment_info) | Rechazo de pago o falla técnica |
| Abandono de carrito (total) | 1 - (purchase / carts_created) | Base ideal: carts_created. Si no lo medís, usá begin_checkout solo como proxy de checkout, no de carrito. |
| Abandono de checkout (total) | 1 - (purchase / begin_checkout) | Fricción dentro del flujo de pago |
Separá estas dos tasas. No miden lo mismo y tampoco apuntan al mismo problema.
La tasa, por sí sola, no alcanza. Para encontrar la causa, hay que abrir el dato por segmento.
Un número global dice poco a la hora de actuar. Por ejemplo, una caída alta en begin_checkout → add_shipping_info puede aparecer porque el costo de envío recién se muestra en ese paso. Si ese patrón se repite en destinos del interior, el problema no está en el producto: está en la poca claridad previa sobre el costo de envío.
Si la caída sube en add_payment_info → purchase, mirá confianza, medios de pago y fricción en el tramo final. A veces el freno no está en el precio ni en el carrito. Está justo cuando la compra ya parecía cerrada.
Segmentá por:
Monitoreá estos KPIs por día o por semana y activá alertas cuando una etapa se aparte de su base. Estas alertas pueden integrarse con campañas automatizadas en WhatsApp para recuperar usuarios en tiempo real. Mostrá siempre el volumen junto con la tasa para no sobrerreaccionar ante muestras chicas. La idea no es solo informar porcentajes: es detectar el punto exacto donde se escapa la conversión.
Con los puntos de fuga ya medidos, queda un paso: confirmar que el tracking los esté registrando como corresponde.
Acá aplica una regla simple: menos eventos, pero bien validados, suele dar mejores resultados que llenar todo de eventos mal armados. Definí una sola convención de nombres y dejá por escrito cuándo se dispara cada evento, sobre todo add_shipping_info y add_payment_info.
En producción, chequeá que cada evento - view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info y purchase - se envíe una sola vez, en el orden correcto, y que el monto de purchase coincida con la orden real usando el mismo formato monetario de esa orden.
Después, compará ese esquema contra los registros nativos de la tienda. Tomalos como control de calidad semanal. Si contrastás los checkouts abandonados de la plataforma con los usuarios que tienen begin_checkout pero no purchase en tu herramienta de analítica, vas a detectar mucho antes si el tracking se rompió y evitar decisiones basadas en datos flojos.
También conviene unificar session_id, cart_id, checkout_id y customer_id bajo una sola identidad, usando el dato disponible en checkout. Eso te deja conectar sesiones distintas con una misma persona.
El mapa de abandono no responde “¿cuántos carritos se perdieron?”. Responde en qué paso se cayó la intención y por qué. Y eso cambia todo.
Cada fuga suele señalar un problema distinto. A veces el freno aparece en el carrito. Otras veces, en el envío. O justo al momento de pagar. El mapa sirve para ubicar ese punto con precisión antes de meter mano.
Con el mapa ya validado, recién ahí tiene sentido automatizar la recuperación. Cuando el mapa y los datos quedan unificados, Burbuxa puede activar mensajes automáticos cuando un checkout queda incompleto. Así medís pérdida y recuperación con los mismos IDs.
La diferencia está en el momento del recorrido de compra.
El abandono de carrito sucede cuando una persona agrega productos al carrito, pero se va antes de empezar el pago.
El abandono de checkout, en cambio, pasa cuando esa persona ya arrancó el proceso de pago, pero no lo termina. ¿Por qué suele pasar? Por fricciones bastante comunes: costos inesperados, falta de medios de pago que prefiere usar o un proceso demasiado largo o enredado.
Medí, como base, estos eventos: product_view, add_to_cart, begin_checkout (o checkout.started) y purchase.
Si querés que el mapa sirva de verdad para tomar decisiones, sumá checkout.abandoned cuando haya entre 30 y 60 minutos de inactividad.
En cada evento incluí sí o sí:
event_idcustomer_id o teléfonoorder_id o cart_idtimestamp en formato ISO 8601 con offset -03:00Si el evento viene de Instagram o WhatsApp, agregá también clicked y replied.
Primero, hacé la integración nativa de Burbuxa desde la tienda de aplicaciones de tu plataforma. De ese modo, se sincronizan en tiempo real los productos, los pedidos, los clientes y el inventario, sin vueltas técnicas ni ajustes complejos.
Después, el cruce se hace con identificadores en común, como el ID de cliente, el teléfono o el número de pedido. Para que todo funcione bien, cada evento tiene que incluir el tipo de evento, un ID único, el canal de origen y un timestamp en formato ISO 8601 con huso horario local (-03:00).