Caso de uso · Publicidad, marketing y DSPs
Filtrado pre-puja de IPs para DSPs y compra programática
Un DSP tiene milisegundos de un solo dígito para decidir si merece la pena pujar por un bid request. La IP es una de las pocas señales que están siempre presentes antes de pujar, y eso la convierte en el filtro natural para aplicar antes del gasto, no después.
Por qué el momento de la puja es el que cuenta
Respuesta rápida
El filtrado pre-puja evalúa el riesgo de tráfico inválido de la IP de un bid request antes de que el DSP decida si puja, usando señales de categoría (datacenter, proxy residencial, bot) en lugar de una llamada de red, de modo que la comprobación no añade latencia al bid loop.
Cualquier otra fase de la detección de fraude —post-puja, post-clic, post-conversión— consiste en identificar un gasto que ya se ha producido e intentar recuperarlo o excluir la fuente de ahí en adelante. La pre-puja es el único punto en el que sencillamente puedes no gastarlo.
La restricción es la velocidad. La lógica de puja de un DSP se ejecuta en milisegundos de un solo dígito, así que todo lo que se añada a ese camino tiene que salir prácticamente gratis. La IP es una de las poquísimas señales presentes en el propio bid request antes de que sea posible una llamada de red, un cookie sync o una huella de dispositivo, y por eso es el filtro viable en esta fase.
Cómo ayuda IP Raccoon
IP Raccoon se entrega como ficheros descargables, así que un DSP obtiene la evaluación de riesgo de una IP sin una sola llamada de red dentro del proceso de puja. El dataset se carga directamente en la infraestructura del comprador y se consulta en el propio proceso, y el enlace permanente del que viene es estable, así que cada publicación nueva llega sin volver a integrar nada.
El desglose por categorías es lo que lo hace utilizable en distintos tipos de inventario, en lugar de una regla única que resulta demasiado agresiva o demasiado permisiva según el contexto:
| Señal | Inventario de app móvil | Inventario de web de escritorio |
|---|---|---|
| IP de datacenter | Tráfico inválido: un móvil real no se conecta desde un datacenter | Señal más débil: aquí se solapan VPNs corporativas y navegadores en la nube |
| Proxy residencial | Sospechoso, justifica rebajar la puja | Sospechoso, pero no descalificante por sí solo |
| Bot conocido | Excluir | Excluir |
Cada comprador fija sus propios umbrales y reglas por tipo de inventario, en lugar de heredar la política general de otro.
Qué buscar en un filtro de IP pre-puja
- Entrega en fichero, para que la comprobación se ejecute en proceso y no añada latencia al bid loop
- Desglose por categorías (datacenter, proxy residencial, bot conocido, anonimizador), no una única puntuación opaca
- Frecuencia de actualización suficiente para detectar rangos de datacenter y pools de proxies recién levantados
- Un precio que separe los créditos por consulta de la suscripción al dataset, para dimensionar cada cosa a la escala de la prueba o de la campaña
$ curl -o anonymizers.mmdb \ "https://files.ipraccoon.com/download/anonymizers?authorization=$IP_RACCOON_TOKEN&format=mmdb" slugs: reputation · anonymizers · detected_bots · known_bots formats: csv (subnet) · csv_plus (subnet + subcategory) · mmdb
Filtra antes de gastar, no después
Carga los datasets de IP Raccoon en tu infraestructura de puja y comprueba qué parte de tu inventario es tráfico inválido antes de la próxima subasta.
FAQ