¿Necesito tanto el píxel de Meta como la Conversions API?

Meta recomienda usar ambos. El píxel añade datos del navegador, como la cookie fbp, y la Conversions API entrega los eventos que el navegador pierde. Da a las dos copias el mismo nombre de evento y el mismo id de evento para que Meta cuente cada evento una sola vez.

¿Cuánto espera Meta para deduplicar un evento del navegador y uno del servidor?

Meta deduplica un evento del navegador y uno del servidor con el mismo nombre de evento y el mismo id de evento cuando llegan con menos de 48 horas de diferencia. Una copia que llega más tarde se cuenta de nuevo.

¿La Conversions API necesita que los datos del cliente tengan hash?

Sí, en el caso de los datos de contacto. Los campos de email, teléfono, nombre y dirección deben normalizarse y aplicarles un hash SHA-256. La dirección IP, el user agent, fbp y fbc se envían sin hash.

¿Qué campos son obligatorios para un evento de sitio web?

Todo evento necesita event_name, event_time, action_source y al menos un parámetro de información del cliente. Para los eventos de sitio web, Meta exige además event_source_url y client_user_agent.

¿Puedo enviar pedidos antiguos a través de la Conversions API?

Solo los recientes. El event_time puede estar como máximo 7 días en el pasado, y si un evento de una solicitud es más antiguo, Meta rechaza toda la solicitud.

Meta Conversions API (CAPI): guía práctica

Ideas clave

La Meta Conversions API envía eventos como Purchase desde tu servidor, de modo que llegan a Meta incluso cuando el píxel del navegador está bloqueado.
Ejecútala junto al píxel y da a ambas copias el mismo nombre de evento y el mismo event_id; así, Meta cuenta el evento una sola vez si ambas llegan en un plazo de 48 horas.
Los eventos de sitio web necesitan action_source, event_source_url y el user agent del comprador; el email y el teléfono con hash, la dirección IP, fbp y fbc determinan lo bien que Meta puede vincularlos.
Prueba con la pestaña Test events de Events Manager y después elimina el código de prueba, porque los eventos de prueba no se descartan.
La mayoría de los problemas vienen de ids de evento que no coinciden, de la propia dirección IP del servidor, de un fbclid perdido o de datos de contacto a los que se aplicó el hash sin normalizarlos.

La Meta Conversions API (CAPI) permite que tu servidor envíe eventos como Purchase directamente a Meta. El píxel de Meta envía los mismos eventos desde el navegador del comprador. CAPI los envía desde tu servidor, así que siguen llegando cuando un bloqueador de anuncios detiene el píxel, falta una cookie o la página de agradecimiento nunca se carga.

Esta guía explica qué contiene un evento de la Conversions API, cómo ejecutarla junto al píxel con un único event_id, qué parámetros exige y recomienda Meta, cómo probar con Test events y los errores que aparecen con más frecuencia.

¿Qué es la Meta Conversions API?

La Conversions API forma parte de la Graph API de Meta. Tu servidor envía una solicitud HTTPS POST a graph.facebook.com/VERSION/PIXEL_ID/events con un token de acceso y una lista data de hasta 1,000 eventos. Cada evento describe una acción, como una compra, en tres partes: qué ocurrió, quién lo hizo y los detalles.

Campo	Qué contiene
`event_name`	La acción, por ejemplo `Purchase`, `AddToCart` o `InitiateCheckout`
`event_time`	Cuándo ocurrió, como marca de tiempo Unix en segundos
`event_id`	Un id único para este evento, usado para deduplicarlo frente al píxel
`action_source`	Dónde ocurrió: `website` para las compras de la tienda
`event_source_url`	La URL de la página donde ocurrió el evento
`user_data`	Datos del cliente para la coincidencia: email y teléfono con hash, dirección IP, user agent, fbp y fbc
`custom_data`	Detalles como `value`, `currency` y `content_ids`

Todo evento de la Conversions API tiene la misma estructura: la acción, los datos del cliente y los detalles.

Así se ve un evento Purchase reducido:

Conversions API: un evento Purchase (abreviado)

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1792929600,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkouts/thank-you",
    "user_data": {
      "em": ["<SHA-256 of the normalized email>"],
      "ph": ["<SHA-256 of the normalized phone>"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; ...)",
      "fbp": "fb.1.1792928400000.1234567890",
      "fbc": "fb.1.1792928400000.AbCdEf123"
    },
    "custom_data": { "value": 74.00, "currency": "USD" }
  }]
}

Los campos de contacto, como el email y el teléfono, se normalizan y se les aplica un hash SHA-256 antes de salir de tu servidor. La dirección IP, el user agent, fbp y fbc se envían tal cual.

¿Por qué ejecutar la Conversions API junto al píxel?

Meta recomienda ejecutar la Conversions API junto con el píxel y enviar los mismos eventos por ambos. Cada uno ve algo que el otro no ve, y juntos dan a Meta datos más completos.

Píxel de Meta (navegador)

Crea la cookie _fbp y guarda el fbclid de un clic en un anuncio en la cookie _fbc
Ve la página y el navegador mientras ocurre la visita
Se pierde cuando el navegador lo bloquea o la página no se carga

Conversions API (servidor)

Envía el pedido pagado desde los datos de tu tienda
Puede añadir email, teléfono y dirección con hash a partir del pedido
No depende del navegador, así que los bloqueadores de anuncios no lo detienen

El píxel aporta los identificadores del navegador y el servidor aporta el pedido. Cada uno por separado se pierde parte del panorama.

El coste de ejecutar ambos es que Meta recibe ahora dos copias de cada evento. La siguiente sección muestra cómo Meta se queda con una sola.

¿Cómo funciona la deduplicación con un solo event_id?

Meta trata un evento del navegador y un evento del servidor como el mismo evento cuando coinciden dos cosas: el nombre del evento y el id del evento. En el píxel, el id va en la opción eventID. En la Conversions API, el mismo valor va en event_id.

Píxel de Meta: el mismo Purchase con eventID

fbq('track', 'Purchase', { value: 74.00, currency: 'USD' }, { eventID: 'order-1042' });

El comprador pagaPedido 1042, $74.00

El píxel envía PurchaseeventID order-1042, desde el navegador

El servidor envía Purchaseevent_id order-1042, desde el pedido

Meta cuenta unoMismo nombre e id en 48 horas

Ambas copias llevan el mismo nombre e id de evento, así que Meta se queda con una compra en lugar de dos.

Meta deduplica una pareja que coincide solo cuando las dos copias llegan con menos de 48 horas de diferencia. Unas cuantas reglas hacen que esto funcione en la práctica:

Crea el id una sola vez. Constrúyelo a partir de algo que conozcan ambos lados, como el número de pedido, y pásalo tanto al navegador como al servidor. Dos sistemas que construyen cada uno su propio id no coincidirán.
Usa un único formato. order-1042 y 1042 son ids distintos.
Haz coincidir el nombre del evento exactamente. Purchase y purchase son eventos distintos.
Envía el evento del servidor sin demora. Un evento del servidor que llega más de 48 horas después del evento del navegador se cuenta una segunda vez.

Meta describe también un segundo método que empareja los eventos por fbp o external_id. Meta dice que, por lo general, solo funciona cuando el evento del navegador llega antes que el del servidor, así que un event_id compartido es la opción más fiable. Si Meta sigue informando de más compras de las que tuvo tu tienda, nuestra guía sobre eventos de compra duplicados enumera las causas habituales.

¿Qué parámetros son obligatorios y cuáles son recomendados?

Los campos obligatorios hacen que un evento sea válido. Los campos recomendados determinan cuántos de tus eventos puede vincular Meta con una persona, y solo los eventos vinculados pueden usarse para la atribución y la entrega de anuncios.

Parámetro	Eventos de sitio web	Qué enviar
`event_name`	Obligatorio	Un evento estándar como Purchase, o un nombre de evento personalizado
`event_time`	Obligatorio	Hora Unix en segundos, como máximo 7 días en el pasado
`action_source`	Obligatorio	`website` para eventos de tu tienda
`event_source_url`	Obligatorio	La URL de la página donde ocurrió el evento
`client_user_agent`	Obligatorio	La cadena del navegador del comprador, no la de tu servidor
`user_data`	Obligatorio	Al menos un parámetro de información del cliente
`event_id`	Recomendado	El mismo id que usa el píxel, para la deduplicación
`em`, `ph`	Recomendado	Email y teléfono, normalizados y con hash SHA-256
`client_ip_address`	Recomendado	La dirección IP del comprador, sin hash
`fbp`, `fbc`	Recomendado	Las cookies de id de navegador y de click id, sin hash
`external_id`	Recomendado	Tu propio id de cliente, el mismo en los eventos del navegador y del servidor
`value`, `currency`	Enviar con Purchase	El valor del pedido y un código de moneda de tres letras

Meta indica que action_source, event_source_url y client_user_agent son obligatorios para los eventos de sitio web enviados a través de la Conversions API.

Tres detalles causan la mayoría de los problemas:

Normaliza antes de aplicar el hash. Meta espera el email sin espacios sobrantes y en minúsculas, y los teléfonos como dígitos con el prefijo del país. Anna@Example.com y anna@example.com dan hashes distintos, y solo el segundo puede coincidir.
No apliques el hash a los identificadores del navegador. fbp, fbc, la dirección IP y el user agent se envían como valores en claro.
Conserva el click id exactamente como es. El valor de fbc es fb.1., la hora de creación en milisegundos, un punto y el fbclid de la URL de la página de llegada. El fbclid distingue entre mayúsculas y minúsculas. Guárdalo cuando el visitante llegue, porque ya no está en la URL en el checkout.

Lo bien que coinciden estos campos es lo que mide la puntuación Event Match Quality de Meta. Nuestra guía sobre Event Match Quality trata cada parámetro, las reglas del hash y la puntuación que conviene buscar.

¿Cómo se prueban los eventos con Test events?

Events Manager tiene una pestaña Test events que muestra los eventos según llegan. Úsala antes de fiarte de una configuración nueva.

Abre Test events
En Events Manager, selecciona tu conjunto de datos (píxel) y abre la pestaña Test events. Copia el código de prueba que muestra.
Añade el código a tus eventos del servidor
Envíalo como test_event_code en la solicitud. En ROASaurus, pégalo en el campo Test event code del píxel de Meta.
Haz un pedido de prueba
Visita la tienda, añade un producto y paga, de modo que tanto el píxel como el servidor envíen un Purchase.
Compara las dos copias
Ambas copias deben mostrar el mismo nombre de evento, id de evento, valor y moneda.
Revisa la información del cliente
El evento del servidor debe llevar el email y el teléfono con hash, la dirección IP, el user agent y fbp, además de fbc si la visita empezó con un clic en un anuncio.
Quita el código de prueba
Meta indica que el campo es solo para pruebas, así que quítalo antes de fiarte de los eventos.

Purchase browser order-1042 74.00 USDDesde el píxel

Purchase server order-1042 74.00 USDDesde la Conversions API

event_name + event_id matchContado como una sola compra

em ph fbp fbc client_ip_address client_user_agentInformación del cliente en el evento del servidor

Lo que muestra un buen pedido de prueba (valores de ejemplo): dos copias, un id e información completa del cliente.

Errores habituales de la Conversions API y cómo solucionarlos

Lo que ves	Causa probable	Solución
Toda la solicitud falla y no se procesa ningún evento	Un evento del lote tiene un event_time de más de 7 días de antigüedad	Envía los eventos cuando ocurren. Corrige o descarta los eventos antiguos antes de reintentar.
Meta informa de más compras de las que tuvo tu tienda	Ids de evento distintos, un evento del píxel sin eventID o una segunda app que envía el mismo píxel	Usa un único id para ambas copias y un único emisor del servidor por píxel.
Baja calidad de coincidencia en los eventos del servidor	Tu servidor envía su propia dirección IP y su propio user agent	Reenvía la dirección IP y el user agent registrados del navegador o del pedido del comprador.
Pocos eventos con fbc	El fbclid no se guardó en la página de llegada, o se modificó	Guarda el fbclid exactamente como llega y construye fbc a partir de él.
El email y el teléfono no coinciden	Valores a los que se aplicó el hash sin normalizarlos, o enviados sin hash	Quita los espacios sobrantes y pasa el email a minúsculas, conserva los dígitos y el prefijo del país del teléfono y después aplica el hash SHA-256.
Las solicitudes fallan con un error de token caducado	El token de acceso procede de un inicio de sesión de Facebook, y los tokens de inicio de sesión caducan	Vuelve a conectar, o usa un token de System User de Business Manager, que puedes crear sin fecha de caducidad.

La mayoría de los problemas de la Conversions API aparecen como solicitudes rechazadas, dobles conteos o baja calidad de coincidencia.

Después de unos días de tráfico real, abre la pestaña Diagnostics de Events Manager. Meta enumera ahí los problemas con recomendaciones para solucionarlos. Luego compara el recuento diario de Purchase en Events Manager con los pedidos pagados de tu tienda en los mismos días. Si Meta es claramente superior, nuestra página de ayuda sobre cómo evitar el doble conteo enumera los ajustes que debes revisar.

Cómo configurar la Conversions API con ROASaurus

ROASaurus envía los eventos de la Conversions API a partir de los datos de pedido de tu tienda, así que no tienes que construir tú mismo la parte del servidor. En Tracking & platforms, haz clic en Connect with Facebook y elige tu cuenta publicitaria y tu píxel, o pega el id del píxel (conjunto de datos) y un token de la Conversions API. La guía de configuración de Meta recorre ambas opciones, y la página de la integración con Meta enumera todos los campos que se envían.

Un id en ambos lados. Los eventos del navegador y del servidor comparten un id de evento. Para una compra es order- seguido del id del pedido.
Una breve espera antes de la compra. El Purchase del servidor espera un momento tras la llegada del pedido, para que antes pueda unirse el evento de compra del navegador. Su dirección IP, su user agent y la URL de la página salen entonces con el evento del servidor, junto con el fbp y el fbc guardados para el visitante.
Información del cliente a partir del pedido. El email, el teléfono, el nombre y la dirección se normalizan y se les aplica un hash SHA-256. El id de cliente de la tienda y el id de visitante de ROASaurus entran con hash como external_id.
Los eventos que Meta no puede vincular se omiten. Un evento sin fbc, fbp, email, teléfono ni dirección IP no se envía.

El Event log muestra cada envío del servidor con la solicitud y la respuesta de Meta. Si tus márgenes difieren mucho entre productos, también puedes enviar un valor de beneficio junto a cada compra: nuestra guía sobre la optimización de valor en Meta para el beneficio explica cómo. Para el recorrido completo de los datos desde el clic hasta el pedido, consulta server-side tracking.

Fuentes

En ROASaurus

Sigue leyendo

Plataformas publicitarias y tiendas onlineTracking de conversiones en pago contra reembolso y checkouts externosTracking de conversiones en pago contra reembolso: por qué los píxeles no detectan los pedidos COD ni los de checkouts externos, cuándo enviar la compra y cómo gestionar los pedidos rechazados.Plataformas publicitarias y tiendas onlineTracking de conversiones en CCV Shop: guía de configuraciónTracking de conversiones en CCV Shop: envía los pedidos pagados a Meta y TikTok con un webhook firmado, vincúlalos a los clics en anuncios, configúralo, pruébalo y gestiona los pagos tardíos.Plataformas publicitarias y tiendas onlineConversiones mejoradas de Google Ads en ShopifyLas conversiones mejoradas añaden datos de cliente con hash a las compras de Google Ads en Shopify. Cómo funcionan, en qué se diferencian de las importaciones offline y cómo configurarlas.

Meta Conversions API (CAPI): una guía práctica