Píxel de Meta y API de conversiones: cómo usar los dos sin contar cada conversión dos veces

Para usar el píxel de Meta y la API de conversiones a la vez sin duplicar resultados, el evento que envía el navegador y el que envía el servidor tienen que llevar el mismo nombre de evento y el mismo identificador (eventID en el píxel, event_id en la API). Meta recomienda usar los dos en configuración redundante, y solo descarta el duplicado si ambos llegan con esos dos campos iguales y dentro de 48 horas desde el primero con ese event_id.

Si tus leads o compras en Meta no cuadran con lo que ves en el CRM, la causa suele estar en uno de estos tres sitios: eventos que llegan por dos vías sin identificador común, varias integraciones enviando el mismo evento o eventos que se disparan en el momento equivocado. Esta guía explica cómo funciona la deduplicación, cómo hacer inventario de quién envía cada evento y qué revisar antes de dar por buena la medición.

¿Píxel, API de conversiones o los dos?

Los dos, porque miden desde lugares distintos y cada uno cubre un hueco del otro:

En su documentación, Meta recomienda implementar la API de conversiones junto al píxel en lo que llama una configuración redundante, y explica que esa configuración exige deduplicar para no contar dos veces el mismo evento (deduplicación de eventos del píxel y del servidor, consultado en septiembre de 2026).

La pregunta “¿API de conversiones o píxel?” tiene truco: elegir solo uno te obliga a aceptar pérdidas (solo píxel) o a renunciar a la señal del navegador (solo servidor). El trabajo real está en que convivan.

¿Cómo deduplica Meta los eventos?

Meta ofrece dos métodos. Conviene conocer los dos porque tienen límites distintos.

Método recomendado: nombre de evento + event_id

Meta considera que dos eventos son el mismo cuando:

• el event del píxel coincide con el event_name de la API de conversiones (por ejemplo, Purchase y Purchase), y
• el eventID del píxel coincide con el event_id de la API de conversiones.

Además, solo deduplica si los eventos llegan dentro de las 48 horas siguientes a la recepción del primero con ese event_id. Un evento de servidor que envías tres días después, por ejemplo al reprocesar una cola de errores, ya no se deduplica contra el del navegador.

Método alternativo: fbp o external_id

También puede comparar event_name con fbp o external_id. Tiene dos limitaciones documentadas: solo funciona cuando el evento llega primero desde el navegador y después desde el servidor, y no descarta el evento del servidor si el del navegador no llega en 48 horas. Sirve como apoyo, no como estrategia principal.

¿Por qué se duplican los eventos en la práctica?

Estos son los patrones que explican la mayoría de cifras infladas o incoherentes:

Si tu plataforma de pago o de cursos envía eventos por servidor además de por navegador, trátala como una fuente más en el inventario: no des por hecho que ya deduplica con lo que tú envías desde GTM o desde tu web.

¿Cómo configuro píxel y API de conversiones sin duplicados?

1. Haz inventario de quién envía cada evento

Antes de tocar nada, rellena esta tabla para cada evento que te importa. Es la plantilla que evita la mayoría de problemas:

Si en una fila aparecen tres herramientas o la columna del event_id está vacía, ya tienes el origen del problema. Cada evento debería tener, como máximo, un emisor en navegador y uno en servidor.

2. Define un identificador único por conversión

El event_id tiene que representar un hecho de negocio, no una carga de página. Los mejores candidatos son identificadores que ya existen en tu operación:

• Compra: el identificador del pedido o de la transacción.
• Registro o lead: el identificador del registro que crea tu formulario o tu CRM.
• Lead cualificado: el identificador del lead en el CRM más el nombre de la etapa.

Lo que no funciona es generar un valor aleatorio en el navegador y otro distinto en el servidor. Los dos lados tienen que poder obtener el mismo valor.

3. Pasa el mismo valor a ambos lados

Si el identificador nace en el servidor (el pedido), expónlo a la página de confirmación para que el píxel lo use como eventID. Si nace en el navegador (un registro que todavía no existe en el servidor), envíalo junto con el formulario para que el servidor lo reutilice como event_id. Es la misma idea que explico en la atribución de leads: un identificador que viaja con el lead de principio a fin.

4. Dispara en la confirmación, no en el clic

Un Lead debería enviarse cuando el registro existe, y un Purchase cuando el pago está aprobado. Disparar al pulsar el botón cuenta intentos, formularios con errores y dobles clics. En pagos que quedan pendientes, decide qué evento se envía y cuándo, y ten presente la ventana de 48 horas.

5. Envía desde el CRM las conversiones que solo existen allí

Muchas búsquedas de “CRM con la API de conversiones de Meta” responden a una necesidad concreta: que Meta aprenda de los leads que de verdad avanzan, no de todos los registros. Si tu venta pasa por llamada o por un equipo comercial, el CRM es el único que sabe qué lead se cualificó o compró. Enviar ese evento desde el CRM, con el identificador del lead, convierte la API de conversiones en una señal de negocio y no solo en una copia de lo que ya mide el píxel.

6. Prueba con una conversión real antes de escalar campañas

Haz una compra o un registro de prueba y verifica en el Administrador de eventos de Meta, con su herramienta de prueba de eventos, que llegan el evento del navegador y el del servidor y que comparten nombre e identificador. Repite recargando la página de confirmación y con un formulario que falle. Documenta el resultado: dentro de dos lanzamientos nadie recordará qué se probó.

¿Qué errores conviene evitar?

• Añadir la API de conversiones sin retirar nada. Activar la integración de servidor de una plataforma mientras sigue activa tu etiqueta de servidor en GTM crea un emisor más, no un respaldo.
• Tratar la deduplicación como algo de Meta. Meta deduplica lo que le mandas bien etiquetado. Decidir el identificador y quién lo envía es trabajo tuyo.
• Reprocesar eventos antiguos sin pensar en las 48 horas. Un reenvío masivo tras un fallo puede inflar resultados.
• Mezclar pruebas y producción. Los eventos de prueba que se cuelan en el conjunto de datos real ensucian el aprendizaje de las campañas.
• Esperar que Meta, GA4 y el CRM coincidan. La API de conversiones reduce pérdidas y, bien deduplicada, evita dobles conteos, pero no iguala las cifras. Cada herramienta atribuye con sus reglas; lo explico con un recorrido completo en por qué GA4, Meta y tu CRM nunca dan la misma cifra.
• Descubrirlo en pleno lanzamiento. Si vendes por lanzamientos, la medición se valida antes de abrir registros, como cualquier otra pieza del checklist técnico de un lanzamiento.

Checklist: píxel y API de conversiones sin duplicados

• Existe una tabla con cada evento, su emisor en navegador, su emisor en servidor y su event_id.
• Ningún evento tiene más de un emisor por lado.
• El nombre del evento es idéntico en píxel y servidor.
• El event_id sale de un identificador de negocio (pedido, registro, lead) y es el mismo en ambos lados.
• Lead y Purchase se disparan en la confirmación, no en el clic.
• Recargar la página de confirmación no genera un evento nuevo.
• Los eventos de servidor se envían dentro de las 48 horas siguientes al del navegador.
• Las conversiones cualificadas del CRM se envían con el identificador del lead.
• Hay una prueba documentada con compra real, recarga y formulario con error.
• Está claro qué herramienta es la fuente de verdad de leads y ventas, y no es Meta.

¿Cuándo conviene delegarlo?

Si tienes un solo checkout, un formulario y una integración nativa bien configurada, puedes resolverlo con esta guía y una tarde de pruebas. Cambia cuando la operación tiene varias plataformas enviando eventos, venta por llamada, pagos pendientes, lanzamientos con picos o campañas donde un dato inflado decide dónde va el presupuesto.

Ahí el problema ya no es de una etiqueta: es de arquitectura de datos. Qué sistema genera cada identificador, cómo viaja hasta el CRM y qué conversiones vuelven a Meta. Es exactamente el trabajo del servicio de tracking server-side y API de conversiones, que conecta eventos, atribución y dashboards con una fuente de datos fiable. Encaja dentro de la visión de conjunto que describo en la guía de sistemas para negocios digitales.

Si tus cifras de Meta no se parecen a lo que factura el negocio, cuéntame qué proceso os está frenando y revisamos por dónde se duplican o se pierden los eventos.