Cómo detectar el fraude de clics por dirección IP (sin una lista de exclusión)

Todos los anunciantes descubren el fraude de clics de la misma manera. El gráfico de gasto parece normal, el de clics parece estupendo y el de conversiones es una línea plana. Abres los logs en bruto, ordenas por IP y ahí está: la misma dirección, cuarenta veces, sin conversiones, todo en una sola tarde.

Así que haces lo obvio. Pegas esa dirección en la lista de exclusión de IP.

Funciona, por poco tiempo. Luego los clics vuelven desde otra dirección, y otra, y otra, y en algún momento hacia la trigésima entrada de tu lista de exclusión empiezas a sospechar que estás jugando una partida que no puedes ganar. Así es. La lista de exclusión no es una versión débil de la herramienta correcta. Es la herramienta equivocada, y vale la pena entender exactamente por qué antes de ver qué la sustituye: una puntuación de riesgo para la red que hay detrás de cada clic.

Qué hacen realmente las plataformas publicitarias con los clics no válidos

Empieza por lo que la mayoría de los anunciantes da por resuelto.

Google sí filtra el tráfico no válido, y lo dice claramente. Su documentación sobre tráfico no válido define el tráfico no válido como "tráfico que no representa un interés genuino en tu negocio" y afirma que "si Google identifica una interacción como no válida antes del final del ciclo de facturación, no pagas por ella". Volvimos a leer esa página el 13 de octubre de 2026 y la han reescrito, así que las citas de esta sección reflejan su redacción actual.

Eso es real, y no es poca cosa. Pero fíjate en lo que protege. Protege la factura. El tráfico no válido detectado antes de fin de mes "se elimina automáticamente de tus informes de facturación y de campaña, así que no hacen falta reembolsos". Si Google lo detecta después de facturarte, "recibirás créditos en forma de ajuste de facturación por el valor de la actividad no válida". Nada de eso te dice qué palabra clave, ubicación o audiencia está atrayendo el fraude. No impide que el tráfico contamine tu analítica, y no impide que una conversión falsa llegue a tu modelo de pujas.

Puedes pedir a Google que investigue el tráfico que se le escapó, con límites. Google "limita las investigaciones a los últimos 60 días", y la misma página advierte que "una investigación no podrá confirmar si clics concretos se marcaron como válidos o no válidos". La razón de Google es que compartir esos detalles ayudaría a los actores maliciosos a esquivar sus defensas. Es una razón justa, y aun así te deja sin una respuesta a nivel de clic.

Lo más parecido a un desglose es el informe de créditos por actividad no válida. "Desglosa estos créditos por campaña y red" y añade los clics e interacciones detrás de cada crédito. Solo está disponible para campañas de búsqueda y Performance Max, y cubre créditos, que se emiten por actividad no válida detectada después de una factura. El tráfico que Google filtró antes de facturar nunca se convierte en crédito, así que no aparece en este informe.

La información equivalente de Meta es todavía más escasa. Su página sobre clics no válidos dice que Meta "toma varias medidas para reducir el riesgo de abuso por clics no válidos", realiza una revisión manual cuando se detecta o se denuncia actividad sospechosa y no te cobrará los clics que se determinen no válidos. Ese es todo el compromiso.

Ambas plataformas se ponen nota a sí mismas, justo en la única métrica en la que sus intereses y los tuyos divergen. Lo que quede después de su filtro es problema tuyo, y tu problema se mide en estrategia, no solo en dinero.

Por qué falla una lista de exclusión de IP

• Se queda sin espacio y no puede nombrar una red. Google Ads limita las exclusiones de IP a 500 por campaña y 500 por cuenta, la interfaz solo documenta un comodín en el último octeto y Performance Max solo admite exclusiones a nivel de cuenta. Cubrimos los límites exactos, las entradas CIDR a través de la API y qué direcciones merecen un hueco en la guía sobre el límite de exclusiones de IP de Google Ads.
• No existe en Meta. Meta Ads Manager no tiene función de exclusión de IP. Todas las herramientas de terceros contra el fraude de clics en Meta lo sortean empujando a los usuarios sospechosos a una exclusión de público personalizado, que es un mecanismo fundamentalmente distinto y más tosco.

Esos son los límites mecánicos. El límite estratégico es peor.

Las direcciones rotan más rápido de lo que puedes escribir

El extremo profesional del fraude publicitario no opera desde una dirección fija. Alquila IP residenciales por millones.

En 2025 Google demandó a los operadores de la botnet BADBOX 2.0, que había comprometido más de 10 millones de dispositivos Android no certificados. Fíjate para qué se usaba uno solo de esos dispositivos infectados: creación de nodos de proxy residencial, fraude publicitario programático, anuncios ocultos y fraude de clics. Todo ello desde un único TV box comprometido en el salón de alguien. La investigación PROXYLIB de HUMAN Security encontró la cadena de suministro que lo alimentaba: aplicaciones Android, publicadas en Google Play, que inscribían en silencio los teléfonos de sus usuarios como nodos de salida de proxy.

Es la misma infraestructura sobre la que escribimos en por qué hay tantos proxies residenciales en tu tráfico. Para un anunciante significa que el clic fraudulento que acaba de costarte 14 dólares llegó desde una conexión de banda ancha doméstica real en tu ciudad objetivo, perteneciente a una persona real que no tiene ni idea de que su router está en alquiler. No hay ninguna dirección que vetar. Hay diez millones, y mañana serán otros diez millones distintos.

Y vetarlas afecta a clientes reales

Esta es la parte que, en silencio, cuesta más que el propio fraude.

Una dirección IP pública ya no significa una persona. El NAT de nivel de operador coloca a cientos o miles de abonados móviles detrás de una sola dirección pública, y el RFC 6269, la evaluación del IETF sobre lo que rompe el uso compartido de direcciones, anticipó la consecuencia hace años: cuando un servidor penaliza una dirección compartida, "un usuario que falla varios intentos de inicio de sesión puede dejar fuera a otros usuarios que no han hecho ningún intento previo".

Cambia "intentos de inicio de sesión" por "clics fraudulentos" y tienes tu lista de exclusión. Excluye de forma permanente la IP del operador móvil detrás de la que casualmente estaba un defraudador y habrás borrado un número desconocido de compradores móviles reales de todas las campañas de la cuenta: en silencio, sin ningún informe, para siempre. Es la versión en gasto publicitario del problema de los rechazos falsos que tratamos en cómo detectar tráfico anonimizado sin bloquear a clientes reales.

Una lista de exclusión no tiene el concepto de "probablemente malo". Solo tiene "vetado". Ese es el defecto de diseño fatal, y es la razón por la que la respuesta no es una lista más larga.

El cambio de enfoque: la IP es evidencia, no un veredicto

Deja de preguntar "¿está esta dirección en mi lista negra?" y empieza a preguntar "¿de qué tipo de red viene este clic y cuánto me fío de ella?".

Esa pregunta tiene una respuesta rica, porque una dirección IP lleva una gran cantidad de contexto que no tiene nada que ver con su historial de reputación. A un defraudador le cuesta falsear ese contexto, porque es una propiedad de la infraestructura que toma prestada y no de la solicitud que envía.

El sector ya lo formalizó, y esa es la parte que la mayoría de los consejos sobre PPC pasa por alto.

Lo que ya exigen los estándares

Las IVT Detection and Filtration Standards del Media Rating Council dividen el tráfico no válido en dos niveles, y esa división se corresponde casi a la perfección con lo difícil que es leer la IP. El tráfico no válido general (GIVT) se detecta "mediante la aplicación de listas o con otras comprobaciones de parámetros estandarizadas", y la primera categoría que el MRC incluye en él es el tráfico de datacenter no válido conocido. El tráfico no válido sofisticado (SIVT) es el nivel más difícil, que requiere "analítica avanzada, corroboración/coordinación desde múltiples puntos e intervención humana significativa", y ahí está el tráfico de proxies no válido. Repasamos todas las categorías de ambos niveles, junto a las nueve de Google, e indicamos cuáles puede ver una consulta de IP, en GIVT frente a SIVT: las categorías de tráfico no válido de Google.

Las directrices Certified Against Fraud de TAG hacen obligatoria la mitad del datacenter: una empresa certificada "debe aplicar filtrado de amenazas de IP de datacenter en todas las transacciones monetizables (incluidas impresiones, clics, conversiones, etc.)", y la sección 4.8.a añade que usar solo la TAG Data Center IP List no basta. De ahí se derivan dos cosas para un anunciante. Si los organismos de estándares tratan el filtrado de IP de datacenter como un mínimo de cumplimiento, un anunciante que no lo hace está por debajo de ese mínimo. Y los estándares dicen lo mismo que este artículo: las listas se encargan del nivel fácil, y el nivel difícil requiere análisis.

Las señales de la dirección IP que detectan el fraude de clics

Esto es lo que hay que leer de la IP, más o menos en orden de relación señal-ruido para el tráfico de pago. Para ver los mismos indicadores aplicados a bots más allá de los clics en anuncios, y dónde se queda ciego cada uno, consulta qué señales de IP identifican bots.

Fíjate en la dirección de la última fila. Un buen modelo de puntuación no solo suma puntos. También los resta. Un ISP residencial y un rastreador verificado son motivos para ser más indulgente, un rango de NAT de nivel de operador tiene la puntuación limitada, y un sistema que no tenga en cuenta todo esto triturará tu audiencia móvil real a base de falsos positivos. Ese principio se explica motivo por motivo en los motivos exculpatorios detrás de una puntuación de riesgo, y en publicidad importa más que casi en ningún otro sitio, porque en el tráfico de pago un falso positivo no es un inicio de sesión bloqueado. Es un cliente que pagaste por captar y luego tiraste.

Cómo leerlo en una sola llamada

En concreto, es una consulta sobre la IP que generó el clic, antes de decidir cuánto valía. Puedes hacer la misma comprobación a mano en el comprobador gratuito de puntuación de riesgo de IP.

Los campos que importan para un clic de pago están repartidos en cuatro grupos de la respuesta:

Un clic desde hosting puntúa bajo, un clic desde Tor puntúa 100

La puntuación por sí sola no descontará por ti un clic de datacenter, y dos consultas reales muestran por qué sigues teniendo que leer los campos. Consultamos ambas direcciones el 13 de octubre de 2026 y las volvimos a ejecutar el 14 de octubre de 2026 con los mismos valores; el primer bloque es la respuesta del 14 de octubre. Los resultados cambian a medida que se mueven los rangos. La primera es la IP de hosting de la solicitud anterior: scanme.nmap.org, el host de pruebas público que Nmap tiene en Akamai Connected Cloud en Fremont, California. No ha hecho clic en el anuncio de nadie. Representa a cualquier servidor en la nube corriente:

La segunda es un nodo de salida de Tor en Hamburgo:

El servidor en la nube obtiene 10 y allow, con datacenter_ip como único método. Es deliberado: la puntuación general está pensada para todo tipo de tráfico, incluidas las llamadas a API y la salida de redes corporativas, donde una dirección de hosting por sí sola no es fraude. Un clic de pago es distinto, porque un comprador no hace clic en tu anuncio desde un servidor, así que para el tráfico publicitario aplica tu propia regla sobre asn.connection_type o detection.is_hosting en lugar de esperar a que la puntuación diga block. El nodo de salida de Tor no necesita ninguna regla adicional: obtiene 100 y block, y detection_methods nombra cuatro motivos independientes (nodo de salida de Tor, un rango de datacenter en una lista de bloqueo, DNS inverso de estilo Tor y un spammer conocido).

Una VPN queda en medio. Hasta esta actualización, este artículo usaba 45.83.220.7 como ejemplo de hosting corriente. El 13 de octubre de 2026 la API la identifica como un servidor de Mullvad y le da 46, review, con known_vpn_server y datacenter_ip. Esa es la ponderación que pide la tabla de señales: un clic desde una VPN es un motivo para mirar más de cerca, no para vetar, y también es un recordatorio de que hay que volver a ejecutar cualquier consulta antes de fiarse de un resultado antiguo.

Ese campo es lo que convierte esto de una caja negra en algo que puedes defender en una revisión de calidad de medios. Cuando se descuenta un clic, puedes decir con precisión por qué: conexión de datacenter en un clic de pago, o nodo de salida de Tor más un listado de spam. "Lo dijo la puntuación" no es una respuesta que nadie deba aceptar, y menos aún de sus propias herramientas antifraude.

Protege la señal de puja, no solo el clic

Esta es la parte que cambia la economía, y es donde los anunciantes invierten sistemáticamente de menos.

Bloquear un clic fraudulento te ahorra el coste de ese clic. Evitar una conversión fraudulenta te salva de algo bastante más caro: enseñar a tu algoritmo de pujas a comprar más fraude.

Tanto Smart Bidding como la optimización de Meta funcionan aprendiendo qué grupos de señales producen conversiones y pujando con más fuerza hacia ellos. Mete una conversión falsa en ese bucle y no habrás perdido un clic. Habrás pagado por entrenar al modelo para que vaya a buscar más tráfico que se parezca exactamente al que acaba de estafarte. El sistema lo perseguirá con entusiasmo e informará de resultados excelentes, porque según su propia medida está teniendo éxito.

Para ser precisos sobre lo que está documentado y lo que no: Google no publica ninguna declaración de que las conversiones fraudulentas envenenen las pujas automáticas. Lo que sí dice la documentación de Smart Bidding de Google es que "si los datos de seguimiento de conversiones no son precisos, puedes ver fluctuaciones en tu volumen, CPA o ROAS", aunque también señala que Smart Bidding puede reaccionar y ajustarse a datos imprecisos. La afirmación más fuerte de arriba es un argumento razonado a partir de cómo funciona la optimización, no una cita de Google, y deberías tratarla como tal. Es, en cualquier caso, un argumento sencillo: un optimizador maximiza lo que se le diga que cuente.

El control práctico está en el servidor, y es el único punto en el que Meta te da más control que Google y no menos. Como la Conversions API es un canal de servidor a servidor, tu servidor decide qué eventos se envían alguna vez a Meta. Una consulta de IP en el momento de la conversión (no en el momento del clic) te permite no enviar el evento en absoluto cuando el "cliente" es una dirección de datacenter. Meta nunca aprende a querer más de eso. Lo mismo se aplica a las importaciones de conversiones offline de Google.

Puntúa el clic para proteger el presupuesto. Filtra la conversión para proteger el modelo.

La lista de exclusión todavía tiene un pequeño papel

Nada de esto significa que debas vaciar la lista. Significa que debes dejar de tratarla como la estrategia.

Una lista de exclusión es la herramienta correcta para exactamente una situación: un número pequeño de infractores reincidentes, estables y de alta confianza: el rango de la oficina de un competidor, un scraper en un host fijo, una IP interna que quema tu propio presupuesto. Son un puñado de entradas, no rotan y nunca se acercarán a 500.

Todo lo demás (todo lo que rote, todo lo compartido, todo aquello de lo que no estés completamente seguro) pertenece a la puntuación, donde se puede ponderar, hacer decaer, corroborar con otras señales y revertir mañana cuando cambie la evidencia. Los vetos son permanentes y binarios. El fraude no es ninguna de las dos cosas.

Dónde funciona esto en producción

Construyo esto a ambos lados del cable, y conviene ser transparente al respecto. GeoIPHub es la capa de inteligencia IP descrita arriba. ClickFortify es nuestro producto contra el fraude de clics construido sobre ella. Puntúa en vivo los clics en anuncios de Google y Meta, sincroniza el pequeño conjunto de infractores de confianza realmente alta con las exclusiones de IP de Google Ads y filtra las conversiones sospechosas antes de que lleguen a la CAPI de Meta y al Smart Bidding de Google.

La arquitectura es el argumento de este artículo hecho realidad: la inteligencia IP se encarga de la puntuación, y la lista de exclusión solo se usa para la estrecha franja de casos en los que un veto permanente es realmente la respuesta correcta. Si prefieres construir esa lógica tú mismo, la API de arriba es la misma a la que llama.

Seis cambios que hacer antes de tu próxima campaña

• Registra la IP en cada clic en un anuncio. No puedes puntuar lo que no has registrado. Captura la dirección al llegar a la landing page, junto al gclid/fbclid.
• Puntúa, no vetes. Pasa la IP de cada clic por una consulta y guarda la puntuación con la sesión, para poder segmentar tus informes por franja de riesgo de forma retroactiva.
• Empieza por el mínimo de datacenter. El tráfico de ASN de hosting es la base GIVT del MRC y la señal de mayor confianza y menos falsos positivos que tienes. Es la victoria más barata disponible.
• Filtra las conversiones en el servidor. No envíes eventos de conversión a CAPI ni a las importaciones offline cuando la IP sea de alto riesgo. Así proteges el modelo de pujas, que vale más que el clic.
• Limita el riesgo en las IP compartidas. Asegúrate de que los rangos de CGNAT y de operadores móviles se traten como compartidos, no como malos. Es la barrera que impide que la prevención del fraude se convierta en prevención de ingresos.
• Mantén corta la lista de exclusión. Resérvala para infractores reincidentes, estables y seguros, y configúrala a nivel de cuenta para que cubra también Performance Max.

El clic ya te dijo de dónde venía. La única pregunta es si escuchabas con la atención suficiente para oír algo más que una dirección.

Preguntas frecuentes

¿Cómo se detecta el fraude de clics por dirección IP?

No comparando con una lista de vetos, sino puntuando la red de la que vino el clic. Los campos con más señal son el tipo de conexión (un clic desde un ASN de hosting o datacenter no es un comprador), los indicadores de anonimizador (VPN, proxy público, Tor), la evidencia de feeds de amenazas (botnet, escáner, spammer) con una marca de tiempo de actualidad, y la verificación de rastreadores (una solicitud que dice ser Googlebot desde una IP fuera de los rangos publicados por Google no pasa la verificación; tu código compara esa afirmación con el campo verificado de la API). Cada uno de ellos es una entrada ponderada de una puntuación de riesgo, y es la puntuación, no la IP en bruto, lo que usas para actuar.

¿Se puede bloquear el fraude de clics en Meta Ads por IP?

No. Meta Ads Manager no ofrece ninguna función de exclusión de IP, y por eso todas las herramientas de terceros contra el fraude de clics en Meta funcionan empujando a los usuarios sospechosos a una exclusión de público personalizado (Custom Audience) en lugar de bloquear una dirección. En Meta, la palanca no es el clic, es la Conversions API: como CAPI funciona del lado del servidor, tu servidor decide qué eventos de conversión se envían a Meta, así que una conversión desde una IP de datacenter simplemente puede no enviarse.

¿No filtra ya Google los clics no válidos por mí?

Google filtra algunos, y explica claramente cómo. La ayuda de Google Ads dice que el tráfico no válido detectado antes de fin de mes 'se elimina automáticamente de tus informes de facturación y de campaña, así que no hacen falta reembolsos', y el tráfico no válido detectado después de que se te haya facturado se devuelve como 'créditos en forma de ajuste de facturación'. Eso protege tu factura, no tu estrategia de campaña. Las investigaciones solo cubren los últimos 60 días, y Google dice que una investigación 'no podrá confirmar si clics concretos se marcaron como válidos o no válidos', así que no puedes rastrear el fraude hasta las palabras clave, ubicaciones o audiencias que lo atraen.

¿Por qué es peligroso bloquear una dirección IP fraudulenta?

Porque en la internet actual una misma dirección pública la comparten habitualmente muchas personas sin relación entre sí. El RFC 6269 documentó esta consecuencia hace años: cuando un servidor penaliza una dirección compartida, un usuario abusivo puede dejar fuera a otros usuarios que no hicieron nada malo. El NAT de nivel de operador coloca a cientos o miles de abonados móviles detrás de una sola IP pública, así que una exclusión permanente dirigida a un defraudador puede borrar en silencio una parte de tu audiencia móvil real de todas las campañas.

¿Se considera oficialmente tráfico no válido el tráfico de datacenter?

El tráfico de datacenter no válido conocido sí, pero no todo el tráfico de datacenter. Las IVT Detection and Filtration Standards del Media Rating Council sitúan el 'tráfico de datacenter no válido conocido' como la primera categoría del tráfico no válido general (GIVT), al tiempo que excluyen la navegación legítima desde máquinas virtuales y los artefactos de enrutamiento de usuarios reales, y el MRC exige como base filtrar el tráfico de datacenter de las tres mayores entidades de hosting (Amazon AWS, Google y Microsoft). Las directrices Certified Against Fraud de TAG van más allá y exigen a las empresas certificadas aplicar filtrado de amenazas de IP de datacenter en todas las transacciones monetizables.