Compara las compras que el píxel de Meta reportó el mes pasado con los pedidos en el admin de tu tienda. Los números no van a coincidir. Los bloqueadores de anuncios matan el script antes de que cargue, iOS y Safari estrangulan sus cookies, los banners de consentimiento lo suprimen, y una parte de los compradores cierra la pestaña antes de que dispare la página de gracias. Cada una de esas compras perdidas es una venta de la que el algoritmo de Meta nunca aprendió — y un pedido sin crédito para tus campañas.
La API de Conversiones existe para cerrar exactamente ese hueco. Esta guía cubre qué es realmente la CAPI, por qué lo recomendado es redundancia y no reemplazo, cómo la deduplicación por event_id mantiene tus números honestos, y qué campos de usuario suben el Event Match Quality.
Qué Es Realmente la API de Conversiones
El píxel del navegador es un JavaScript que corre dentro del navegador del visitante. Observa lo que pasa en la página y se lo reporta a Meta — siempre que nada se lo impida.
La API de Conversiones es el mismo flujo de eventos enviado desde tu servidor. Cuando un pedido aterriza en tu backend — confirmado, pagado, real — tu sistema hace una llamada HTTPS al endpoint de Meta con el evento. No hay script que bloquear, no hay cookie de terceros que expire, no hay dependencia de que el navegador del comprador sobreviva al checkout. Si el pedido existe en tu base de datos, el evento llega.
Dos cosas que la CAPI no es:
- Una taxonomía de eventos distinta. Los eventos de servidor usan los mismos nombres que el píxel —
Purchase,AddToCart,InitiateCheckout— así que tus campañas y conversiones personalizadas siguen funcionando sin cambios. - Un reemplazo del píxel. Enviar solo eventos de servidor descarta el contexto de navegador que el servidor nunca ve. El patrón recomendado son los dos, juntos.
Por Qué la Redundancia Le Gana al Reemplazo
El píxel y el servidor tienen puntos ciegos — y, convenientemente, puntos ciegos distintos:
| Píxel del navegador | API de Conversiones | |
|---|---|---|
| Corre en | El navegador del visitante | Tu servidor |
| Bloqueado por ad blockers | Sí | No |
| Afectado por los límites de cookies de Safari/iOS | Sí | No |
Ve las cookies fbp/fbc de forma nativa | Sí | Solo si las capturas y las pasas |
| Conoce el importe realmente cobrado | No — reporta el valor del carrito | Sí — lee el pedido real |
| Puede reportar reembolsos después | No | Sí |
| Dispara eventos de parte alta del funnel (ViewContent) | Barato, en todas partes | Solo con plomería extra |
Corre ambos y cada uno cubre los huecos del otro. Cuenta ilustrativa (no es un benchmark): si tu tienda procesa 1.000 pedidos al mes y el píxel solo logra dispararse en 850, una configuración de solo píxel deja 150 compras invisibles para la optimización de Meta. La configuración redundante entrega las 1.000 — y la deduplicación hace que Meta cuente 1.000, no 1.850.
Esa segunda mitad es la parte en la que los equipos fallan.
Una Venta, Un Evento: Deduplicación por event_id
Con redundancia, Meta recibe la mayoría de las compras dos veces — una del píxel, otra de tu servidor. El contrato de deduplicación es simple: las dos copias deben llevar el mismo event_name y el mismo event_id. Cuando Meta ve la pareja, conserva una y descarta la otra (documentación de deduplicación).
La elección natural para el event_id es el ID del pedido — es único, estable y ambos lados lo conocen al disparar.
Lo que sale mal en la práctica:
- Cada lado genera su propio ID aleatorio. Meta ve dos eventos distintos, cuenta la venta dos veces, y tu ROAS reportado se infla exactamente en la proporción de pedidos donde ambos disparan.
- Un lado omite el
event_idpor completo. Mismo resultado: sin clave, no hay dedup. - Los IDs coinciden pero los nombres de evento no (
Purchasevs.purchaseen una integración hecha a mano). La pareja nunca se une.
Si activaste la CAPI y las conversiones "saltaron" esa misma semana, revisa la deduplicación antes de celebrar. El salto suele ser conteo doble disfrazado de éxito.
Event Match Quality: La Nota Que Decide Si Tus Datos Cuentan
Un evento de servidor solo sirve si Meta puede vincularlo a una persona. El Event Match Quality (EMQ) es la puntuación de 1 a 10 en el Administrador de Eventos que califica exactamente eso, por tipo de evento (sobre el EMQ). Un EMQ bajo significa que los eventos llegan pero no coinciden con nadie — existen y no cambian nada.
Los campos de user_data que suben la nota:
- Email (hash SHA-256) — el identificador que hace el trabajo pesado; tu checkout lo tiene en cada pedido.
- Teléfono (hash SHA-256) — fuerte por sí solo, más fuerte combinado con el email.
- Dirección IP del cliente + user agent — contexto de navegador que el servidor debe reenviar explícitamente, porque la petición a Meta sale de tu datacenter, no del dispositivo del comprador.
- Cookie
fbp— el identificador de navegador de Meta, escrito por el píxel en tu dominio. - Cookie
fbc— presente cuando la visita vino de un clic en un anuncio de Meta; lleva el ID del clic y es la línea más directa de vuelta a la campaña. external_id— tu propio ID de cliente, útil para compradores recurrentes.
El píxel envía fbp y fbc automáticamente. Tu servidor no los tiene a menos que algo los haya capturado en el momento del clic y los haya guardado con la sesión, para reutilizarlos cuando el pedido llegue minutos o días después. Esa plomería es el hueco más común en las integraciones de CAPI caseras — y es exactamente para lo que sirve una capa de tracking first-party. El pipeline de Decisa, por ejemplo, registra fbc, fbp y los IDs de clic en el instante en que el visitante aterriza, y los adjunta al pedido verificado antes de empujar el evento por el servidor: la compra llega con la identidad completa, no con un email pelado.
Poner Compras Verificadas a Fluir Esta Semana
- Conserva el píxel. La redundancia es el patrón; no se arranca nada.
- Elige tu fuente server-side. Integración nativa de la plataforma (Shopify y los grandes checkouts la traen), un gestor de etiquetas server-side, integración directa con la API, o una plataforma de atribución que envíe por ti; la vía directa da más control sobre el
user_data. - Define
event_id= ID del pedido en ambos lados. El evento de compra del píxel y el del servidor deben llevar el valor idéntico. - Envía el
user_datamás rico que puedas, dentro de la ley. Email y teléfono con hash desde el pedido, IP y user agent de la sesión original,fbp/fbccapturados en el clic. - Verifica en el Administrador de Eventos antes de confiar en nada. Usa la herramienta de eventos de prueba, confirma que los eventos de servidor llegan y se deduplican, y vigila la nota de EMQ de tu evento de Purchase.
- Envía la verdad, no el carrito. Reporta el importe realmente cobrado, dispara solo con el pago confirmado y maneja los reembolsos — un algoritmo entrenado con pedidos cancelados optimiza hacia pedidos cancelados.
El píxel le cuenta a Meta lo que pasó en el navegador. La CAPI le cuenta a Meta lo que pasó en tu negocio. Un e-commerce necesita ambos — atados al mismo event_id, con identidad suficiente para el match — porque las campañas solo pueden optimizar hacia las ventas que les dejas ver.