CAPI en Black Friday: checklist antes de escalar

Puntos clave

Evento aceptado, evento coincidido, venta atribuida y venta confirmada son cuatro cosas distintas; verifique cada una por separado.
Solo la venta confirmada se convierte en Purchase; un cambio de etapa, un link enviado o un "voy a pagar" no son compra.
El event_id tiene que ser el mismo en todo reenvío del mismo pedido y distinto para cada pedido nuevo; así es como Meta deduplica.
Valor y moneda viajan juntos, y monedas distintas nunca se suman en el informe.
Concilie a diario: eventos enviados, aceptados, rechazados y duplicados contra los pedidos del CRM, antes de aumentar la inversión.

¿Qué hace la API de Conversiones en una campaña de WhatsApp en Black Friday?

La API de Conversiones (CAPI) envía eventos del servidor a Meta, como Purchase, con deduplicación por event_id cuando el mismo evento también llega por el píxel, según la documentación de Meta. En ventas por WhatsApp no hay píxel en la conversación: la venta solo existe para Meta si el CRM envía el evento.

Eso importa porque la campaña con objetivo de mensajes optimiza para conversación iniciada. Sin el Purchase de vuelta, Meta nunca sabe qué conversaciones se convirtieron en venta, y el gestor decide la inversión por el CPL. Con el Purchase, Meta recibe una señal de venta y muestra, dentro de la ventana de atribución, ventas por campaña. El artículo anterior sobre API de Conversiones para ventas en WhatsApp explica la base; aquí el foco es no escalar con un envío roto.

Cuatro estados que no pueden confundirse:

Estado	Qué significa	Quién lo confirma	Qué NO prueba
Evento aceptado	Meta recibió un payload válido	Administrador de eventos	Que la venta existió
Evento coincidido	Meta ligó el evento a un usuario	Administrador de eventos	Que el anuncio causó la venta
Venta atribuida	Meta acreditó la venta a un anuncio dentro de la ventana	Informe de Meta	Que el valor es correcto
Venta confirmada	Pago aprobado y registrado en el CRM con valor y moneda	CRM / finanzas	Que Meta recibió el evento

¿Cuál es el checklist de CAPI antes de escalar?

El checklist tiene diez ítems, y cualquier "no" frena la expansión de la inversión. Pruebe antes del evento con el mecanismo de prueba de Meta, sin simular compras reales en producción.

Origen del evento definido: qué conjunto de datos recibe el evento y qué sistema lo envía. Si dos herramientas envían, una tiene que parar.
Disparador correcto: Purchase sale solo cuando la venta se confirma en el CRM. Un cambio de etapa en el embudo, el envío de un link de pago y un "cerró por audio" no disparan Purchase.
Valor y moneda: value numérico y currency en ISO (BRL). Sin moneda el valor es inútil; con moneda equivocada el ROAS se vuelve ficción.
event_id estable: generado a partir del identificador del pedido, igual en todo reenvío del mismo pedido, distinto para un pedido nuevo.
event_time del pago: hora de la confirmación, no del envío en lote. Un lote atrasado empuja la venta fuera de la ventana de atribución.
Datos de coincidencia: los campos de identificación que el canal entrega siguen el formato que exige la documentación de Meta; sin ellos el evento llega y no se liga a nadie.
Deduplicación probada: envíe el mismo pedido dos veces en el entorno de prueba y verifique que Meta cuente uno.
Reenvío controlado: una falla de red genera un nuevo intento con el mismo event_id, con límite de intentos y log.
Dueño de los rechazos: una persona revisa los eventos rechazados todos los días y sabe detener el envío si el payload está mal.
Conciliación: los eventos aceptados por día coinciden con los pedidos confirmados en el CRM por día; una diferencia por encima de lo tolerado (hipotético: 5%) bloquea la escala.

Regla de decisión: si fallan los ítems 2, 3, 4 o 10, no escale. Los demás pueden corregirse con la inversión de validación al aire.

¿Cómo funciona la deduplicación por event_id en la práctica?

Meta recibe eventos con el mismo event_name y el mismo event_id dentro de un intervalo y cuenta solo uno. Eso protege contra el reenvío tras una falla y contra el mismo evento llegando por dos caminos. Ejemplo hipotético:

Pedido 7781 confirmado a las 14:02, R$ 240,00 BRL (reales brasileños). El CRM genera el event_id "purchase-7781" y envía Purchase.
La red falla y el CRM no recibe confirmación. A las 14:04, reenvía el mismo payload con event_id "purchase-7781". Meta cuenta un Purchase.
Pedido 7782 confirmado a las 14:10, R$ 240,00 BRL, el mismo cliente comprando un segundo artículo. event_id "purchase-7782". Meta cuenta el segundo Purchase.
Error que destruye el informe: el CRM genera el event_id a partir del teléfono del cliente. Los pedidos 7781 y 7782 reciben el mismo event_id, Meta deduplica y el informe muestra R$ 240 en vez de R$ 480.
Error opuesto: el CRM genera el event_id con timestamp. El reenvío de las 14:04 recibe un id nuevo y Meta cuenta dos Purchase de R$ 240 para un solo pedido: ROAS inflado.

Conciliación del día: CRM con 2 pedidos (R$ 480); Meta con 2 eventos aceptados (R$ 480). Tres eventos indican id inestable; un evento indica colisión de id. Un CRM con atribución que envía Purchase con control de duplicidad, como RASTRO, se encarga de esa parte; el gestor igual verifica la conciliación.

¿Qué errores de CAPI aparecen más en Black Friday?

Los errores más frecuentes son de disparador, de identidad y de tiempo:

Convertir una etapa del embudo en Purchase. El lead en "negociando" no compró. Un Purchase ahí le enseña a Meta a buscar a quien negocia, no a quien paga, e infla el ROAS.
Copiar el payload de un e-commerce. Un sitio web con píxel tiene campos que la conversación no tiene; el evento llega con datos vacíos y la coincidencia cae. Arme el payload a partir de lo que el canal entrega y declare lo que no está disponible.
Enviar en lote de madrugada. El event_time en lote manda la venta a otro día y, cerca del fin de la ventana de atribución, fuera de ella. El informe de Meta y el del CRM dejan de coincidir.
Sumar monedas. Un cliente que vende a Brasil en BRL y al exterior en USD necesita dos informes de ROAS. Un Purchase en USD sumado a otro en BRL genera un número sin significado.
Olvidar las cancelaciones. El art. 49 del CDC (código del consumidor brasileño) da 7 días de desistimiento en compras fuera del establecimiento, incluido WhatsApp. La venta cancelada se marca en el CRM y se descuenta del informe; el Purchase ya enviado queda como limitación declarada.

La fuente de la verdad es el CRM con valor y moneda, no el administrador de eventos. Si lo que usted envía está mal, la optimización aprende mal en la subasta más disputada del año; en noviembre, compare el costo con el noviembre anterior de la propia cuenta.

¿Qué medir a diario en la Black Week para mantener la CAPI confiable?

Mida eventos enviados, aceptados, rechazados, duplicados y conciliados, y crúcelos con la cobertura de atribución del CRM. Fórmulas y rangos:

Tasa de aceptación = eventos aceptados ÷ eventos enviados. Bueno: cerca del 100%. Malo: por debajo del 95% (hipotético); investigue el payload el mismo día.
Tasa de duplicados = eventos deduplicados ÷ eventos enviados. Bueno: igual a la tasa de reenvíos por falla. Malo: muy por encima (id inestable) o cero con reenvíos (id en colisión).
Conciliación = eventos aceptados ÷ pedidos confirmados en el CRM. Bueno: entre 0,95 y 1,05 (hipotético). Malo: fuera de eso durante dos días.
Cobertura de atribución = ventas con origen ÷ ventas totales en el CRM. El Purchase sale para toda venta confirmada, con o sin origen; la cobertura dice cuánto logrará atribuir Meta. Por debajo del 70% (hipotético), el informe de Meta por campaña queda parcial y la escala por anuncio pierde base.
Diferencia de valor = ingresos de los eventos aceptados − ingresos confirmados en el CRM, por moneda. Bueno: cero. Malo: cualquier diferencia recurrente.

Compare por cohorte (ventas de los leads que entraron en el día), no por caja; la ventana de atribución sigue al clic, no al pago. El rastreo que alimenta esas ventas está en rastreo del anuncio a WhatsApp, y la decisión de inversión a partir de ellas en presupuesto de Meta Ads en Black Friday.

¿Cómo presentar los números de la CAPI al cliente sin prometer lo que no existe?

Presente los cuatro estados por separado, con la cobertura al lado, y deje escrito lo que el canal no entrega. El ROAS de Meta y el del CRM son lecturas distintas, no un error de alguien. Estructura sugerida:

Ventas confirmadas en el CRM, por moneda, con total y sin atribución en línea propia.
Eventos Purchase enviados, aceptados y deduplicados en el período.
Ventas atribuidas por Meta dentro de la ventana, por campaña.
Diferencia entre 1 y 3 explicada por ventana, cobertura y coincidencia.
Limitaciones declaradas: cancelaciones después del envío y caminos de entrada sin origen.

El número que no puede explicarse línea por línea no debe estar en el informe. El formato completo está en informe que ayuda al cliente a decidir.

Plan de acción: qué hacer esta semana

Use este cronograma para validar la CAPI antes de escalar.

Cuándo	Acción	Responsable	Listo cuando
Hoy	Confirmar qué sistema envía Purchase y a qué conjunto de datos	Gestor de tráfico	Una sola herramienta enviando
Antes del viernes	Disparar Purchase solo con venta confirmada, con value, currency y event_id del número de pedido	Responsable del CRM	Payload de prueba con valor, moneda ISO y event_id del pedido
D-14	Enviar el mismo pedido dos veces y un segundo pedido del mismo cliente en el entorno de prueba	Responsable del CRM	La deduplicación cuenta 1 evento para 2 envíos del mismo pedido y 2 eventos para 2 pedidos
D-7	Nombrar quién revisa a diario los eventos rechazados y puede detener el envío	Gestor de tráfico y cliente	Nombre del responsable escrito en el briefing
D-7 a D-1	Conciliar eventos aceptados con pedidos confirmados en el CRM, por día	Gestor de tráfico	Conciliación entre 0,95 y 1,05 (hipotético) antes de escalar
Día del evento	Revisar tasa de aceptación y diferencia de valor por moneda	Gestor de tráfico	Aceptación cercana a 100% y diferencia de valor cero
D+7	Marcar en el CRM las ventas canceladas en el plazo de arrepentimiento	Equipo de atención	Cancelaciones descontadas del informe

Preguntas frecuentes

Fuentes

¿Un evento aceptado por Meta garantiza que la venta fue atribuida al anuncio?

No. La aceptación significa que el payload era válido. La atribución exige que Meta encuentre al usuario (coincidencia) y que la venta caiga en la ventana de atribución del clic. La venta confirmada es otra cosa más: solo el CRM y finanzas la confirman. Verifique los cuatro estados por separado.

¿Debo enviar Purchase cuando el lead dice que va a pagar?

No. Purchase solo para pago confirmado, con valor y moneda. Enviarlo antes le enseña a Meta a buscar a quien promete, no a quien paga, e infla el ROAS. Si quiere una señal intermedia, use un evento propio para lead calificado, separado de Purchase.

¿Qué pasa si reenvío el mismo pedido dos veces?

Si el event_id es el mismo, Meta deduplica y cuenta un Purchase. Si el event_id cambia en cada envío (por ejemplo, con timestamp), Meta cuenta dos y el ROAS queda inflado. Pruebe el reenvío en el entorno de prueba antes de Black Friday y verifique el conteo.

¿Cómo probar la CAPI sin generar compras falsas?

Use el mecanismo de eventos de prueba del administrador de eventos de Meta, con un pedido marcado como prueba en el CRM. Verifique valor, moneda, event_id, event_time y la deduplicación. Después marque o elimine el pedido de prueba para que no entre en el informe.