Para medir las conversiones de Meta con precisión, envías el mismo evento tanto desde el Pixel (navegador) como desde la Conversions API (CAPI / servidor) — esta es la configuración que el propio Meta recomienda. Si un lado falla por consentimiento o restricciones del navegador, el otro todavía puede capturar el evento, lo que te da redundancia. Pero cuando este "enviar por ambos lados" funciona sin deduplicación, una sola conversión se cuenta dos veces. Un diseño pensado para la redundancia se convierte directamente en números inflados.
¿Te suena familiar alguno de estos síntomas?
- Desde que agregaste tanto el Pixel como CAPI, las conversiones son más altas de lo real
- En Events Manager, la misma compra aparece como dos eventos — uno de navegador, uno de servidor
- El ingreso total (
value) está inflado por encima de las ventas reales - Configuraste la deduplicación, pero los duplicados no han desaparecido
Esta guía organiza por qué la deduplicación de Meta es necesaria, su condición (event_id más nombre de evento), y cómo verificar que realmente está funcionando tanto del lado del navegador como del servidor — desde una perspectiva práctica y aplicada.
Principio básico: "enviar por ambos lados" y "doble conteo" están a un pelo de distancia
Empecemos por la premisa. Meta recomienda ejecutar el Pixel y la Conversions API juntos para reducir los eventos perdidos. El lado del navegador se pierde fácilmente por la protección de rastreo y los bloqueadores de anuncios; el lado del servidor es en gran medida inmune a eso. Así que envías el mismo evento desde ambos lados, bajo la premisa de que Meta va a fusionar el duplicado en un solo evento (deduplicación).
| Estado | Qué sucede |
|---|---|
| Enviar solo desde un lado | Es probable que haya eventos perdidos (sin redundancia) |
| Enviar por ambos lados + deduplicación activada | Se cuenta correctamente como un solo evento (recomendado) |
| Enviar por ambos lados + deduplicación desactivada | El mismo evento único se infla a dos |
Así que el problema no es "enviar por ambos lados" — es si la deduplicación funciona una vez que ya enviaste por ambos lados. Lo que necesitas verificar no es "si se envió" sino "si Meta lo fusionó en uno".
La condición de deduplicación: mismo event_id + mismo nombre de evento
La condición para que Meta trate un evento del lado del navegador y uno del lado del servidor como "el mismo" es simple.
event_idcoincidente … para una sola conversión, pasa el mismo valor exacto desde el navegador y el servidorevent_namecoincidente … usa el mismo nombre de evento en ambos lados, comoPurchaseoLead
Solo cuando estos dos coinciden, Meta decide "esta es la misma ocurrencia que llega desde el navegador y el servidor" y la fusiona en una sola. El fbp (ID de navegador, el valor de la cookie _fbp) también se usa como señal de apoyo, pero el eje central siempre es la coincidencia de event_id más nombre de evento.
Error común: hacer coincidir el nombre del evento pero adjuntar
event_idsolo a un lado. Entonces se trata como "mismo nombre pero ocurrencia diferente", y sobreviven dos eventos sin deduplicarse. Por el contrario, incluso si alineas elevent_id, un desajuste en el nombre del evento comoPurchasevs.purchasetambién hace que se cuenten como cosas separadas (guía de tracking de conversiones de Meta).
La ventana de deduplicación de 48 horas
Meta no mantiene los eventos indefinidamente para hacer coincidencias. Cuando un evento del lado del navegador y uno del lado del servidor comparten el mismo event_id y nombre de evento, Meta los fusionará solo si ambos llegan dentro de 48 horas uno del otro. Después de que se cierra esa ventana, incluso una coincidencia perfecta de event_id se ignora — los dos eventos se cuentan por separado.
En la práctica esto rara vez causa problemas, porque el Pixel se dispara al instante y CAPI típicamente lo sigue en segundos o minutos. Pero si tu pipeline del lado del servidor tiene un retraso largo — jobs por lotes que se ejecutan durante la noche, colas que se acumulan los fines de semana, o lógica de reintentos que retiene eventos fallidos — el evento de CAPI puede llegar fuera de la ventana de 48 horas y la deduplicación deja de funcionar silenciosamente.
Consejo: si procesas conversiones por lotes, mantén el retraso muy por debajo de las 48 horas. El envío en tiempo real o casi en tiempo real desde el servidor es el enfoque más seguro.
Cómo verificar: ¿coinciden el event_id del lado del navegador y del lado del servidor?
Verificar que la deduplicación funciona se reduce a comparar el event_id en ambos lados y confirmar que es el mismo valor. Paso a paso.
1. Lee el event_id del lado del navegador
Abre la pestaña "Network" de las DevTools de tu navegador y filtra por facebook.com/tr. Realiza la acción de conversión objetivo una vez, y revisa el parámetro eid (= event_id) en la solicitud que se dispara. El eventID de fbq('track', 'Purchase', {...}, {eventID: '...'}) viaja aquí.
2. Lee el event_id del lado del servidor
Del lado de CAPI, confirma que el payload que tu servidor envía a Meta (data[].event_id) contiene el mismo valor. Usando tus logs de implementación o el código de eventos de prueba, compáralo contra el valor exacto que confirmaste en el navegador.
3. Concilia en "Eventos de prueba" de Events Manager
Abre Events Manager → tu dataset → Eventos de prueba, y genera una conversión en el sitio. Deberían llegar dos eventos — uno del navegador, uno del servidor. Si Meta los fusiona en uno como "deduplicado", lo indicará. Si los dos permanecen listados por separado, la deduplicación no está funcionando.
Error común: Eventos de prueba solo muestra "este momento, en tu entorno". Aunque coincida en tu máquina, si el punto donde generas dinámicamente el
event_iden producción se desincroniza, los duplicados aparecen solo en los recorridos de visitantes reales. No te confíes con un solo patrón en tu propia máquina.
Leer las tasas de deduplicación en Events Manager
Eventos de prueba te muestra una instantánea única, pero Events Manager también ofrece métricas de deduplicación agregadas para el monitoreo continuo. Para encontrarlas:
- Abre Events Manager y selecciona tu dataset (pixel).
- Haz clic en un nombre de evento específico — por ejemplo, Purchase.
- En la vista de detalle, compara el conteo de Recibidos (total de eventos sin procesar de todas las fuentes) contra el conteo de Deduplicados (eventos reconocidos como duplicados y fusionados).
La diferencia entre estos dos números es la deduplicación que realmente ocurrió. Una configuración de doble fuente saludable (Pixel + CAPI ambos disparando de forma confiable) típicamente muestra una tasa de deduplicación de aproximadamente 40--70 % para un evento dado. Lo que te dicen los números:
| Tasa de dedup | Significado probable |
|---|---|
| 40--70 % | Saludable — ambas fuentes están disparando y Meta las está fusionando |
| Cerca de 0 % | El event_id no se está pasando o no está coincidiendo |
| Cerca de 100 % | Inusual — posiblemente una fuente no está llegando a Meta en absoluto |
Nota: las tasas de deduplicación en la pestaña de Overview no son en tiempo real. Espera al menos 48--72 horas de tráfico real antes de sacar conclusiones, especialmente justo después del despliegue.
Razones comunes por las que la deduplicación no funciona
Agregaste event_id pero los duplicados no desaparecen — aquí están los patrones típicos.
1. El event_id difiere entre los dos lados
La causa más común. Si el navegador y el servidor generan el event_id de forma independiente, los valores no coincidirán y se tratan como cosas diferentes. El event_id necesita un mecanismo que siempre produzca el mismo valor en ambos lados — pasa el valor generado del lado del navegador al servidor, o deriva el mismo valor de una lógica compartida.
2. El event_id existe solo en un lado
Pasas eventID al Pixel pero no incluyes event_id en CAPI (o viceversa). Sin nada en un lado no hay nada que conciliar, y la deduplicación nunca sucede.
3. El nombre del evento no coincide
Purchase vs. purchase, o mezclar un evento estándar con un evento personalizado — un desajuste en el nombre del evento también desactiva la deduplicación. Usa exactamente el mismo nombre en ambos lados.
4. fbp / fbc no se están pasando
Si fbp (ID de navegador) o fbc (click ID), usados para la conciliación de apoyo, no se pasan al lado del servidor, eso afecta la precisión de conciliación y la calidad de coincidencia. La coincidencia de event_id es el eje principal, pero pasar estos también es la configuración preferible.
Pasar el event_id a través de GTM Server-Side
Si usas Google Tag Manager (GTM) Server-Side para tu implementación de CAPI, el flujo para mantener el event_id consistente en ambos lados típicamente se ve así:
- Genera el
event_iden el cliente. En el JavaScript de tu sitio web (o una etiqueta GTM del lado del cliente), crea un ID único (un UUID o ID de pedido) para cada conversión. - Pásalo al Pixel. Incluye el ID como
eventIDen tu llamadafbq('track', ...). - Reenvíalo al contenedor del servidor. Envía el mismo ID como parámetro en tu evento de GA4 (o a través de una variable de data layer personalizada) para que llegue al contenedor GTM del lado del servidor.
- Mapéalo en la etiqueta de Meta CAPI. En la configuración de tu etiqueta de Meta del lado del servidor, mapea el parámetro entrante al campo
event_id.
El punto crítico: el cliente y el servidor deben usar una única fuente de verdad para el ID. Si el contenedor del servidor genera su propio ID en lugar de leer el que envió el cliente, los valores divergen y la deduplicación se rompe. Para una mirada más amplia sobre cómo verificar tu configuración de GTM del lado del servidor, consulta verificación de GTM server-side.
Lo que la verificación en tu propia máquina no puede decirte
Verificar una vez, manualmente, en tu propia máquina tiene dos límites estructurales.
- Tu entorno no es el entorno de tus visitantes. Dependiendo del estado de sesión, las extensiones y el estado de consentimiento, el
event_idpuede parecer alineado en tu máquina pero la deduplicación puede romperse bajo condiciones reales de visitantes (solo el lado del navegador se cae cuando se rechaza el consentimiento, el momento de generación delevent_idse desfasa en una fuente de tráfico particular, etc.). - Las conversiones que involucran un clic en anuncio son difíciles de verificar. Para recrear correctamente "¿realmente se fusiona en uno a través de un anuncio?", necesitarías hacer clic en un anuncio real y seguir el recorrido — lo cual conlleva el riesgo de una infracción de política publicitaria por autoclic.
En otras palabras, confirmar que "el event_id coincide" en tu propia acción no es prueba de que la deduplicación funcione en el recorrido real que hacen tus visitantes.
Lista de verificación
- ¿El Pixel y CAPI pasan el mismo
event_idpara la misma conversión? - ¿El nombre del evento (
event_name) coincide exactamente en ambos lados (incluyendo mayúsculas/minúsculas)? - ¿Realmente conciliaste el
eiddel lado del navegador contra elevent_iddel lado del servidor? - ¿Confirmaste el estado "deduplicado" en Eventos de prueba?
- ¿Es el
event_idúnico por conversión e idéntico en ambos lados? - ¿Se pasan
fbp/fbctambién al lado del servidor? - Más allá de un solo patrón en tu máquina, ¿está libre de duplicados bajo condiciones reales de visitantes en producción?
Preguntas frecuentes
P. ¿Debería instalar tanto el Pixel como CAPI desde el principio?
R. Sí — es la recomendación de Meta. Si un lado falla por consentimiento o restricciones del navegador, el otro todavía puede capturar el evento, dándote redundancia. Pero eso se sostiene solo bajo la premisa de que la deduplicación (event_id + nombre de evento) está funcionando. Si no lo está, enviar por ambos lados se convierte directamente en doble conteo (los fundamentos del doble conteo).
P. ¿Qué valor debería tener el event_id?
R. Cualquier valor que identifique de forma única una sola conversión (un ID de pedido, por ejemplo) funciona, siempre y cuando uses el mismo tanto en el navegador como en el servidor. Las dos cosas que importan: "único por conversión" e "idéntico en ambos lados". No funcionará si se asigna un valor diferente cada vez, o si un lado está vacío.
P. Hice coincidir el nombre del evento pero los duplicados no desaparecen.
R. Lo más probable es que el event_id no coincida en ambos lados. Revisa si el valor generado del lado del navegador realmente se pasa al servidor, y si la generación independiente ha causado que los valores diverjan (verificando CAPI).
P. Si Eventos de prueba dice deduplicado, ¿producción también está bien?
R. Eventos de prueba es una verificación de tu entorno, en ese momento. En producción, la asignación y coincidencia del event_id puede romperse dependiendo del estado de consentimiento y la fuente de tráfico, y un solo patrón en tu máquina puede no reproducirlo. Se necesita verificación bajo condiciones reales de visitantes.
P. También quiero saber cómo verificar el Pixel en sí. R. Verificar la instalación, el disparo y la recepción del Pixel por sí solo se cubre en un artículo separado (verificando el Meta Pixel). La deduplicación en este artículo es la siguiente etapa — hacer que el Pixel y CAPI coexistan.
Conclusión: "enviar por ambos lados" no está terminado hasta que "se fusiona en uno"
Instalar tanto el Pixel como CAPI es la recomendación de Meta y un diseño sólido para reducir los eventos perdidos. Pero eso descansa sobre la premisa de que Meta los fusiona en uno (deduplicación) mediante el mismo event_id más el mismo nombre de evento. Si la deduplicación no funciona, un diseño pensado para la redundancia se convierte en la causa del doble conteo. Empieza conciliando el event_id en ambos lados, y confirma "deduplicado" en Eventos de prueba.
Aun así, una sola verificación en tu propia máquina no puede detectar la deduplicación que se rompe solo en los recorridos de visitantes reales. ConversionOK ejecuta tu página en vivo en un navegador independiente y aislado e intercepta los eventos de Pixel y CAPI realmente enviados (y si sus event_id coinciden), para luego verificarlos — sin necesidad de hacer clic en tu propio anuncio y sin interferencia de tu entorno de oficina. Empieza con una verificación estática gratuita para confirmar el punto de entrada de tu medición.