El síntoma: el Administrador de eventos muestra Purchases o Leads que tu sistema de pedidos o tu CRM no pueden relacionar con nada. Un anunciante reportó 105 compras en un día desde un anuncio de tráfico frente a cero pedidos en la tienda (hilo de la comunidad de una plataforma de tiendas, iniciado el 25 dic 2023, reportado por anunciantes). Esa diferencia apunta a eventos que nunca ocurrieron o a errores de seguimiento. Una acción fraudulenta real no deja ninguna diferencia, porque el pedido o el lead existe; sale a la luz más tarde como una devolución de cargo o como un lead al que nadie consigue contactar. Para saber cómo llegan los bots y el tráfico inválido a los anuncios de Meta, empieza por nuestra guía sobre el fraude de clics en Meta Ads.
Cómo lo comprobamos. No se hizo ninguna prueba en una cuenta publicitaria. El comportamiento de Meta procede de páginas de Meta for Developers leídas el 12 de noviembre de 2026, y los patrones de los anunciantes proceden de hilos de la comunidad con fecha.
¿Cómo se crean los eventos falsos del Pixel de Meta?
Los eventos sospechosos tienen tres causas: eventos que nunca ocurrieron (un script o un navegador headless que dispara el Pixel), acciones fraudulentas reales que producen eventos reales (como pedidos de prueba de tarjeta) y errores de seguimiento (instalaciones duplicadas, reglas de configuración mal definidas, un test_event_code olvidado). Una pregunta ordena la mayoría: ¿hay un registro en tu sistema de pedidos o en tu CRM? Sin registro y con el evento reproduciéndose en tu propia página, es un error; sin registro y sin reproducción, nunca ocurrió; y con un registro fraudulento, es fraude real.
La documentación más reciente de Meta llama conjunto de datos al almacén de tus eventos: el Pixel de Meta le envía eventos del navegador, la Conversions API de Meta le envía eventos del servidor y el Administrador de eventos muestra ambos. El Pixel es un script público cuyo ID está en el código fuente de tu página. Meta define Purchase como “cuando se realiza una compra o se completa el proceso de pago” y marca currency y value como obligatorios (referencia del Pixel de Meta). Nada en esa llamada demuestra que se haya producido una compra.
Eventos que nunca ocurrieron. Cualquier script que pueda ejecutar el Pixel puede llamar a fbq('track', 'Purchase') con cualquier valor. Un navegador headless hace lo mismo de forma menos visible, activando los eventos que activaría una persona.
Acciones fraudulentas reales. Un bot de prueba de tarjetas que completa el pago con una tarjeta robada crea un pedido real, así que el Purchase es un evento real. En mayo de este año, un comerciante reportó bots que pedían cientos de unidades del mismo producto, lo que afectó a su Pixel (hilo de la comunidad de una plataforma de tiendas, iniciado el 16 may 2026, reportado por anunciantes). Nuestra página sobre la protección contra el fraude de clics en e-commerce cubre el lado de la tienda.
Errores de seguimiento. Los más comunes son las instalaciones duplicadas del Pixel, una página de agradecimiento que se dispara de nuevo al recargar, un test_event_code olvidado en producción, claves de deduplicación rotas y reglas de configuración que disparan Purchase en la página equivocada. Una respuesta de octubre de 2026 en el hilo de las 105 compras citado al principio sugería revisar si hay una regla de la Event Setup Tool (herramienta de configuración de eventos) que convierta las visitas de página en eventos Purchase (reportado por anunciantes).
Errores del lado de Meta. Un comerciante reportó compras de valor cero que inflaban los recuentos y escribió el 20 de febrero de 2025 que Meta había corregido un error de su lado, provocado por un cambio de código entre el 8 y el 11 de febrero y ya revertido (hilo de la comunidad de una plataforma de tiendas, iniciado el 10 feb 2025, reportado por anunciantes).
¿Por qué Meta optimiza para eventos falsos?
Nuestra lectura: la entrega de Meta aprende de las conversiones que reportas, así que un Purchase o un Lead falso le enseña a buscar más visitas como la falsa.
La optimización por valor añade una segunda distorsión: una serie de Purchases de $0 o de valores redondos sesga el valor que el sistema cree que aporta un comprador, de nuevo según nuestra lectura.
¿Dónde aparecen los eventos falsos en el Administrador de eventos?
El Administrador de eventos muestra volúmenes, métodos de conexión y tasas de deduplicación, y las comprobaciones de datos documentadas por Meta señalan datos mal formados, no los eventos falsos del Pixel de Meta. Úsalo para localizar una diferencia y confirma la causa en otro sitio.
- Overview (Resumen). Meta dice que Overview muestra “el número de eventos que recibimos antes de que se deduplicen” y que “en Connection Method, ves el canal por el que se envió ese evento” (Verifying Your Setup, Meta for Developers). Compara su recuento diario de Purchase con los pedidos pagados.
- Event Details (Detalles del evento). Se abre desde Overview, y su pestaña Event Deduplication muestra el “porcentaje de eventos que se han deduplicado de cada fuente de eventos” y con qué frecuencia se usa cada clave de deduplicación (misma página).
- Dataset Quality API. La Dataset Quality API de Meta comprueba si hay eventos cuyo “parámetro de valor o de moneda falta o no es válido”, direcciones IP de cliente que “no coinciden con las del Pixel de Meta” y eventos que “comparten el mismo correo de relleno en lugar de uno real” (Dataset Quality API, Meta for Developers). Son comprobaciones de formato; no encontramos ninguna página de Meta que describa una comprobación de bots, spam o fraude, así que un falso bien formado las pasa todas.
- Test Events (Eventos de prueba). El camino de Meta es Administrador de eventos, luego Data Sources, luego tu Pixel, luego Test Events, y los eventos de servidor que envías con el parámetro test_event_code aparecen allí (Using the Conversions API).
- Event Match Quality (EMQ). EMQ muestra lo bien que la información del cliente de un evento puede coincidir con una cuenta de Meta (Conversions API best practices), no si el evento es fraudulento. Meta dice que “se puntúa de 1 a 10” y recomienda que “apuntes a una puntuación de Event Match Quality de 6,0 o superior” (Verifying Your Setup).
Nuestra lectura, no la de Meta: si el EMQ de los eventos Lead baja mientras el volumen de leads sube, revisa los leads, porque unos datos de contacto inventados no pueden coincidir con cuentas reales. Un formulario que dejó de pasar un campo también baja el EMQ.
¿Es un evento falso o un error de seguimiento?
La mayoría de los patrones tienen una explicación inocente y otra hostil, y una comprobación suele bastar para saber cuál tienes.
| Patrón | Suele ser un error cuando | Nunca ocurrió o es fraude real cuando | Comprobación que lo resuelve |
|---|---|---|---|
| Purchase sin ID de pedido | Tu configuración nunca pasa un ID de pedido | Nunca ocurrió: los Purchases reales llevan uno | Haz coincidir la marca de tiempo de cada evento con un pedido |
| Purchase disparado en la URL de una página de producto | Se dispara cada vez que recargas la página | Nunca ocurrió: no se reproduce y ningún pedido coincide | Recarga la página con el panel de red abierto |
| Valor redondo o cero | Una regla envía un valor fijo o vacío | Nunca ocurrió: el valor no coincide con ningún producto | Compara los valores con tus precios y pedidos |
| Eventos solo del navegador, sin gemelo del servidor | Tu servidor solo envía algunos eventos | Nunca ocurrió: tu servidor envía cada Purchase real | Compara los métodos de conexión en Overview |
| Eventos de un dominio que no es tuyo | El dominio es una vista previa de la tienda o una sesión de prueba | Nunca ocurrió: el dominio no tiene relación con tu negocio | Revisa los dominios en los ajustes de tu Pixel |
| Muchos Leads idénticos de un mismo visitante en segundos | El formulario se envía dos veces | Fraude real: un bot envió el formulario, así que existen registros en el CRM | Haz coincidir los leads con los registros del CRM y las marcas de tiempo |
| Pico de AddToCart, InitiateCheckout plano | Una regla dispara AddToCart al ver la página | Nunca ocurrió: las visitas automatizadas hacen clic en añadir al carrito | Agrupa el pico por origen, página y hora |
| Los recuentos se duplican exactamente | Se disparan dos instalaciones o las claves de deduplicación difieren | Rara vez una de las dos: la duplicación apunta a la configuración | Lee la pestaña Event Deduplication |
| Pico en una tienda o campaña recién creada | La configuración aún se está probando | Nunca ocurrió: las visitas automatizadas sondean el sitio nuevo | Compara con los pedidos y las fechas de las pruebas |
| El EMQ baja mientras el volumen sube | Un formulario dejó de pasar un campo | Fraude real: los leads nuevos llevan datos de contacto inventados | Revisa los leads nuevos en tu CRM |
| Eventos con un test_event_code en producción | El código nunca se eliminó | Rara vez una de las dos: un código olvidado es un error de configuración | Busca test_event_code en el payload de tu servidor |
Los anunciantes han reportado varios de estos patrones en hilos de la comunidad de plataformas de tiendas:
- Purchases de valor fijo. Un hilo iniciado el 17 oct 2021, titulado a partir de unas compras falsas de 99 dólares, describe eventos Purchase solo del navegador disparados desde la página de producto. Una respuesta posterior decía que el soporte de Meta veía que los eventos se habían configurado mediante una integración de un socio.
- Tiendas nuevas. Un comerciante vio eventos falsos de añadir al carrito, pago y compra dos días después de abrir una tienda (iniciado el 25 nov 2020), y otro vio lo mismo en dos tiendas de menos de 15 días (iniciado el 19 oct 2022).
- Dominios desconocidos. Un comerciante encontró unos 40 en los permisos de tráfico, incluidos subdominios de vista previa de la tienda, y una respuesta sugirió que las sesiones de prueba podían explicar algunos (iniciado el 10 abr 2024).
Qué elimina la deduplicación y qué no puede eliminar
La deduplicación elimina copias de un mismo evento real; no hace nada con un evento falso del navegador que no tiene copia en el servidor. Meta empareja los eventos “según su ID y su nombre”, es decir, el event_id y el nombre del evento, y solo los deduplica “si se reciben dentro de las 48 horas” posteriores al primer evento con ese ID (Deduplicate pixel and server events, Meta for Developers).
Los límites importan más. Meta dice que “no deduplica los eventos cuando solo se usa una fuente de eventos, es decir, solo navegador o solo servidor”, y que dos eventos consecutivos del navegador con la misma información se conservan ambos. Meta también dice que el método de fbp o external_id “por lo general” solo funciona con eventos “enviados primero desde el navegador y después a través del servidor” (misma página). Así que un script que dispara Purchase en el navegador se cuenta cada vez. Para montar la configuración del ID de evento, consulta cómo configurar la deduplicación y las conversiones filtradas de fraude.
Cómo rastrear un Purchase sospechoso
Elige un Purchase que no puedas relacionar con un pedido y síguelo hasta una página, una regla o un script. Este ejemplo es ilustrativo, no una cuenta real.
- Encuentra la diferencia en Overview. Fija el intervalo de fechas en el día de la diferencia y lee el Connection Method del Purchase.
- Reúne el valor y la moneda. Los registros de tu Conversions API los guardan para los eventos de servidor. Un Purchase solo del navegador cuyo valor no coincide con ningún producto es la pista.
- Relaciona la marca de tiempo con un pedido. Si no hay ningún pedido pagado en unos minutos, el evento no tiene ningún cliente detrás.
- Abre el panel de red de las herramientas de desarrollo de tu navegador y recarga la página de producto. Observa qué solicitudes del Pixel se disparan y con qué parámetros.
- Confirma con Meta Ads Data Advisor. Meta dice que la extensión, antes llamada Meta Pixel Helper, muestra “el número de eventos del Pixel disparados en la página web actual” y sus parámetros (Meta for Developers).
- Reprodúcelo en Test Events. Usa un conjunto de datos de prueba y nunca dejes el test_event_code en tu payload de producción. Meta advierte de que los eventos enviados con él “no se descartan” y “entran en el Administrador de eventos y se usan para la segmentación y la medición de anuncios” (Using the Conversions API).
- Revisa los dominios que envían eventos en los permisos de tráfico de tu Pixel. La página de ayuda de Meta sobre esa opción no cargó para nosotros el 12 de noviembre de 2026.
Un Purchase que se dispara cuando recargas la página se dispara para cada visitante. Si lo explica una regla, el código del tema o una integración, tienes un error; si no lo explica nada, busca un script inyectado. Si no se reproduce y ningún pedido coincide, comprueba su dominio y su método de conexión: una llamada hecha a mano o el script de otro dominio nunca aparece en tu panel de red.
Cómo detener los eventos falsos en Meta
Para detener los eventos falsos del Pixel de Meta, restringe los dominios que envían eventos, corrige las claves de deduplicación, elimina el test_event_code y después envía Purchase desde tu servidor con los datos de los pedidos pagados.
- Revisa los permisos de tráfico. Descarta las vistas previas y las sesiones de prueba y después permite solo tus propios dominios si tus pantallas actuales lo ofrecen. Una lista de dominios permitidos no detiene un script que se ejecuta en un dominio tuyo.
- Corrige las claves de deduplicación. Pasa el mismo ID de evento y el mismo nombre de evento desde el navegador y desde el servidor para cada evento real.
- Envía los eventos de conversión desde el servidor con un ID de evento compartido. Tu servidor sabe qué pedidos se pagaron. Esto no elimina los eventos falsos del navegador, que se siguen contando, pero te da un recuento de Purchase confirmado por el servidor con el que compararlos.
- Elimina el test_event_code. Búscalo en los payloads del servidor antes de cada versión.
- Concilia cada semana. Compara los eventos Purchase y Lead con los pedidos pagados y los registros del CRM, tu registro de referencia.
Con el Black Friday el 27 de noviembre, exporta ya los recuentos diarios de Purchase, Lead y AddToCart por método de conexión, para juzgar los picos del día de ofertas frente a una línea base, como plantea nuestra lista de comprobación de temporada para Google Ads y Meta.
Para los leads que son personas reales sin intención, mira cómo distinguir los leads de baja intención de los bots. Si la diferencia empieza antes, en el clic, lee clics en el enlace frente a visitas a la página de destino.
Qué hace ClickFortify y qué no puede detener
ClickFortify marca las conversiones sospechosas tras un clic en un anuncio de Meta y puede filtrar los eventos de servidor enviados a través de su proxy de CAPI; no elimina los eventos que el Pixel de Meta dispara en el navegador.
ClickFortify reconoce los clics en anuncios de Meta por su fbclid y puntúa cada visita con más de 100 puntos de datos de dispositivo, red y comportamiento en el recorrido hacia la página de destino. Marca tres patrones de conversión sospechosa en el registro del clic: una conversión en los 2 segundos siguientes al clic, una conversión de un visitante ya clasificado como bot y un dispositivo con 3 o más conversiones. Cuando el proxy de CAPI está activado, las conversiones enviadas a través de ClickFortify se comprueban con la puntuación de fraude del visitante, y los eventos marcados se descartan o se etiquetan antes de que Meta los reciba. Ese filtro cubre solo los eventos de servidor enviados a través del proxy. Los eventos que el Pixel de Meta dispara en el navegador siguen llegando a Meta, y ClickFortify no puede detener un script o un bot que dispare el Pixel a mano.
ClickFortify no comprueba el correo electrónico ni el teléfono de un lead, así que combínalo con comprobaciones en el CRM. Los leads de formularios instantáneos no son eventos del Pixel y ClickFortify no puede verlos; para ellos, consulta nuestra guía sobre los leads falsos de los anuncios de clientes potenciales de Facebook. No bloquea direcciones IP ni crea exclusiones de audiencia en Meta. Consulta ClickFortify para Meta Ads para ver la configuración.
¿Usas también Google Ads? El lado de las acciones de conversión está en nuestra guía sobre las conversiones falsas en Google Ads.
Nuestro veredicto: concilia los eventos con los pedidos y corrige primero los errores, porque son la causa más barata de descartar. Añade comprobaciones de conversión cuando la diferencia siga a los clics de pago y sobreviva a la limpieza. Para el resto del grupo de temas, consulta todas las guías sobre el fraude en Meta Ads.
