Los formularios de Facebook pueden generar contactos que no encajan con el negocio. El enfoque del artículo de Make del 8 de agosto de 2024 consistía en devolver a Meta señales del CRM sobre el avance de esos contactos, en vez de medir solo cuántos formularios se recibían.
Esta es una explicación contextualizada de aquel flujo. No es una receta de interfaz vigente ni promete mejorar el retorno publicitario. El resultado depende de la calidad de los datos, la configuración y los requisitos aplicables a las cuentas.
Qué problema intentaba resolver
Un formulario enviado no equivale a un contacto cualificado. El original proponía comunicar estados posteriores del CRM para distinguir los contactos que avanzaban en el embudo.
La idea era cerrar la relación entre captación y resultado comercial. No demuestra que una campaña concreta vaya a conseguir contactos más baratos o de mayor valor.
Recomendación editorial: el equipo de anuncios y el del CRM deben acordar qué significa cada estado. Una etiqueta que cada persona interpreta de forma distinta no produce una señal consistente.
Condiciones del ejemplo histórico
La guía de 2024 exigía que los contactos procedieran de Facebook Lead Ads, que se conservara su lead ID y que se confirmara su recepción. También daba umbrales de volumen, conversión y tiempo de avance.
Esos umbrales pertenecen a la publicación de 2024. No se reproducen como requisitos vigentes confirmados ni se sustituyen por condiciones comerciales de Make: son cuestiones técnicas y publicitarias de Meta.
Arquitectura de los dos escenarios
1. Confirmar la recepción y guardar el contacto
El primer escenario descrito seguía este orden:
- Recibir el contacto con Facebook Lead Ads.
- Enviar mediante Facebook Conversions API el evento de recepción, con la hora y el identificador del contacto.
- Crear el registro en el CRM y guardar el lead ID en un campo preparado para ello.
La confirmación de recepción era un paso explícito del original. No bastaba con crear un registro en el CRM y esperar al siguiente cambio.
2. Devolver los cambios de estado
El segundo escenario observaba cambios en el CRM y utilizaba Facebook Conversions API for CRM para enviarlos a Meta. El ejemplo mapeaba el estado al nombre del evento y conservaba la relación con el lead ID.
Las capturas del artículo mostraban Salesforce. No se infiere de ellas compatibilidad automática con cualquier CRM ni se presentan plantillas de otros productos como parte de la guía.
Requisitos que deben comprobarse hoy
La documentación oficial de Facebook Conversions API for CRM en Make, consultada el 29 de septiembre de 2026, presenta la app para crear eventos de lead en la cuenta de Facebook Conversions API. La sección Requirements (applies to legacy setups) describe el procedimiento manual: cuenta de Facebook y de Business Manager, un píxel específico de tipo CRM creado en el Administrador de eventos, el envío de eventos «Lead» al recibir contactos y de los cambios de estado posteriores. La cuenta conectada debe administrar la cuenta publicitaria y el píxel, y la configuración del embudo se completa en los ajustes del píxel. La lista de acciones de la versión consultada incluye Create a Lead Event (conexión, nombre del evento y Pixel ID); esta documentación no describe una creación automática del píxel.
La documentación aclara que, desde octubre de 2025, el lead ID deja de ser obligatorio cuando se proporciona una dirección de correo, aunque recomienda incluirlo cuando esté disponible. Algunos textos de campos siguen describiendo el recorrido antiguo; no conviertas el requisito del blog de 2024 en una regla universal para todas las conexiones actuales.
Revisa la versión aplicable antes de configurar el flujo. La documentación consultada organiza los requisitos como propios de configuraciones antiguas (legacy setups) y lista la acción Create a Lead Event. Para detalles de Meta, esa página enlaza su guía de Conversions API for CRM para plataformas. No mezcles pasos de la guía de 2024 con la interfaz actual sin comprobarla.
Cómo interpretar los pasos de configuración
Preparar el origen de eventos
La guía empezaba por crear un píxel independiente para eventos del CRM en Events Manager, en lugar de reutilizar el píxel web. Esa separación coincide con el requisito de píxel de tipo CRM que recoge la documentación consultada. Esta página no valida la interfaz actual de Meta.
No compartas credenciales ni tokens en capturas o documentos del equipo. Consulta el procedimiento oficial correspondiente a tu cuenta.
Conservar los identificadores
Recomendación editorial: verifica con un registro de prueba que el lead ID llega al campo esperado y no se sustituye por un ID interno distinto. Comprueba tanto la recepción inicial como el evento posterior.
Definir qué estados se envían
No todos los cambios administrativos representan un avance comercial. Revisa el significado de cada evento y la información que recibe Meta.
La documentación de Make describe campos como nombre y hora del evento y los datos de usuario aplicables. Esta guía no valida consentimiento, base jurídica ni cumplimiento de políticas publicitarias para tu caso.
Revisar antes de cambiar la campaña
El original explicaba cómo ordenar estados del embudo y pasar a una optimización orientada a conversiones de contactos. Sus plazos y nombres de controles son contexto histórico.
Criterio editorial: comprueba recepción y significado de los eventos antes de modificar una campaña. Una ejecución sin errores no demuestra que los datos sean adecuados para optimizar anuncios.
Qué conservar de la idea
No te limites a contar formularios: comprende qué contactos avanzan. Conserva identificadores, confirma recepción y contrasta los requisitos oficiales antes de enviar datos.