API de Conversiones de Meta: cómo devolver las ventas del CRM a la campaña

Una campaña de captación de leads funciona bien en Meta Ads: el costo por lead baja, el volumen de formularios completados sube y el panel parece saludable. Tres semanas después, el equipo comercial cierra un contrato importante y nadie puede decirle al algoritmo que ese lead específico se convirtió en venta. Para Meta, ese evento nunca ocurrió, y la campaña sigue optimizando para lo que logra ver: el formulario, no el resultado. Es exactamente ese vacío el que la API de Conversiones de Meta fue creada para cerrar.

Qué es la API de Conversiones de Meta

La API de Conversiones de Meta es el canal que permite enviar, directo desde el servidor, eventos que ocurrieron fuera del navegador, como una venta cerrada en el CRM, a la misma cuenta de anuncios que generó ese lead. Funciona en paralelo al Pixel: mientras el Pixel captura lo que ocurre en el sitio a través del navegador de la persona, la API de Conversiones recibe eventos enviados por tu sistema, sin depender de cookies, de que cargue JavaScript ni de que el visitante haya aceptado el rastreo.

En la práctica, esto cambia lo que la campaña aprende. En lugar de optimizar solo para "formulario completado", pasa a recibir también "se convirtió en oportunidad", "cerró contrato" o "canceló", siempre que alguien envíe esos eventos de vuelta. Esa devolución, del CRM a la campaña, es la que cierra el ciclo entre medios pagos e ingresos.

Por qué el Pixel solo ya no es suficiente

El Pixel depende del navegador para funcionar, y una parte creciente del tráfico bloquea ese camino antes de que el evento llegue a salir. Los bloqueadores de anuncios, los navegadores con rastreo restringido por defecto y las políticas de privacidad más estrictas cortan parte de los eventos del lado del cliente, aun cuando la conversión realmente ocurrió.

Existe además una limitación estructural: el Pixel solo sabe lo que pasa en la página. No tiene acceso a lo que ocurre después, cuando el lead sale del sitio y entra al proceso comercial. Una reunión agendada, una propuesta enviada y un contrato firmado son eventos que viven en el CRM, no en el navegador, y solo llegan a Meta si alguien los envía de vuelta desde el servidor.

Cómo el evento sale del CRM y llega hasta la campaña

El flujo comienza en el momento del lead, no en el momento de la venta. Cuando alguien completa un formulario que viene de un anuncio, Meta adjunta un identificador de clic a la sesión, el parámetro fbc. Ese valor debe capturarse mediante un campo oculto en el formulario y guardarse junto con el lead, en el mismo espíritu de otros parámetros de clic que solo existen en ese instante y luego desaparecen, como el identificador de clic de Google Ads.

A partir de ahí, el camino es este:

• El lead entra al CRM ya con fbc , correo electrónico y teléfono guardados.
• Cuando el negocio cambia de etapa (por ejemplo, se convierte en oportunidad o cierra una venta), se arma un evento con esos datos.
• Ese evento se envía por servidor a la Conversions API, con el valor de la venta cuando exista.
• Meta suma ese evento al historial de esa campaña y pasa a optimizar considerando lo que realmente se convirtió en negocio.

Sin ese encadenamiento, el embudo unificado de marketing y ventas deja de existir del lado de la plataforma de anuncios: el CRM sabe de la venta, Meta no. Vale la pena enviar más que solo la venta cerrada: las operaciones con ciclo de venta más largo suelen perder la ventana útil si esperan el contrato firmado, por lo que tiene sentido devolver también hitos intermedios, como la calificación o la propuesta enviada, para que la campaña tenga señal antes del final del embudo.

Material de apoyo · En portuguésGuía de Prompts para Marketing y Ventas70 prompts con preguntas sobre marketing, ventas y comportamiento para hacerles a tus datos.Descargar la guía

Event_id y la deduplicación con el Pixel

Cuando el mismo evento es capturado por el Pixel y también enviado por la Conversions API, el event_id es lo que impide que Meta cuente ese evento dos veces. Cada evento lleva un identificador único, generado de tu lado, repetido en las dos fuentes: el mismo valor en el eventID del Pixel y en el event_id del evento de servidor.

La comparación funciona así: Meta cruza event_id y nombre del evento entre las dos fuentes y, si hay coincidencia, conserva solo una ocurrencia. Según la documentación oficial de deduplicación de Meta, esa comparación solo es válida dentro de una ventana de 48 horas a partir del primer evento recibido con ese identificador.

Quien envía por el servidor sin repetir el event_id del Pixel corre el riesgo opuesto al que motivó el proyecto: en lugar de faltar datos, el mismo evento aparece duplicado en el reporte, inflando el número de conversiones y distorsionando el costo por resultado.

Calidad de coincidencia: los datos que hacen que el evento sea reconocido

La calidad de coincidencia mide cuántos de los parámetros enviados Meta logró asociar a un perfil real dentro de su propia base. Cuantos más parámetros coinciden, mayor es la probabilidad de que el evento de venta se vincule correctamente al clic y a la campaña que originaron ese lead.

Los parámetros que más pesan en esa coincidencia son:

• Correo electrónico y teléfono , siempre enviados con hash (nunca en texto plano).
• fbc , el identificador de clic capturado en el momento del lead.
• fbp , el identificador de navegador generado por el propio Pixel.
• external_id , un identificador interno estable de tu CRM para ese contacto.

Si faltan esos campos, Meta aún intenta asociar el evento por otras señales, pero con una tasa de acierto mucho menor. Un CRM que guarda correo y teléfono con formato inconsistente, o que nunca capturó el fbc en el formulario de origen, está pagando ese precio sin verlo en ningún reporte.

Paso a paso para conectar el CRM a la Conversions API

Conectar el CRM a la Conversions API es una secuencia corta de decisiones técnicas, no un proyecto de meses. En la práctica, el trabajo sigue este orden:

1. Capturar el fbc (y, cuando exista, el fbp ) en el formulario de origen del lead, junto con correo y teléfono.
2. Definir los hitos del embudo comercial que valen como evento (oportunidad creada, venta cerrada, venta perdida).
3. Armar el evento de servidor en el formato exigido por la API, con los parámetros con hash, el action_source correcto y el valor de la venta cuando corresponda.
4. Reutilizar el mismo event_id cuando el mismo suceso también sea capturado por el Pixel, para evitar el conteo doble.
5. Enviar el evento en el momento en que el CRM registra el cambio de etapa, no en lote a fin de mes.
6. Monitorear la calidad de coincidencia en el Administrador de Eventos y corregir los campos que estén llegando vacíos o mal formateados.

Errores que cuestan datos sin generar ninguna alerta en el panel

Ninguno de los errores más comunes aparece como falla en el reporte de la campaña, porque Meta simplemente no recibe el dato que faltó. Los más frecuentes:

• No capturar el fbc en el formulario, lo que elimina el vínculo directo con el clic original.
• Enviar correo y teléfono sin hash, o con un formato distinto al exigido (el hash de un número con y sin el noveno dígito, por ejemplo, genera valores diferentes).
• Esperar el fin de mes para enviar los eventos en lote, cuando parte de ellos ya pasó de la ventana útil de coincidencia.
• Duplicar el envío entre Pixel y servidor sin repetir el mismo event_id en ambos extremos.

Cada uno de estos puntos es silencioso: el panel de medios pagos sigue en pie, el dashboard de medios pagos sigue mostrando números, y solo cuando alguien compara el ingreso real del CRM con lo que la campaña dice haber generado aparece la diferencia.

Dónde entra Laiki

El caso de Incorporadora Valor Real muestra este cierre de ciclo en la práctica. Laiki guarda el fbc junto al lead desde la entrada, en la misma ficha donde están el origen, los eventos y la etapa del embudo. Cuando ese lead llega a una etapa que le interesa al negocio, la plataforma arma y envía el evento correspondiente a la Conversions API automáticamente, con el event_id reutilizado de lo que ya se capturó en el navegador.

Esto le quita al equipo la tarea manual de armar el payload, aplicar hash campo por campo y acordarse de enviar a tiempo. La campaña pasa a optimizar por lo que se convirtió en negocio en el CRM, y no solo por lo que se convirtió en formulario, con la API de Conversiones de Meta recibiendo ese dato en el momento justo en lugar de en un lote atrasado.

Preguntas frecuentes

¿La API de Conversiones de Meta reemplaza al Pixel? No. Las dos trabajan juntas: el Pixel cubre lo que ocurre en el navegador, la API de Conversiones cubre lo que ocurre fuera de él, como los eventos del CRM. Usar las dos al mismo tiempo, con el event_id compartido, es el escenario recomendado.

¿Necesito un equipo técnico dedicado para configurar esto? Se necesita alguien que arme la integración entre el CRM y la API, pero una vez configurado el envío pasa a ser automático. El trabajo se concentra en la etapa inicial de mapear los hitos del embudo y los campos de coincidencia.

¿En cuánto tiempo la venta enviada por el CRM aparece reflejada en la campaña? Meta procesa el evento en minutos, pero el efecto sobre la optimización de la campaña se acumula a lo largo de días, a medida que el algoritmo recibe suficiente volumen de eventos de venta para ajustar la entrega.