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

> Por qué Meta cuenta leads y compras dos veces al usar píxel y API de conversiones, cómo funciona la deduplicación con event_id y qué revisar paso a paso.

- URL: https://fcgsystems.es/blog/pixel-meta-api-conversiones-duplicados/
- Autor: Gabriel Florencio Calvo, Fundador de FCG Systems (https://fcgsystems.es/blog/autor/gabriel-florencio/)
- Publicado: 2026-09-15 (15 de septiembre de 2026)
- Tema: Sistemas · Formato: Breakdown · Lectura: 8 min
- Palabra clave: pixel de meta y api de conversiones (también: api de conversiones meta, eventos duplicados meta, deduplicación event_id, api de conversiones o pixel de meta)

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:

| | Píxel de Meta | API de conversiones |
|---|---|---|
| Desde dónde envía | Navegador del usuario | Un servidor: tu plataforma de pago, CRM, backend o automatización |
| Qué lo bloquea | Bloqueadores, restricciones del navegador, consentimiento rechazado | Nada del lado del navegador; depende de que tu servidor envíe bien |
| Qué ve bien | La navegación y la interacción en la página | Hechos confirmados: pago aprobado, registro guardado, lead cualificado |
| Riesgo típico | Perder eventos | Duplicar eventos si no se deduplica |

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](https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events), 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:

| Síntoma | Causa probable | Cómo comprobarlo |
|---|---|---|
| Cada compra aparece dos veces | Píxel y API envían `Purchase` con `event_id` distinto o sin él | Compara el identificador en los dos eventos de una compra de prueba |
| Compras triplicadas | Plugin del CMS + etiqueta de GTM + integración de la plataforma de pago enviando lo mismo | Inventario de fuentes (paso 1 de abajo) |
| Leads que no existen en el CRM | El evento `Lead` se dispara al pulsar el botón, no al confirmar el registro | Envía un formulario con error y mira si el evento se dispara igual |
| Duplicados solo en algunos casos | Recargas de la página de gracias o reintentos del servidor que reenvían sin mismo `event_id` | Recarga la página de gracias en una prueba |
| Meta deduplica unas veces sí y otras no | El evento de servidor llega más de 48 horas después | Revisa cuándo se envía el evento de servidor, sobre todo en pagos pendientes |

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:

| Evento | Se envía desde el navegador por | Se envía desde el servidor por | Momento en que se dispara | event_id | Quién genera el event_id |
|---|---|---|---|---|---|
| Lead | | | | | |
| CompleteRegistration | | | | | |
| InitiateCheckout | | | | | |
| Purchase | | | | | |

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](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/): 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](https://fcgsystems.es/blog/atribucion-rota-ga4-crm/).
- **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](https://fcgsystems.es/blog/checklist-tecnico-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](https://fcgsystems.es/servicios/datos-tracking-analitica/), 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](https://fcgsystems.es/blog/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](https://fcgsystems.es/contacto/) y revisamos por dónde se duplican o se pierden los eventos.

## Preguntas frecuentes

### ¿Uso el píxel de Meta o la API de conversiones?

Los dos. Meta recomienda una configuración redundante: el píxel envía el evento desde el navegador y la API de conversiones lo envía desde un servidor. Así, si el navegador bloquea el píxel, el evento del servidor sigue llegando. La condición es que ambos compartan nombre de evento e identificador para que Meta los cuente una sola vez.

### ¿Por qué Meta me cuenta las compras o los leads duplicados?

Casi siempre porque el mismo evento llega por dos vías sin un identificador común, o porque dos integraciones distintas envían el mismo evento: un plugin, una etiqueta de Google Tag Manager y la propia plataforma de pago. Meta solo deduplica cuando el nombre del evento y el event_id coinciden en el navegador y en el servidor.

### ¿Qué es el event_id?

Es el identificador único de una conversión concreta. En el píxel se envía como eventID y en la API de conversiones como event_id. Si una compra genera el mismo valor en los dos lados, por ejemplo el identificador del pedido, Meta entiende que es un solo evento recibido dos veces y descarta el duplicado.

### ¿La API de conversiones hace que Meta, GA4 y el CRM den la misma cifra?

No. Reduce los eventos que se pierden y, bien deduplicada, evita contar dos veces, pero Meta, GA4 y el CRM siguen midiendo con reglas distintas: ventanas de atribución, visualizaciones, consentimiento y cambios de dispositivo. La cifra de negocio debe salir de tu fuente de verdad, normalmente el CRM o la pasarela de pago.

### ¿Necesito tracking server-side para usar la API de conversiones?

Necesitas que algo envíe eventos desde un servidor, pero no siempre un contenedor server-side propio. Puede hacerlo tu plataforma de pago si tiene la integración, tu CRM o una automatización. Un tracking server-side completo compensa cuando hay volumen, varias plataformas y necesidad de controlar qué datos salen y cuándo.

## Servicios relacionados

- [Datos, tracking y analítica](https://fcgsystems.es/servicios/datos-tracking-analitica/): Qué canal vende, no solo cuál registra: tracking, atribución hasta el CRM y cifras que coinciden.
- [Arquitectura de sistemas](https://fcgsystems.es/servicios/arquitectura-de-sistemas/): Auditoría de tus herramientas, datos y procesos, y un plan claro de qué construir primero.

## Contacto

Escribe a hola@fcgsystems.es o usa el formulario de https://fcgsystems.es/contacto/. Respuesta en un día laborable.