La Conversions API de Meta explicada para quien no es dev

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.

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.

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.

• Realidad

  Compras

  100

  Ingresos

  R$ 30.000

  ROAS

  3,0

• Pixel y CAPI sin event_id (hipótesis)

  Compras

  170

  Ingresos

  R$ 51.000

  ROAS

  5,1

• Pixel y CAPI con event_id

  Compras

  100

  Ingresos

  R$ 30.000

  ROAS

  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.

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. 1.Lista los eventos que importan (compra, lead, lead calificado) y confirma que el Pixel ya los envía.
2. 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. 3.Mantén event_name idéntico en los dos canales.
4. 4.Envía action_source, event_source_url y client_user_agent en cada evento de sitio web.
5. 5.Agrega em y ph normalizados y con hash SHA-256 cuando tengas base legal, además de fbp y fbc cuando existan.
6. 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. 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: qué hace la API y que los eventos se procesan como los del Pixel.
• Meta for Developers, Best Practices: uso junto con el Pixel, campos obligatorios y calidad de coincidencia.
• Meta for Developers, 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: event_time con límite de 7 días, action_source y event_source_url.
• Meta for Developers, Customer Information Parameters: hash SHA-256 y normalización.