Si conecto bien los eventos de compra con WhatsApp, puedo recuperar carritos, frenar mensajes fuera de tiempo y medir ventas con más precisión.
En esta guía, voy al punto: para que una automatización de ventas funcione, necesito tres eventos base - checkout iniciado, carrito abandonado y compra confirmada - , una regla de cancelación cuando entra la compra, consentimiento válido, teléfono en E.164 y control de duplicados. Si falla una de esas piezas, el cliente puede recibir un mensaje tarde, repetido o fuera de contexto.
En pocas palabras, esto es lo que tengo que dejar resuelto:
Un dato simple pero clave: si defino el abandono a los 60 minutos de inactividad, el sistema tiene que revisar antes si ya entró un purchase_completed. Si no lo hace, puedo mandar un “te olvidaste tu carrito” a alguien que ya pagó. Y eso pega directo en la experiencia del cliente.
También necesito separar bien los tipos de mensaje:
Esa separación evita errores con consentimiento, frecuencia y bajas.
Lo central del artículo es esto: una automatización confiable no depende solo del mensaje, sino de la lógica que corre antes. Primero valido, después deduplico, luego reviso elegibilidad y recién ahí envío. Con ese orden, WhatsApp pasa de ser un canal manual a un canal conectado con lo que pasa en la tienda, en tiempo real y con reglas claras.
La arquitectura mínima tiene que conectar la tienda con WhatsApp para crear experiencias de compra automatizadas sin perder eventos ni duplicar mensajes. En la práctica, eso implica cubrir cinco piezas: la fuente, el endpoint de recepción, la normalización, la identificación del cliente, las reglas y la ejecución.
La tienda tiene que ser la fuente principal. La pasarela confirma el pago, el OMS informa el estado logístico y el CRM/CDP aporta consentimiento e historial. Cada dato debe salir de su sistema maestro.
Dicho más simple: no conviene mezclar roles. Si la tienda define el carrito, que lo haga la tienda. Si la pasarela confirma el cobro, que esa confirmación venga desde ahí. Eso evita cruces raros, demoras y mensajes enviados con datos viejos.
Con esas fuentes definidas, el siguiente paso es decidir qué evento dispara cada flujo y cuál lo frena.
Cada evento debe incluir event_id, event_type, occurred_at, source, customer_id, cart_id o checkout_id, order_id, items, currency, total y payment_status.
No hace falta complicarlo de más: si faltan esos campos, después cuesta deduplicar, cancelar envíos o entender qué pasó en cada caso.
cart_updated consolida cambios del carrito.purchase_completed corta cualquier recuperación activa.cart_abandoned se calcula por 60 minutos de inactividad y ausencia de compra confirmada.Si entra una compra después de que el abandono ya fue programado, el sistema debe cancelar el mensaje pendiente antes de enviarlo. Ese punto parece menor, pero cambia todo: nadie quiere recibir un “te olvidaste algo en el carrito” después de haber pagado.
Después, toca preparar los datos y validar los requisitos de WhatsApp antes de activar los mensajes.
Burbuxa funciona como capa de ejecución: toma los eventos normalizados y dispara las automatizaciones de WhatsApp con datos de tienda siempre actualizados. La arquitectura propia sigue validando, deduplicando y controlando el consentimiento.
Así, los eventos de compra pasan a WhatsApp sin intervención manual.
Con la arquitectura definida, el siguiente paso es validar consentimiento, plantillas y formato de los datos antes de enviar mensajes.
Antes de prender cualquier automatización, asegurate de que la cuenta, los datos y las reglas de elegibilidad estén en orden. Si algo se corta en el medio, el mensaje puede no salir o llegar tarde. Con la arquitectura ya definida, ahora toca chequear lo mínimo para que cada evento entre bien y se procese como corresponde.
El punto de partida es una cuenta activa en WhatsApp Business Platform con el negocio verificado, un número habilitado, credenciales de acceso, plantillas creadas y un webhook o motor de automatización activo. Esa cuenta también tiene que recibir eventos desde un webhook o desde una capa de ejecución ya integrada.
Para mensajes proactivos - como estrategias de recuperación de carrito o confirmaciones de compra fuera de la ventana de atención - necesitás una plantilla aprobada y el consentimiento explícito del cliente. Haber comprado antes o tener el número no alcanza. Sin un consentimiento válido, no se pueden mandar mensajes proactivos ni recuperar carritos. Pedí el opt-in de forma explícita en el checkout y guardá estos datos:
Los números tienen que normalizarse al formato E.164 antes de cualquier envío. En Argentina, validá el código de país (+54) y que el número esté habilitado en WhatsApp. No uses formato local ni separadores. El valor normalizado va al API, mientras que el formato local puede quedar guardado aparte para mostrárselo al cliente.
No todos los mensajes siguen las mismas reglas. Si metés todo en una sola lógica, podés terminar mandando una oferta a alguien que ya pidió la baja de marketing. O enviar un recordatorio cuando la compra ya quedó confirmada.
| Tipo | Ejemplos | Requisito clave |
|---|---|---|
| Transaccional | Confirmación de pago, despacho, entrega | Vinculado a una acción concreta; sin contenido promocional |
| Recuperación | Recordatorio de carrito, checkout pendiente | Carrito abierto, URL de checkout válida, consentimiento compatible y sin orden posterior |
| Promocional | Descuentos, lanzamientos, recomendaciones | Opt-in de marketing, límite de frecuencia y supresión activa |
Cada flujo debería revisar opted_in, opted_out, consent_categories, last_contact_at y last_message_type. El mecanismo de baja - por ejemplo, responder BAJA - tiene que procesarse en el momento y reflejarse en la lista de supresión antes del próximo envío.
Estos controles evitan que un evento correcto termine disparando el mensaje equivocado. Los webhooks pueden entregar el mismo evento más de una vez. Si el endpoint no responde o está caído, Meta puede reintentar la entrega con menos frecuencia durante hasta siete días. Por eso, el sistema tiene que ser idempotente: cada evento entra con un event_id único, se registra en una tabla de idempotencia y, si ese ID ya fue procesado, se descarta sin enviar nada.
Tampoco conviene perder de vista los eventos que fallan. En vez de tirarlos al olvido, guardá el payload original, el motivo del error, la hora del intento, la cantidad de reintentos y, si aplica, el próximo intento en una cola de eventos fallidos.
Para los mensajes salientes, registrá por separado:
Así podés ver con claridad qué pasó: si el evento nunca llegó, si quedó suprimido o si WhatsApp rechazó la plantilla.
Con estos controles activos, pasá al mapeo de cada evento al payload y a la automatización correcta.
Flujo de Automatización de WhatsApp: Eventos de Compra Paso a Paso
Con los eventos ya validados, toca definir qué datos manda cada uno y qué automatización activa en WhatsApp. Desde acá, el foco pasa al esquema de datos y a la rama que dispara cada mensaje.
Cada evento tiene que llegar con un esquema fijo: event_name, event_id, customer_id, phone, occurred_at, source y los IDs del carrito, checkout u orden. En items, incluí product_id, variant_id, nombre, cantidad y precio unitario. Sumá subtotal, descuento y envío solo si le sirven al mensaje. Guardá el valor numérico dentro del payload y mostralo en WhatsApp con formato local.
Si el evento puede activar recuperación o mensajes promocionales como parte de tus estrategias de WhatsApp para ecommerce, agregá consent_status y la URL que corresponda: cart_url, checkout_url o la URL de recuperación. Sin una URL válida, no hay recuperación. Sin consentimiento, no hay envío.
| Evento | Disparador | Payload requerido | Uso en WhatsApp |
|---|---|---|---|
checkout_started | El comprador inicia el checkout y ya existe identidad o contacto para asociar la sesión | event_id, customer_id o phone, occurred_at, source, cart_id, checkout_id cuando exista, ítems, cantidades, total, currency, checkout_url, consent_status, payment_status | Disparar recordatorio o asistencia |
cart_updated | Se agrega, elimina o cambia la cantidad de un producto | event_id, customer_id, phone, occurred_at, source, cart_id, lista actual completa de ítems, cantidades, total, currency, cart_url | Actualizar el estado actual del carrito y esperar la ventana de abandono definida |
purchase_completed | El pago se confirma o la orden queda registrada | event_id, customer_id, phone, occurred_at, source, order_id, cart_id o checkout_id cuando exista, ítems, total, currency, payment_status, order_status | Confirmar la compra y cortar la recuperación |
cart_abandoned | Vence la ventana de inactividad configurada sin una compra posterior | event_id, customer_id, phone, occurred_at, source, cart_id, checkout_id cuando exista, último snapshot del carrito o checkout, total, currency, URL de recuperación, consent_status | Iniciar la recuperación |
El evento marca la rama. La elegibilidad define si se envía o no.
El flujo es determinista: entra el evento, se valida, se deduplica y recién ahí se decide qué hacer. La secuencia es esta:
phone, event_id, event_name, currency, totales e identificadores de carrito, checkout u orden.event_id; si ya se procesó, descartalo sin enviar nada.purchase_completed, cancelá cualquier cart_abandoned pendiente del mismo carrito o checkout.purchase_completed, el cliente responde con una consulta que pide atención humana o se registra un opt-out.Con Burbuxa, podés conectar estos eventos con Shopify, Tiendanube, VTEX o una API propia.
Con este mapeo listo, el siguiente paso es armar la secuencia de recuperación del carrito.
Con los eventos ya mapeados, toca poner en marcha la recuperación de carritos. La lógica es simple: si un checkout_started o cart_abandoned queda 60 minutos sin un purchase_completed, se dispara el primer mensaje.
Ese primer contacto tiene que apuntar a destrabar la compra, no a regalar margen de entrada. Por eso, conviene que salga como un mensaje de ayuda. Tiene que incluir el nombre del cliente, los productos, las cantidades, el total en pesos - por ejemplo, $ 125.000,00 - y el link directo al carrito o al checkout.
Hola, [nombre]. Vimos que dejaste productos en tu carrito. Podés retomar tu compra acá: [link]. ¿Necesitás ayuda con el envío o con los medios de pago?
No debería arrancar con descuento. En esta etapa, un mensaje de asistencia suele rendir mejor. Si no hubo compra, respuesta ni baja, podés mandar un segundo mensaje entre 20 y 24 horas después. Ahí sí conviene apuntar a las trabas más comunes: costo de envío, medios de pago o stock.
La secuencia se corta cuando aparece cualquiera de estos casos:
purchase_completedCon Burbuxa, este control corre en tiempo real con datos sincronizados de Shopify, Tiendanube o VTEX.
Una vez que el flujo está definido, hay que mirar si de verdad trae ventas de vuelta. La tasa de recuperación se calcula así:
Tasa de recuperación = pedidos recuperados / carritos elegibles × 100
Los ingresos recuperados netos tienen que excluir descuentos, mensajería, devoluciones y cancelaciones. Además, conviene reportar siempre en ARS y con el timestamp en hora local de Argentina.
Las métricas clave son:
También hace falta separar recuperación directa - cuando el cliente compra desde el link de WhatsApp - de recuperación asistida - cuando una conversación influye en el pedido - . Esa diferencia evita mezclar resultados y te da una atribución mucho más limpia.
Una automatización de eventos de WhatsApp que funciona a escala se apoya en cuatro pilares: una arquitectura de eventos clara con identificadores estables, datos de clientes limpios con consentimiento registrado, un mapeo consistente de eventos de carrito y compra a plantillas aprobadas, y controles deterministas que cancelen el flujo ante cualquier cambio de estado relevante.
Si falta alguna de esas piezas, la recuperación de carritos puede terminar mandando mensajes fuera de contexto y mostrando una atribución errónea. Antes de escalar, validá el flujo completo de punta a punta: evento, entrega, respuesta y cierre del pedido.
Un carrito entra en elegibilidad cuando se registra el evento checkout.abandoned. Ese evento se dispara después de 30 a 60 minutos de inactividad desde que la persona inició el pago.
Además, el evento tiene que traer estos datos:
Y hay un punto clave: si después llega un order.paid para ese mismo checkout_id, hay que cancelar cualquier recuperación que haya quedado pendiente.
Para evitar mensajes de más, aplicá una regla de deduplicación según el estado del pedido. Si entra un evento de compra confirmada (order.paid) para un checkout_id puntual, cancelá en el momento cualquier mensaje de recuperación que haya quedado pendiente para ese mismo proceso.
Así evitás pedirle al cliente que termine una compra que ya pagó y mantenés una experiencia prolija y profesional en Burbuxa.
Cada evento tiene que llevar una base común y obligatoria:
Después, según el caso, sumá los datos que correspondan. Por ejemplo, podés enviar el ID de la orden o del carrito, el total en ARS, la moneda y los parámetros UTM. En otros eventos, puede hacer falta el ID de campaña y el mensaje, o bien el estado de opt-in, el teléfono en formato +54 y el idioma es-AR.
Si el evento es de carrito o checkout, hay un punto que no conviene pasar por alto: también tenés que enviar los ítems. Y, además, validar que los IDs de producto coincidan con los de tu catálogo. Si eso no cierra, todo lo demás empieza a hacer ruido.