Solución de problemasMeta

Meta CAPI no deduplica: arregla los eventos duplicados

¿Meta Pixel y CAPI informan dos veces la misma compra? Diagnostica desajustes de event_id y doble disparo, y verifica la deduplicación en Events Manager.

Publicado: 23 de julio de 2026
Revisado: 17 de septiembre de 2026

Diagnóstico

Plataforma Meta
Causa habitual Los eventos del navegador y del servidor no comparten el mismo event_name y event_id.
Causas, por orden 4
Cómo diagnosticarlo 7

Ir a las comprobaciones

Primera respuesta gratis, en un día laborable. Describe tu caso

¿Te suena?

El síntoma

Parte del síntoma Meta

Una campaña que no debería funcionar está mostrando un ROAS excelente. O Events Manager de Meta informa de más compras en una semana de las que tuvo la tienda.

Ambas cosas suelen remontarse a la misma causa raíz: la misma compra real contada dos veces —una desde el Pixel del navegador y otra desde CAPI en el servidor— porque nunca se le dio a Meta una forma de reconocer que son el mismo evento.

Dos rutas de envío que llevan la misma clave, resueltas en un único evento deduplicado

Marca lo que ves

El ROAS informado parece mejor de lo que el volumen de pedidos puede explicar
El recuento de Purchase de Meta es superior al recuento de pedidos de Shopify para el mismo periodo
Events Manager muestra dos eventos Purchase por pedido procedentes de fuentes distintas
La métrica de deduplicación en la vista general de Events Manager se mantiene cerca de cero
Los recuentos duplicados empezaron tras instalar una nueva app de tracking o una integración CAPI

Marca las líneas que coinciden con tu tienda.

Describir mi caso

La versión corta

Respuesta directa

Meta deduplica un evento de Pixel y un evento de CAPI solo cuando ambos llevan el mismo event_name y event_id exactos para la misma acción.

Si cualquiera de los dos valores difiere —o si dos sistemas independientes, como el canal nativo de Meta e Instagram de Shopify y una configuración de GTM configurada aparte, envían ambos Purchase para el mismo pedido sin compartir un esquema de event_id—, Meta no tiene forma de saber que son duplicados y cuenta los dos. La herramienta Test Events de Events Manager lo muestra directamente: una compra correctamente deduplicada aparece una vez, marcada como fusionada a partir de dos fuentes, no como dos filas separadas.

Dónde mirar

Causas, por orden

Píxel y CAPI cuentan doble4 causas

Sin event_id compartido

La llamada del Pixel del navegador y la llamada CAPI del servidor generan su event_id de forma independiente en lugar de usar un único valor compartido (normalmente el token de pedido o de checkout de Shopify), así que Meta no tiene nada con lo que emparejarlos.
Dos sistemas independientes lanzándose en paralelo

El canal de ventas nativo de Facebook e Instagram de Shopify y una configuración de Meta Pixel/CAPI basada en GTM aparte, instrumentados a la vez, cada uno con su propia lógica de event_id que no sabe nada del otro. Esta es la causa individual más común de un recuento de compras de aproximadamente el doble.
Desajuste de event_name

La deduplicación se basa en event_name más event_id conjuntamente. Si el servidor envía Purchase pero el evento del navegador está etiquetado de forma distinta, Meta ni siquiera intenta emparejarlos: los trata correctamente como eventos diferentes, lo cual es una característica de diseño, no un error, pero produce el mismo recuento inflado.
Entrega tardía de CAPI

Si los eventos del servidor se agrupan y se envían mucho después del evento del navegador, pueden llegar fuera de la ventana que Meta usa para emparejar eventos y contarse por separado incluso con un event_id correcto.

7 pasos

Cómo diagnosticarlo

Hazlos en este orden.

En Meta Events Manager → Data Sources, selecciona tu Pixel/dataset y abre la pestaña Overview. Comprueba la cifra de deduplicación para el evento Purchase.
Abre Events Manager → Test Events, lanza una compra real o de prueba y observa cómo aparecen tanto el evento Purchase del navegador como el del servidor. Una configuración que funciona muestra un único evento fusionado y marcado, no dos filas sin fusionar.
En la página de agradecimiento, abre la pestaña Network del navegador, encuentra la llamada saliente del Pixel (solicitud fbevents.js) y anota el parámetro event_id que envió.
En el lado del servidor, revisa lo que envíe CAPI para ese mismo pedido —Settings → Customer events de Shopify (si usas el canal nativo) o la etiqueta Meta CAPI de tu contenedor de servidor de GTM— y confirma que el event_id que envía para el mismo pedido coincide exactamente con el valor del navegador.
En Shopify Admin → Settings → Apps and sales channels, comprueba si el canal Facebook e Instagram está instalado a la vez que una implementación de Meta en GTM aparte. Ejecutar ambos es la causa individual más común de un recuento duplicado.
Confirma la paridad de event_name: ambas partes deben enviar exactamente Purchase, con las mismas mayúsculas y la misma ortografía, para que la clave de deduplicación se aplique.
Compara las marcas temporales entre el evento del navegador y el evento CAPI para el mismo pedido en Test Events: una brecha grande sugiere un retraso de agrupación que empuja el evento del servidor fuera de la ventana de emparejamiento.

Señal y solución

Tabla de decisión

Causa	Señal que verás	Solución
Sin event_id compartido	Test Events muestra dos filas Purchase separadas para el mismo pedido, sin indicador de deduplicación	Genera un event_id por pedido (p. ej., el token de checkout) y pasa el mismo valor idéntico tanto a la llamada del Pixel como a la llamada CAPI
Canal nativo + GTM lanzándose ambos	El recuento de Purchase es aproximadamente el doble del recuento real de pedidos; están instalados tanto un canal nativo de Meta como una configuración de GTM aparte	Elige un sistema como fuente de verdad para los eventos Purchase y desactívalo en el otro
Desajuste de event_name	El ratio de deduplicación se mantiene cerca de cero aunque ambas partes se lanzan claramente	Alinea el event_name exactamente (`Purchase`) y las mayúsculas de los parámetros en las llamadas del navegador y del servidor
Entrega tardía de CAPI	El evento del navegador se lanza de inmediato; el evento CAPI correspondiente aparece en Test Events mucho más tarde	Envía los eventos CAPI de forma síncrona en la creación del pedido en lugar de en un lote con retraso

Una nota de Daniilantes de decidir

¿Deberías arreglarlo tú mismo o pedir ayuda?

Revisar la vista general y Test Events de Events Manager, y confirmar si están instalados tanto un canal nativo como una configuración de GTM aparte, es algo que la mayoría de los comerciantes puede hacer directamente en los paneles de administración, sin necesidad de código.

Donde se necesita un desarrollador es en generar y canalizar un event_id coherente tanto por el código del tema/píxel como por lo que envíe CAPI, o en decidir cuál de los dos sistemas superpuestos mantener y migrar limpiamente fuera del otro.

Si los duplicados persisten tras confirmar que solo hay un sistema activo y que los nombres de evento coinciden, la propia lógica de generación del event_id necesita un replanteamiento: eso es un trabajo de Meta Conversions API, no un cambio de configuración.

— Daniil

Siguiente paso

Si la comprobación no lo resuelve.

Las comprobaciones anteriores encuentran la causa en la mayoría de las tiendas. Cuando se solapan dos o más, una conciliación a nivel de pedido es más rápida que otra tarde comparando paneles.

Tracking Health Check

Precio: EUR 375
Acceso: Solo lectura
Plazo: veredicto dos días laborables después del kickoff

Lo que muestra la conciliación para este síntoma.

Un Health Check concilia este síntoma pedido por pedido contra tus pedidos de Shopify, así que la causa es un hecho de tus propios datos, no una suposición desde un panel. Todavía no hay cifras reales publicadas para este síntoma — pide el informe de muestra.

Solicitar un Health Check · EUR 375

Sigue el pedido. Después compara las pruebas.

Pedido realID del pedido, importe, moneda
Eventos del navegador / servidorConsentimiento, ID del evento, entrega
GA4 / plataformas publicitariasEventos recibidos e informes
Conciliar los registrosComparar IDs, períodos y definiciones

Un pedido completado y una conversión registrada son registros distintos. Revisa el recorrido y compara criterios equivalentes antes de interpretar una diferencia como datos perdidos.

Preguntas

Preguntas que plantea este síntoma

¿Qué es exactamente un event_id?

Es un identificador único que generas una vez por acción —uno por pedido, no por envío de evento— y que adjuntas tanto a la llamada del Pixel del navegador como a la llamada CAPI del servidor para esa misma acción. Meta usa el par de event_name y event_id para reconocer que dos eventos describen la misma acción del mundo real y deben fusionarse en uno, no en dos.

¿Puedo ejecutar Pixel y CAPI sin deduplicación?

Puedes, pero no deberías. Sin un event_id compartido, cada acción que el navegador puede ver y que el servidor también informa se cuenta dos veces, inflando tu recuento de conversiones y tu ROAS de una forma que parece buena hasta que escalas el gasto contra cifras que no son reales.

¿Cómo sé si la deduplicación funciona de verdad, y no que simplemente no hay duplicados?

Revisa la herramienta Test Events de Events Manager durante una compra real o de prueba. Si el Pixel y CAPI se lanzan ambos y funcionan correctamente, verás los dos eventos listados con un indicador de deduplicación que muestra que se emparejaron en un único evento computado, no solo la ausencia de una segunda fila.

¿El canal nativo de Meta de Shopify ya gestiona la deduplicación por mí?

La gestiona correctamente dentro de sí mismo: las llamadas propias de Pixel y CAPI del canal nativo comparten un event_id por defecto. El fallo se produce al ejecutar el canal nativo junto a una configuración de Meta basada en GTM aparte, lo que introduce un segundo esquema de event_id independiente que Meta no tiene forma de reconciliar con el primero.