# La Conversions API de Meta explicada para quien no es dev > Qué resuelve la Conversions API, cómo evitar contar una compra dos veces con event_id y qué ayuda a Meta a reconocer quién compró. - URL: https://relator.digital/es/blog/conversions-api-meta - Publicado: 2026-10-15 - Atualizado: 2026-10-15 - Autor: Time Relator Digital - Categoria: marketing-data La Conversions API (CAPI) es un canal para que tu servidor envíe a Meta los eventos de negocio, como una compra o un lead, sin depender solo del navegador. No reemplaza al Pixel: Meta recomienda usar los dos al mismo tiempo, compartiendo los mismos eventos. Para que Meta no cuente la misma compra dos veces, cada evento lleva el mismo `event_id` en los dos canales. > [!NOTE] > **En resumen** > - La CAPI envía eventos de tu servidor, sitio, app o CRM a Meta; se procesan como los eventos del Pixel. > - El uso recomendado es Pixel y CAPI juntos, con los mismos eventos. > - Para deduplicar, `event_name` y `event_id` deben ser idénticos en los dos canales, y ambos deben llegar en un máximo de 48 horas. > - Cuantos más datos del cliente (como correo y teléfono con hash) lleve el evento, mayor la probabilidad de que Meta reconozca a la persona. > - Un evento con más de 7 días hace fallar toda la solicitud. ## Qué resuelve la Conversions API El Pixel corre en el navegador de la persona. La CAPI corre en tu servidor, que ya sabe cuándo se pagó un pedido, cuándo se calificó un lead o cuándo se cerró una venta en el CRM. La documentación de Meta describe la CAPI como una conexión entre los datos de marketing del anunciante y Meta, desde servidores, sitios, apps y CRM, usada para mejorar la segmentación, reducir el costo por resultado y medir resultados. Un punto que ayuda a perder el miedo: según la documentación, los eventos de servidor se procesan como los eventos enviados por el Pixel. Sirven para medición, informes y optimización de la misma manera. No existe un "tipo de conversión" aparte para la CAPI. Eso no significa que la CAPI corrija cualquier problema de medición. Envía lo que tu servidor sabe. Si el servidor registra el evento equivocado, Meta recibe el evento equivocado. ## Pixel y CAPI juntos, no uno en lugar del otro La página de buenas prácticas dice: usa la Conversions API además del Pixel de Meta y comparte los mismos eventos por las dos herramientas. La consecuencia es directa. Si los dos canales envían la misma compra, Meta recibe dos notificaciones de la misma venta. Sin una forma de reconocer que son la misma, el informe mostraría el doble. ![Pixel y servidor envían la misma compra; Meta conserva una](https://uploads.relator.digital/blog/conversions-api-meta/bf3c3fc3-deduplicacao.es.svg "El mismo event_id en los dos canales hace que Meta descarte el segundo evento") ## Deduplicación: el papel del event_id Para que Meta trate dos eventos como uno, la documentación pide estas coincidencias: - el `eventID` del Pixel debe ser igual al `event_id` de la CAPI; - el `event` del Pixel debe ser igual al `event_name` de la CAPI. Si las dos claves coinciden y los eventos se enviaron al mismo Pixel ID en un máximo de 48 horas, Meta descarta los eventos siguientes. Cuando el contenido de los dos eventos no difiere de forma relevante, la documentación dice que Meta en general prefiere el evento recibido primero. La página no define qué es "difiere de forma relevante", así que no cuentes con una regla más allá de esa. El `event_id` es opcional, pero recomendado. La documentación dice que puede ser cualquier texto único que elijas, y cita el número de pedido o el identificador de transacción como buenas opciones. Si no hay un identificador natural, sirve un valor aleatorio, siempre que sea el mismo en el evento del navegador y en el del servidor. ### Existe un plan B, pero es más frágil Meta también describe la deduplicación por `event_name` más `fbp` y/o `external_id`. El `fbp` es el identificador del navegador, que viene de la cookie `_fbp`; el `external_id` es un identificador tuyo para la persona. La propia documentación enumera una limitación: el evento de servidor no se descarta si no se recibió ningún evento de navegador en las últimas 48 horas, aunque un evento de navegador idéntico llegue después del de servidor. Y una advertencia importante: la deduplicación no ocurre cuando usas una única fuente, solo navegador o solo servidor. Sirve para el par Pixel más CAPI. ### Un ejemplo hipotético del daño Los números siguientes son inventados para ilustrar la cuenta. Una tienda gasta R$ 10.000 en anuncios en un mes y vende 100 pedidos de R$ 300, lo que da R$ 30.000 de ingresos y un ROAS de 3,0 (30.000 ÷ 10.000). Supón que el Pixel registre 70 de esos pedidos y que el servidor envíe los 100. Sin un `event_id` compartido, Meta podría recibir 170 compras. | Escenario | Compras | Ingresos | ROAS | | --- | --- | --- | --- | | Realidad | 100 | R$ 30.000 | 3,0 | | Pixel y CAPI sin `event_id` (hipótesis) | 170 | R$ 51.000 | 5,1 | | Pixel y CAPI con `event_id` | 100 | R$ 30.000 | 3,0 | La cuenta cuadra: 170 × R$ 300 = R$ 51.000, y 51.000 ÷ 10.000 = 5,1. Un ROAS inflado un 70% (5,1 contra 3,0) llevaría a decisiones de presupuesto basadas en un retorno que no existe. Por eso conviene revisar la deduplicación antes de cualquier otra optimización. ## Los campos que Meta pide en cada evento Cada evento de la CAPI tiene un conjunto de campos. Según la documentación, los principales son: - `event_name`: obligatorio, el nombre del evento estándar o personalizado. - `event_time`: obligatorio, en segundos Unix, en GMT. - `action_source`: obligatorio, indica dónde ocurrió la conversión. Los valores incluyen `website`, `app`, `email`, `phone_call`, `chat`, `physical_store`, `system_generated`, `business_messaging` y `other`. - `event_source_url`: obligatorio para eventos de sitio web. - `client_user_agent`: obligatorio para eventos de sitio web enviados por la CAPI. - `event_id`: opcional, pero recomendado. Dos reglas merecen atención. Primero, `event_time` puede ser de hasta 7 días antes del envío. Si un solo evento de la solicitud es más antiguo, toda la solicitud falla y no se procesa ningún evento. En un lote, un evento atrasado tumba a todos. Segundo, al usar la CAPI declaras que el `action_source` es correcto según tu conocimiento; para eventos offline, el valor no debe ser `website`. Sobre el momento del envío, la documentación dice que puedes compartir los eventos en tiempo real o en lotes cercanos al tiempo real. No da un plazo en minutos, así que la regla práctica es el límite de 7 días de `event_time` y la ventana de 48 horas de la deduplicación. ## Datos del cliente y calidad de coincidencia Para usar un evento en la atribución y en la optimización de la entrega, Meta necesita asociarlo a una persona. La documentación dice que solo los eventos con coincidencia sirven para estos dos usos, y que enviar más parámetros de información del cliente puede ayudar a aumentar la calidad de coincidencia de eventos (*Event Match Quality*). Los parámetros incluyen correo (`em`), teléfono (`ph`), nombre (`fn`, `ln`), `fbp`, `fbc` (de la cookie `_fbc`, que guarda el identificador de clic), `external_id`, `client_ip_address` y `client_user_agent`. Las reglas de formato son estrictas: - `em`, `ph`, `fn`, `ln` y otros campos personales deben pasar por hash SHA-256 antes del envío. - Antes del hash, al correo se le quitan los espacios de los extremos y se pasa a minúsculas. El teléfono pierde símbolos, letras y ceros a la izquierda e incluye el código de país: el ejemplo de Meta convierte (650) 555-1212 en `16505551212`. - `client_ip_address`, `client_user_agent`, `fbp` y `fbc` no pasan por hash. La IP debe ser la real, una dirección IPv4 o IPv6 válida. - `external_id` tiene el hash recomendado, no obligatorio. La documentación también advierte que las combinaciones demasiado amplias, como nombre más género (`fn` + `ge`), son inválidas para la coincidencia. No sirve enviar muchos campos débiles: un correo o teléfono correcto vale más. > [!WARNING] > Los datos del cliente son datos personales. Antes de enviar correo o teléfono, confirma con tu cliente la base legal y el aviso de privacidad del sitio. Este artículo no trata ese análisis. ## Dónde entra Relator Relator Digital conecta Meta, Google Ads, GA4 y el CRM del cliente en una sola base, y cruza los negocios ganados en HubSpot o RD Station CRM con la campaña que trajo el lead. No envía eventos a Meta por la CAPI. Su papel aquí es otro: ayudar a comprobar si lo que reporta Meta es coherente con los ingresos que registra el CRM. ## Cómo aplicarlo 1. Lista los eventos que importan (compra, lead, lead calificado) y confirma que el Pixel ya los envía. 2. Elige un `event_id` por evento, de preferencia el número de pedido o el identificador del lead, y usa el mismo valor en el Pixel y en la CAPI. 3. Mantén `event_name` idéntico en los dos canales. 4. Envía `action_source`, `event_source_url` y `client_user_agent` en cada evento de sitio web. 5. Agrega `em` y `ph` normalizados y con hash SHA-256 cuando tengas base legal, además de `fbp` y `fbc` cuando existan. 6. Nunca envíes un evento con `event_time` de más de 7 días: separa los atrasados antes de armar el lote. 7. Durante una semana, compara las compras de Meta con las de tu servidor. Si Meta muestra bastantes más, sospecha de la deduplicación. ## Fuentes Todas consultadas el 15 de octubre de 2026. Quedaron fuera, por no haber podido leer la página del Centro de ayuda de Meta, la puntuación y la escala de la calidad de coincidencia de eventos, además del código de ejemplo del Pixel con `eventID`. - Meta for Developers, [Conversions API](https://developers.facebook.com/docs/marketing-api/conversions-api/): qué hace la API y que los eventos se procesan como los del Pixel. - Meta for Developers, [Best Practices](https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices): uso junto con el Pixel, campos obligatorios y calidad de coincidencia. - Meta for Developers, [Deduplicate Pixel and Server Events](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events): reglas de `event_id` y `event_name`, ventana de 48 horas y plan B con `fbp`. - Meta for Developers, [Server Event Parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/server-event): `event_time` con límite de 7 días, `action_source` y `event_source_url`. - Meta for Developers, [Customer Information Parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters): hash SHA-256 y normalización.