Filtrado de tráfico no válido en una plataforma publicitaria: qué puede construir tu equipo y cuándo comprar un proveedor de verificación

Construye tú mismo el filtrado del tráfico no válido general y compra la detección del sofisticado a un proveedor de verificación, salvo que puedas permitirte un equipo antifraude propio. El tráfico no válido general, como las direcciones conocidas de centros de datos, los bots declarados y los anuncios invisibles de 1x1, se detecta con listas y reglas. Tus propios ingenieros pueden aplicarlas cuando llega una solicitud y otra vez en los registros. El tráfico no válido sofisticado, como los dispositivos secuestrados y las apps suplantadas, necesita datos de mucho más tráfico del que ve una sola plataforma, y analistas que lo estudien. Los programas de certificación, como el de TAG, también esperan un filtrado hecho por un tercero cualificado.

¿Qué se considera tráfico no válido?

El Media Rating Council (MRC) es el organismo estadounidense que acredita la medición publicitaria. Su Invalid Traffic Detection and Filtration Standards Addendum (la actualización de junio de 2020, consultada el 27 de octubre de 2026, como las demás fuentes de aquí) divide el tráfico no válido en dos tipos. El tráfico no válido general, o GIVT, es el «tráfico identificado mediante medios rutinarios de filtrado, ejecutados aplicando listas u otras comprobaciones estandarizadas de parámetros». Entre los ejemplos del MRC están:

• El tráfico no válido conocido procedente de centros de datos
• Los bots, las arañas y otros rastreadores
• Las solicitudes de user agents que no son navegadores o de navegadores desconocidos
• Las páginas precargadas o prerrenderizadas que ningún usuario real llegó a ver
• Las ubicaciones invisibles, como los anuncios de 0x0 o 1x1 píxeles

El tráfico no válido sofisticado, o SIVT, abarca «situaciones más difíciles de detectar que requieren analítica avanzada, corroboración o coordinación desde varios puntos, una intervención humana significativa, etc., para analizarlas e identificarlas». Entre los ejemplos del MRC están:

• El software de automatización y los emuladores
• Los dispositivos infectados y secuestrados
• La actividad humana pagada y organizada, como las granjas de clics
• Los clics y las redirecciones forzados
• Los eventos de medición falsificados
• Los dominios y las apps suplantados

¿Qué filtros pueden construir nuestros propios ingenieros?

El tipo general está pensado para compartirse. El MRC dice que el filtrado de GIVT «está pensado para ser coherente entre proveedores», por eso se apoya en listas comunes. Un equipo interno trabaja con dos de ellas:

• La IAB/ABC International Spiders & Bots List, que la Alliance for Audited Media mantiene en nombre del IAB Tech Lab
• La Data Center IP List, que el Trustworthy Accountability Group (TAG) publica cada mes

Además de las listas, el equipo escribe reglas para los user agents, los tamaños de anuncio y las solicitudes de precarga, y las aplica cuando llega una solicitud y otra vez cuando se registran los eventos. También guarda un registro de cada solicitud filtrada y del motivo, para poder explicar las cifras a los socios.

Para las empresas de medición que audita, el MRC fija un punto de partida para el tráfico de centros de datos. Tienen que filtrar el tráfico no válido procedente de direcciones IP de «las tres mayores entidades de alojamiento conocidas: Amazon AWS, Google y Microsoft». Hay excepciones para que los usuarios reales que se conectan a la web a través de esas redes no se filtren por error.

El filtrado puede hacerse en dos momentos. De entrada, la plataforma bloquea una solicitud de anuncio o decide no pujar por ella. Después, elimina los eventos no válidos de los registros y de los recuentos. El MRC escribe: «Cada técnica tiene ciertas fortalezas y debilidades, y ambas tienen su lugar en una estrategia de protección del tráfico bien ejecutada». Bloquear pronto, además, ahorra el coste de procesar una solicitud que se descartaría más tarde.

Las listas pierden fuerza a medida que los navegadores y las apps comparten menos datos. En una actualización de 2024, el MRC lo expresó así: «Una dirección IP limitada o inexistente y una cadena de User Agent (UA) menos detallada pueden debilitar los enfoques basados en listas».

¿Cuándo vale la pena pagar a un proveedor de verificación?

La detección del tráfico sofisticado depende de ver patrones en muchos editores, apps y dispositivos, y de analistas que siguen los nuevos esquemas a medida que aparecen. Una plataforma solo ve su propio tráfico, así que se le escapan los patrones que solo aparecen al juntar muchas plataformas. Un equipo que hace bien este trabajo equivale a una empresa antifraude dentro de tu empresa.

La certificación puede zanjar la cuestión. El programa Certified Against Fraud de TAG menciona como uno de sus requisitos clave que «el 100% de sus transacciones monetizables se filtren para la detección y eliminación de IVT por un tercero cualificado». TAG permite a los editores cumplirlo a través de una supply-side platform que tenga un sello de certificación válido. Si tus compradores o socios piden la certificación de TAG, los filtros que construyas por tu cuenta no bastarán por sí solos para cumplir ese requisito.

El MRC publica una lista de los servicios que acredita. Su lista digital incluye empresas de verificación como DoubleVerify, HUMAN, Integral Ad Science, Pixalate y Protected Media. La acreditación cubre servicios y métricas concretos, así que pregunta al proveedor cuáles de sus servicios están acreditados y si eso incluye el tráfico no válido sofisticado.

Construir, comprar o ambas cosas: ¿qué cubre cada opción?

• Solo con medios propios: detectas el tráfico no válido general a cambio del tiempo de tus ingenieros y de las suscripciones a listas que hagan falta, y las reglas y los datos son tuyos. Los esquemas sofisticados pasan sin detectarse, y los requisitos de filtrado por un tercero quedan sin cumplir.
• Solo un proveedor: se detectan los dos tipos, pero cada decisión depende de los sistemas y las tarifas del proveedor, y una comprobación del proveedor dentro de la ruta de puja añade tiempo a cada solicitud.
• Ambas cosas: tus propios filtros descartan pronto y con poco coste el tráfico evidente, y el proveedor solo ve el tráfico que ha pasado esos filtros.

¿Qué tiene que registrar la plataforma en cualquiera de las opciones?

Quien se encargue de la detección necesita los detalles de cada transacción publicitaria. El MRC enumera los campos que una empresa de medición debe recoger cuando sea posible, entre ellos:

• El tipo de evento, un ID de transacción y una marca de tiempo
• La dirección IP, incluida la cabecera X-Forwarded-For cuando el tráfico pasa por proxies
• La cadena completa del user agent y el tipo de dispositivo
• El identificador de la app, o la URL completa de la página donde se mostró el anuncio
• Los ID del editor, del sitio y de la ubicación, y la información de ads.txt o app-ads.txt del editor
• Los atributos de OpenRTB de la solicitud de puja

Los informes deben mantener separadas las cifras brutas y las filtradas. Para los informes de campaña, el estándar del MRC enumera «Gross Metrics (Completely Unfiltered)» y «Net Metrics (Filtered for GIVT Requirements)». Cuando corresponde, las cifras filtradas por tráfico no válido sofisticado aparecen como un paso aparte. Si tu pipeline de eventos ya pierde eventos o los cuenta dos veces, arregla eso primero: el filtrado no puede reparar cifras que ya eran erróneas antes de aplicarlo.

¿Qué preguntar a la empresa que integra el filtrado en nuestra plataforma?

• ¿En qué punto de la ruta de puja se ejecuta cada filtro y cuánto tiempo añade a una solicitud?
• Si la comprobación del proveedor no responde a tiempo, ¿la solicitud sigue adelante o se descarta?
• ¿Cómo se actualizan las listas y quién comprueba que no se filtra por error a usuarios reales?
• ¿Cómo aparecerán las cifras brutas y las filtradas en nuestros informes y en los de nuestros socios?
• ¿Qué campos de cada solicitud se guardan, durante cuánto tiempo y bajo qué normas de privacidad?

La última pregunta también le importa al MRC. Su actualización de 2024 dice que «las normas de privacidad no son una barrera que haya que esquivar con ingeniería, sino requisitos firmes que hay que cumplir».

¿Dónde encaja amBrain?

amBrain, que publica este blog, construye los sistemas en los que se integra el filtrado. Una de sus líneas dice: «amBrain construye ad servers: segmentación, frequency capping e informes». Otra dice: «amBrain construye pipelines de analítica de eventos para ad tech: recopilación, procesamiento e informes de eventos de impresión y de clic». Entre sus trabajos de AdTech está RTBBidder, una demand-side platform que construyó para un cliente.

Desarrolla software desde 2019 y trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables».

Este artículo no es un caso de estudio. No dice que amBrain haya construido detección de fraude para ningún cliente ni que ofrezca servicios de verificación. Si amBrain está en tu lista corta, hazle las mismas preguntas que a cualquier otra empresa.