Prevención del fraudeLímite de exclusión de IP en Google Ads: el tope de 500, CIDR y lo que no puede bloquear
El límite de exclusión de IP en Google Ads es de 500 por campaña y 500 por cuenta. Cómo CIDR amplía cada hueco y qué IPs merecen uno, según seis consultas reales que hicimos.
Tienes un registro de clics. Un puñado de direcciones vuelve una y otra vez, el cuadro de exclusiones admite 500 y te preguntas qué pasa cuando se llene. Busca el límite y casi todas las páginas que te responden son de un proveedor de detección de fraude de clics, y casi todas las respuestas terminan igual: nuestra herramienta rota la lista por ti.
Creemos que esa es la pregunta equivocada. La propia documentación de la API de Google cuenta el límite en "IP blocks" (bloques de IP), así que una entrada puede cubrir un rango entero, y la pregunta útil pasa a ser qué rangos se merecen un hueco. Nuestra postura es sencilla. Una lista de exclusión es para molestias estables, como tu propia oficina o un bloque de hosting que sigue apareciendo, no para el fraude. Google afirma que ya filtra los clics no válidos por su parte, y citamos esa página casi al final.
A continuación damos ambos límites con las palabras de Google, mostramos cómo introducir un rango en la interfaz y como CIDR a través de la API, pasamos seis direcciones reales por nuestra API para decidir cuáles merecen un hueco y enumeramos lo que ninguna exclusión puede detener. Para el argumento general a favor de puntuar cada clic en lugar de bloquearlo, empieza por nuestra guía sobre el fraude de clics.
Límite de exclusión de IP en Google Ads: ¿cuántas direcciones puedes excluir?
Puedes excluir 500 entradas de IP por campaña y 500 por cuenta. Las dos cifras están en páginas distintas de Google, y por eso tantos artículos se equivocan con la segunda.
Abrimos todas las páginas de Google citadas en este artículo a las 06:12 UTC del 14 de octubre de 2026. El tope por campaña está en la página de ayuda de Google Exclude IP addresses (excluir direcciones IP):
"Puedes excluir hasta 500 direcciones IP por campaña."
La página de ayuda no da ninguna cifra para el nivel de cuenta. El tope de la cuenta está en la referencia de la API de Google Ads para CustomerNegativeCriterion, el recurso que contiene las exclusiones a nivel de cuenta. Su campo ip_block dice: "Immutable. IpBlock. You can exclude up to 500 IP addresses per account." (Inmutable. IpBlock. Puedes excluir hasta 500 direcciones IP por cuenta.) Algunas páginas bien posicionadas lo pasan por alto. El artículo de Lunio sobre el límite de 500, que abrimos a la misma hora, dice "The 500 IP exclusion limit applies per campaign, not per account." (El límite de 500 exclusiones de IP se aplica por campaña, no por cuenta.) La referencia de Google dice que la lista de la cuenta tiene su propio tope de 500.
La unidad importa más que la cifra. La tabla de límites del sistema de la API de Google enumera la fila como "Excluded IP blocks per campaign" (bloques de IP excluidos por campaña), valor "500", error ResourceCountLimitExceededError.CAMPAIGN_LIMIT. Se crea un criterio por dirección o por bloque CIDR, así que, según la documentación de la API de Google, un /24 introducido una vez es una entrada. No lo hemos probado en una cuenta real. Por eso hablamos de 500 huecos y no de 500 direcciones.
Cuando ambos niveles tienen entradas, la página de ayuda de Google dice que las listas se combinan:
"Si tienes exclusiones de IP configuradas tanto a nivel de cuenta como a nivel de campaña con el mismo CID, Google Ads combinará las listas de exclusión. Esto significa que todas las direcciones IP excluidas en cualquiera de los dos niveles no podrán ver tus anuncios de esa campaña."
El ejemplo de la propia Google: "Imagina que excluyes las direcciones IP 1, 2 y 3 a nivel de campaña (campaña A). Después, excluyes las direcciones IP 4 y 5 a nivel de cuenta. En la campaña que configuraste (campaña A), Google Ads bloqueará en la práctica las direcciones IP 1, 2, 3, 4 y 5." Google no dice nada más sobre cómo interactúan los dos topes, así que nosotros tampoco.
| Nivel | Tope | Dónde lo dice Google | Cubre |
|---|---|---|---|
| Campaña | 500 | Página de ayuda 2456098; API CampaignCriterion.ip_block | Una campaña, y no todos los tipos de campaña |
| Cuenta | 500 | Solo API CustomerNegativeCriterion.ip_block | Todas las campañas de la cuenta, Performance Max incluida |
| Ambos configurados | Las listas se combinan por campaña | Página de ayuda 2456098 | Cada campaña bloquea sus propias entradas más las de la cuenta |
Nivel de cuenta o nivel de campaña: dónde añadir las exclusiones de IP
Añade una exclusión a nivel de cuenta cuando deba aplicarse en todas partes, y a nivel de campaña solo cuando una campaña tenga un problema propio. El ejemplo de la propia Google de una buena exclusión es tu propio personal: "decides excluir la dirección IP de la red de tu empresa". Esa dirección corresponde al nivel de cuenta.
Estos son los pasos de Google para el nivel de cuenta, de la misma página de ayuda:
- En tu cuenta de Google Ads, haz clic en el icono Administrador.
- Haz clic en Configuración de la cuenta.
- Ve a la sección "Exclusiones de IP".
- Introduce las direcciones IP que quieras excluir de ver tus anuncios.
- Haz clic en Guardar.
Y para una campaña:
- En tu cuenta de Google Ads, haz clic en el icono Campañas.
- Haz clic en el desplegable Campañas del menú de secciones.
- Haz clic en Campañas y después en Configuración.
- Selecciona la campaña de la que quieras excluir direcciones IP.
- En la página "Configuración", haz clic en Configuración adicional.
- Despliega la sección "Exclusiones de IP", introduce las direcciones y haz clic en Guardar.
Para quitar una entrada se sigue la misma ruta en cualquiera de los dos niveles. Las instrucciones de Google son seguir los pasos anteriores, "quitar las exclusiones de direcciones IP que no quieras aplicar" y hacer clic en Guardar. Una trampa: "No puedes editar ni quitar las exclusiones a nivel de cuenta desde las campañas individuales." Si una entrada parece atascada en una campaña, mira en Configuración de la cuenta.
Buenas entradas a nivel de cuenta son tu oficina, la oficina de tu agencia y un bloque de hosting confirmado que sigue haciendo clics. El rango fijo de la oficina de un competidor también es un hueco razonable a nivel de campaña. Si tu objetivo real es geográfico, Google te remite a otra opción: "Si quieres impedir que tus anuncios se muestren en determinadas ubicaciones geográficas, prueba a excluir una ubicación geográfica en lugar de excluir direcciones IP."
¿Qué tipos de campaña no pueden usar exclusiones de IP a nivel de campaña?
Las campañas de vídeo, de hoteles, de aplicaciones, Performance Max y de Display inteligentes no admiten exclusiones de IP a nivel de campaña. La página de ayuda de Google lo resume en una nota:
"Nota: Las exclusiones de IP no están disponibles para las campañas de vídeo, las campañas de hoteles, las campañas de aplicaciones, las campañas Performance Max y las campañas de Display inteligentes."
El nivel de cuenta llega más lejos. Google dice que puedes usarlo "para excluir direcciones IP específicas de ver tus anuncios en todas las campañas de tu cuenta, incluidas Performance Max, Demand Gen, Búsqueda, Shopping, Display, Discover y YouTube". Así que Performance Max solo admite exclusiones de IP a nivel de cuenta, y esa lista son las mismas 500 entradas que comparten todas las demás campañas.
| Tipo de campaña | Exclusiones a nivel de campaña | Exclusiones a nivel de cuenta |
|---|---|---|
| Búsqueda, Shopping, Display | Disponibles | Mencionadas por Google |
| Performance Max | No disponibles | Mencionadas por Google |
| Vídeo | No disponibles | Google menciona YouTube |
| Hoteles, aplicaciones, Display inteligentes | No disponibles | No se indica en la página |
| Demand Gen | No está en la lista de no admitidas de Google | Mencionadas por Google |
Las páginas de los proveedores no coinciden sobre esta lista, en parte porque las propias páginas de Google difieren. La antigua página de ayuda de Search Ads 360 menciona las campañas de vídeo, de aplicaciones, de Display inteligentes y Discovery. Nosotros usamos únicamente las cinco de la página actual de Google Ads.
Cómo excluir un rango de IP: el asterisco, CIDR e IPv6
En la interfaz, la forma documentada de indicar un rango es un asterisco en el último octeto. A través de la API, cualquier bloque CIDR IPv4 o IPv6 es una entrada.
La página de ayuda de Google dice "Puedes introducir direcciones IP específicas o usar un asterisco (*) para sustituir los 3 últimos dígitos si quieres excluir un bloque de direcciones". Los tres últimos dígitos significan el último octeto: 198.51.100.* cubre 256 direcciones, lo mismo que un /24. Google documenta un asterisco en esa posición y nada más. En algunas páginas bien posicionadas aparecen formas con dos asteriscos, o con un asterisco al principio, pero Google no documenta esa sintaxis, así que no confíes en ellas.
La API es más flexible. La referencia de IpBlockInfo de Google dice: "We support excluding individual IP addresses or CIDR blocks. Create one IpBlockInfo criterion for each individual IP address or CIDR block you want to exclude." (Admitimos la exclusión de direcciones IP individuales o de bloques CIDR. Crea un criterio IpBlockInfo por cada dirección IP individual o bloque CIDR que quieras excluir.) Sus ejemplos son 192.168.0.0/24 y una dirección individual como 192.168.0.1/32 para IPv4, y 2001:db8::/48 y 2001:db8:a0b:12f0::1/128 para IPv6.
La interfaz documenta direcciones individuales y el asterisco. Los bloques CIDR e IPv6 están documentados para la API. No hemos probado qué hace la interfaz con una entrada CIDR o IPv6, así que no te diremos que funciona.
La aritmética de los huecos es donde CIDR sale a cuenta. Toma un rango de 194.83.41.0 a 194.83.47.255, el ejemplo que usa una agencia británica en WebSuccess Insights. Lo pasamos por ipaddress.summarize_address_range de Python:
| Lo que escribes | Dónde | Direcciones cubiertas | Entradas usadas |
|---|---|---|---|
De 194.83.41.* a 194.83.47.*, una fila por /24 | Interfaz | 1.792 | 7 |
194.83.41.0/24, 194.83.42.0/23, 194.83.44.0/22 | API | 1.792 | 3 |
2001:db8::/48 | API | 65.536 subredes /64 | 1 |
El ejemplo de IPv6 de Google es un /48, que contiene 65.536 subredes /64. La red de un único dispositivo suele ser un /64, mientras que los ISPs suelen asignar a un hogar un /56 o un /48, así que una entrada /48 puede cubrir todo el sitio de un cliente. Explicamos qué cubre un /48 en comparación con un /64 en nuestro artículo sobre IPv6.
Google añade una línea más: "Las direcciones IP pueden aparecer en distintas versiones, así que asegúrate de usar todas las versiones de la dirección IP que quieras excluir." Interprétalo así: una oficina o un servidor con una dirección IPv4 y otra IPv6 necesita ambas entradas.
Añadir exclusiones de IP de forma masiva a través de la API de Google Ads
A través de la API, una exclusión de campaña es un CampaignCriterion negativo con un ip_block, y una exclusión de cuenta es un CustomerNegativeCriterion con un ip_block. La tabla de criterios de Google indica que el bloque de IP solo se puede excluir, a nivel de campaña y de cliente.
Antes de enviar nada, reduce la lista. Este script convierte las direcciones y los bloques candidatos en el menor número de entradas CIDR que los cubren, de más a menos activos, con un tope de 500. Es exactamente el código que ejecutamos el 14 de octubre, con Python 3.9.6 y solo la biblioteca estándar:
"""Turn candidate IPs and CIDR blocks into a Google Ads exclusion list of at most 500 entries.
Input: one entry per line, an IPv4/IPv6 address or a CIDR block (for example the
registered block you looked up in RDAP), optionally followed by a click count.
Output: the fewest CIDR entries that cover every input, busiest first, capped at 500.
"""
import ipaddress
import sys
GOOGLE_ADS_LIMIT = 500 # per campaign, and per account, in Google's API reference
def build_exclusions(lines, limit=GOOGLE_ADS_LIMIT):
clicks = {}
for line in lines:
line = line.split("#", 1)[0].strip()
if not line:
continue
parts = line.split()
net = ipaddress.ip_network(parts[0], strict=False) # 1.2.3.4 -> 1.2.3.4/32
clicks[net] = clicks.get(net, 0) + (int(parts[1]) if len(parts) > 1 else 1)
merged = []
for version in (4, 6): # collapse_addresses refuses to mix IPv4 and IPv6
nets = [n for n in clicks if n.version == version]
merged += ipaddress.collapse_addresses(nets)
# Credit each merged entry with the clicks of everything it now covers.
totals = {m: sum(c for n, c in clicks.items() if n.version == m.version and n.subnet_of(m))
for m in merged}
ranked = sorted(merged, key=lambda m: totals[m], reverse=True)
return ranked[:limit], ranked[limit:], totals
if __name__ == "__main__":
keep, dropped, totals = build_exclusions(sys.stdin)
for net in keep:
print(f"{net}\tclicks={totals[net]}")
print(f"# {len(keep)} entries kept, {len(dropped)} over the limit", file=sys.stderr)
No tenemos registros de clics reales que publicar, así que le pasamos una muestra sintética creada únicamente con rangos de direcciones de documentación. No son clics reales y nunca se consultaron:
# SYNTHETIC sample: documentation ranges (RFC 5737, RFC 3849), not real clicks
198.51.100.7 3
198.51.100.0/25 12 # a registered block you looked up
198.51.100.128/25 9 # its neighbour: merges with the line above into one /24
203.0.113.10 2
203.0.113.11 2 # adjacent to .10: the two merge into one /31
192.0.2.200 1
2001:db8::42 4
2001:db8::/48 6 # covers the address above
Ejecutar python3 -I build_exclusions.py < synthetic_clicks.txt imprimió:
198.51.100.0/24 clicks=24
2001:db8::/48 clicks=10
203.0.113.10/31 clicks=4
192.0.2.200/32 clicks=1
# 4 entries kept, 0 over the limit
Ocho líneas se convirtieron en cuatro entradas. También le pasamos 600 /32 sintéticos no adyacentes de 198.18.0.0/15, y conservó los 500 más activos e indicó 100 por encima del límite.
Tres cosas que el script no hace a propósito:
- Nunca amplía una dirección.
collapse_addressessolo combina bloques que se tocan o se solapan. Convertir una dirección en su /24 es una decisión que tomas tras una consulta RDAP, no algo que el código deba adivinar. - No le importa la sintaxis de la interfaz. Un /31 o un /48 están bien para la API. En la interfaz escribirías el /31 como dos direcciones, y Google no documenta allí ninguna forma de rango IPv6.
- No filtra las direcciones compartidas. Ejecútalo solo después de que la regla de las siguientes secciones haya eliminado las direcciones de relay y de NAT de operador.
Tampoco llama nunca a nuestra API. Si añades un paso de consulta, es un GET por dirección con la IP en la ruta y tu clave en la cabecera x-api-key, como muestra la referencia de la API. No hay llamada por lotes. Desde urllib de Python, establece un User-Agent explícito, porque nuestra API devuelve actualmente 403 al User-Agent por defecto de urllib.
Enviar una entrada tiene este aspecto. Lo escribimos a partir de la referencia de IpBlockInfo y CampaignCriterion de Google, que mostraba la v25 el 14 de octubre, usando la nomenclatura de la biblioteca cliente de Python. No lo ejecutamos contra una cuenta real.
# Written from Google's IpBlockInfo and CampaignCriterion reference (v25); not run against a live account.
operation = client.get_type("CampaignCriterionOperation")
criterion = operation.create
criterion.campaign = client.get_service("CampaignService").campaign_path(customer_id, campaign_id)
criterion.negative = True # IP blocks can only be excluded
criterion.ip_block.ip_address = "198.51.100.0/24" # one CIDR block = one criterion
client.get_service("CampaignCriterionService").mutate_campaign_criteria(
customer_id=customer_id, operations=[operation]
)
# Account level: CustomerNegativeCriterionOperation, criterion.ip_block.ip_address,
# CustomerNegativeCriterionService.mutate_customer_negative_criteria.
# At 501 campaign entries the API returns ResourceCountLimitExceededError.CAMPAIGN_LIMIT.
Google documenta el error solo para el tope de campaña. No encontramos ningún código de error documentado para el tope de cuenta, así que no nombramos ninguno. Las notas de la versión 2.11 de Google Ads Editor tienen un encabezado "Account-level placement and IP exclusions" (exclusiones de ubicaciones e IP a nivel de cuenta), pero no hemos probado Editor, así que no damos pasos para Editor.
Por qué 500 entradas no bastan para una red de hosting
Quinientas entradas no bastan para un gran proveedor de nube, porque Google no documenta ninguna forma de excluir una red por su ASN y un proveedor grande anuncia miles de prefijos. Los contamos a las 06:14 UTC del 14 de octubre:
| Red | Entradas que necesitarías | Fuente |
|---|---|---|
| AS16509 (Amazon) | 27.319 prefijos anunciados (21.267 IPv4, 6.052 IPv6) | RIPEstat announced-prefixes, ventana del 30-09-2026 al 14-10-2026 |
| Rangos publicados de AWS | 11.336 prefijos únicos (7.863 IPv4, 3.473 IPv6) | ip-ranges.amazonaws.com, createDate 2026-10-14-03-37-06 |
| AS63949 (Akamai Connected Cloud, antes Linode) | 452 (354 IPv4, 98 IPv6) | RIPEstat, misma ventana |
| AS39351 (31173 Services, la red de Mullvad) | 74 (53 IPv4, 21 IPv6) | RIPEstat, misma ventana |
| AS60729 (TORSERVERS-NET) | 6 (3 IPv4, 3 IPv6) | RIPEstat, misma ventana |
Los recuentos de RIPEstat incluyen prefijos más específicos que se solapan y todo lo visto durante la ventana de dos semanas, así que tómalos como un límite superior de entradas, no como espacio de direcciones único. Varían a diario. Aun así, solo Amazon necesita muchas veces más entradas que las que caben en tus dos listas juntas.
Así que la cuestión del hosting no es "¿puedo excluir la nube?". No puedes. Es "¿qué bloques de hosting siguen apareciendo en mi propio registro?". Explicamos por separado qué convierte una dirección en una IP de datacenter. Nuestra API marca el hosting a partir de 853 ASNs de hosting seleccionados más los rangos oficiales de 10 proveedores de nube, y puedes probar una dirección en la comprobación de IP de datacenter gratuita.
Una advertencia antes de escribir una regla basada en ese indicador. El tráfico de hosting es la primera categoría de tráfico no válido general (GIVT) en el estándar del MRC, pero el mismo estándar excluye de ella el enrutamiento legítimo por VPN y la navegación desde máquinas virtuales, algo que desgranamos en GIVT frente a SIVT: las categorías de tráfico no válido de Google. El hosting por sí solo obtiene una puntuación baja por diseño: la 45.33.32.156 de más abajo devuelve detection.is_hosting: true y una puntuación de 10, allow. En los clics de pago, si el tráfico de hosting debe ver tus anuncios es una regla que escribes tú, no la puntuación.
Qué direcciones merecen uno de tus 500 huecos
Un hueco debería ser para un rango estable que nadie más comparte y que hayas visto en tu propio registro de clics. Para mostrar cómo es eso, consultamos seis direcciones públicas a las 06:12 UTC del 14 de octubre con un GET https://api.geoiphub.com/v1/lookup/{ip} anónimo. Las seis devolvieron HTTP 200. Ninguna hizo clic en el anuncio de nadie. Representan los tipos de direcciones que contiene un registro de clics.
Nuestra respuesta no tiene campo de prefijo, así que tomamos cada bloque registrado de RDAP a las 06:14 UTC, a través de rdap.org, que redirigió a ARIN y RIPE.
| IP, qué es | asn / org | user_type | is_hosting | is_vpn | is_relay | is_cgnat | Puntuación, acción | detection_methods | Bloque RDAP | ¿Hueco? |
|---|---|---|---|---|---|---|---|---|---|---|
| 45.33.32.156, scanme.nmap.org | 63949 AKAMAI-LINODE-AP | hosting | true | false | false | false | 10, allow | datacenter_ip | 45.33.0.0/17 (LINODE) | Solo si este bloque se repite en tu registro de clics, como regla propia sobre tu tráfico publicitario |
| 185.220.101.1, nodo de salida de Tor, Hamburgo | 60729 TORSERVERS-NET | hosting | true | false | false | false | 100, block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer | 185.220.101.0/27 (ARTIKEL10) | Sí: un bloque estable de un operador con cuatro motivos independientes |
| 45.83.220.7, red de Mullvad, Malmö | 39351 31173 Services AB | hosting | true | true, "Mullvad (31173 Services)", 85 | false | false | 46, review | known_vpn_server, datacenter_ip | 45.83.220.0/24 | No por defecto: puntúalo en el momento del clic |
| 185.213.155.73, Mullvad de-fra-wg-001 | 39351 31173 Services AB | hosting | true | true, "Mullvad", 95 | false | false | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 185.213.155.0/24 | Posible, pero el mismo operador obtuvo 46 en la fila anterior |
| 104.28.46.99, iCloud Private Relay | 13335 Cloudflare | consumer_privacy_network | false | false | true | false | 9, allow | relay_ip | 104.16.0.0/12 (CLOUDFLARENET) | Nunca |
| 172.224.226.1, iCloud Private Relay | 36183 AKAMAI-AS | consumer_privacy_network | true | false | true | false | 24, allow | datacenter_ip, no_ptr_datacenter, relay_ip | 172.224.0.0/12 (AKAMAI) | Nunca. Un relay con is_hosting: true |
Dos filas necesitan una nota. El nombre de la VPN en 45.83.220.7 procede de nuestra tabla de redes de hosting de VPN con una confianza de 85, no de la lista de servidores de la propia Mullvad, que no la incluía cuando lo comprobamos el 13 de octubre. Y 104.28.46.99 está dentro del /12 registrado de Cloudflare pero fuera de los rangos que Cloudflare publica para su propia red, así que "excluir el bloque de Cloudflare" dejaría fuera a usuarios del relay de Apple, no a servidores de Cloudflare.
Una dirección, de principio a fin
Sigue a 185.220.101.1 desde el clic hasta la entrada. Con el etiquetado automático activado, Google añade un GCLID a tu URL de destino, "www.example.com/?gclid=123xyz" en el ejemplo de Google. Registra la IP del cliente junto a ese gclid en tu página de destino, porque ese emparejamiento es lo que vincula una dirección con un clic de pago.
Después, consulta la dirección. Esta es una copia recortada de nuestra respuesta de las 06:12 UTC, con el anidamiento conservado y los valores sin editar:
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"user_type": "hosting"
},
"whois": {
"netname": "ARTIKEL10",
"status": "ASSIGNED PA"
},
"detection": {
"is_vpn": false,
"is_tor": true,
"is_hosting": true,
"is_relay": false,
"is_anonymous": true
},
"threat": {
"is_spammer": true,
"is_cgnat": false
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
}
detection.is_tor es true, la puntuación es 100 y se activaron cuatro métodos distintos. La respuesta nombra la red registrada pero no su tamaño, así que preguntamos a RDAP: de 185.220.101.0 a 185.220.101.31, un /27. Ese bloque se convierte en una entrada, 185.220.101.0/27, a través de la API. Cuesta uno de 500 huecos y cubre 32 direcciones gestionadas por un mismo operador de Tor. Es un buen intercambio.
La regla que seguiríamos
- Gasta huecos solo en rangos estables y no compartidos que hayas visto en tu propio registro de clics: bloques de hosting con
is_relay: falsey bloques de operadores de Tor. - No gastes nunca un hueco en una dirección con
detection.is_relayothreat.is_cgnaten true, sea cual sea la puntuación. - Puntúa todo lo demás clic a clic en la página de destino, VPN incluidas, porque un mismo operador de VPN obtuvo 46 y 100 en dos de sus direcciones.
- Toma el bloque de RDAP o del archivo de rangos del propio proveedor, no de nuestra respuesta.
Las franjas de puntuación detrás de esas acciones son allow hasta 25, review hasta 50, step_up hasta 75 y block por encima de 75. Explicamos cómo funcionan las franjas de la puntuación de fraude en otro artículo, y puedes comprobar una dirección en el comprobador gratuito de puntuación de fraude de IP antes de gastar un hueco en ella.
No gastes nunca un hueco en una dirección compartida: NAT de operador y Private Relay
Las direcciones de NAT de operador y de iCloud Private Relay transportan a muchas personas reales a la vez, así que excluir una oculta tus anuncios a todas ellas. Ninguna puntuación ni recuento de clics cambia eso.
Empieza por Private Relay. Muchos usuarios de Apple comparten cada dirección de salida, y nuestra puntuación limita un relay a 60, así que una IP de Private Relay nunca puede llegar a block. La trampa está en la tabla anterior. 172.224.226.1 está en la lista de relays de Apple y aun así devuelve detection.is_hosting: true, porque funciona en los datacenters de Akamai. Una regla que diga "excluye todos los bloques de hosting" excluiría a usuarios de Apple. Comprueba is_relay antes que nada, como explicamos en dejar pasar a los usuarios de relays y VPN.
El NAT de operador es la versión móvil del mismo problema. No tenemos ninguna dirección de operador segura que mostrarte, porque nunca consultamos ni publicamos direcciones de consumidores, así que esta parte es solo texto. threat.is_cgnat marca las direcciones compartidas por muchos abonados de un operador, y nuestra puntuación tiene un tope de 50 para el NAT de operador, de modo que una dirección de operador compartida sin nada más en su contra se queda por debajo de step_up. El rango del RFC 6598, 100.64.0.0/10, es el lado interno del operador y nunca aparece como IP de un clic. En su lugar verás la dirección pública del operador.
El coste de equivocarse con esto quedó por escrito hace años. El RFC 6269 advierte que, con direcciones compartidas, "one user who fails a number of login attempts may block out other users who have not made any previous attempts but who will now fail on their first attempt" (un usuario que falla varios intentos de inicio de sesión puede bloquear a otros usuarios que no han hecho ningún intento previo pero que ahora fallarán en el primero). Cambia los intentos de inicio de sesión por clics en anuncios y tienes el problema de las exclusiones. Nuestro artículo principal explica con más detalle por qué bloquear una dirección compartida afecta a clientes reales.
Lo que una exclusión de IP no puede bloquear
Una exclusión de IP no puede detener todos los clics desde una dirección, no puede nombrar una red y no afecta a los clics que ya has pagado. La primera parte la dice la propia Google, en Why do I get clicks from excluded IP addresses? (¿por qué recibo clics de direcciones IP excluidas?):
"Cuando usas la herramienta de exclusión de protocolo de Internet (IP), es posible que los clics de direcciones IP excluidas sigan apareciendo en tus registros web."
Da tres motivos:
- Rotación. "Algunos proveedores de servicios de Internet rotan continuamente las direcciones IP de sus usuarios." El anuncio se muestra en una dirección y el clic llega desde otra.
- Datos que faltan. "Algunos sitios de la Red de Google no proporcionan información de IP, por lo que los usuarios con tus direcciones IP excluidas pueden ver tu anuncio en esos sitios. No podemos garantizar que no habrá clics desde una dirección IP concreta."
- Clics orgánicos. "la URL de referencia de un clic tanto en los resultados de búsqueda orgánicos de Google como en un anuncio será la misma. Como la exclusión de IP solo se aplica a los anuncios, es posible que el clic que estás viendo proceda en realidad de nuestros resultados de búsqueda."
Y luego la frase que da forma a toda nuestra postura:
"Google filtra de forma automática y proactiva los clics no válidos de tu cuenta. No tienes que hacer nada para recibir esta protección. No obstante, puedes usar la herramienta de exclusión de direcciones IP para tener un control adicional sobre la ubicación de tus anuncios."
Control de la ubicación, en palabras de Google, no defensa contra el fraude. Google tampoco documenta ninguna opción de exclusión por ASN, ISP, VPN, proxy o datacenter, y una exclusión no te devuelve el dinero de los clics ya cobrados.
Nuestra parte también tiene límites. Nuestra API clasifica la IP que le das. No puede ver tus clics de Google Ads ni tus GCLIDs, que solo salen de tu propio registro de la página de destino. No devuelve ningún prefijo, así que el bloque siempre sale de RDAP. Y las consultas varían: hasta el 13 de octubre, nuestra guía sobre el fraude de clics usaba 45.83.220.7 como ejemplo de hosting corriente, y hoy la API la identifica como red de Mullvad. Pon fecha a cada resultado sobre el que actúes.
Qué hacer con cada tipo de dirección:
| Tipo de dirección | Qué hacer | Por qué |
|---|---|---|
| Tu oficina, el rango fijo de la oficina de un competidor, un bloque estable de hosting o de Tor visto repetidamente en tu registro | Excluir, una entrada CIDR por bloque, a nivel de cuenta | Estable, no compartido, pocas entradas |
NAT de operador (threat.is_cgnat: true), iCloud Private Relay (is_relay: true) | No excluir nunca | Muchos usuarios reales por dirección |
| Salidas de VPN, direcciones de hosting puntuales, cualquier cosa que rote | Puntuar en la página de destino con scoring.recommended_action | El mismo operador obtuvo 46 y 100 |
Dos comprobaciones sobre tu propia lista de exclusión esta semana:
- Redúcela. Exporta tus entradas actuales y pásalas por el script anterior. Las entradas que se combinan liberan huecos, así que cuenta lo que queda antes de añadir nada nuevo.
- Quita las direcciones compartidas. Consulta una dirección de cada entrada en el comprobador de puntuación de fraude. Elimina cualquier entrada en la que
is_relayois_cgnatsalga true.
Preguntas frecuentes
¿Cuántas direcciones IP se pueden excluir en Google Ads?
Hasta 500 por campaña, y la referencia de la API de Google fija el mismo tope de 500 para las exclusiones a nivel de cuenta. La lista de la cuenta no es un cupo mayor.
¿Se puede usar CIDR o IPv6 en las exclusiones de IP de Google Ads?
A través de la API de Google Ads, sí: cada bloque CIDR IPv4 o IPv6 es una entrada. La página de ayuda de Google solo documenta direcciones individuales y un asterisco en el último octeto para la interfaz.
¿Se pueden excluir direcciones IP de Performance Max?
Solo a nivel de cuenta. Las exclusiones de IP a nivel de campaña no están disponibles para las campañas de vídeo, de hoteles, de aplicaciones, Performance Max y de Display inteligentes.
¿Por qué siguen llegando clics desde direcciones IP excluidas?
Google da tres motivos: algunos ISPs rotan las direcciones de sus usuarios, algunos sitios de la Red de Google no proporcionan información de IP, y los clics orgánicos y los de pago comparten el mismo referente.
¿Excluir una dirección IP reembolsa los clics que ya pagaste?
No. Una exclusión impide que tus anuncios se muestren a esa dirección a partir de ese momento. Los créditos por clics no válidos son un proceso aparte.
¿Debes excluir una IP de un operador móvil o de iCloud Private Relay?
No. Muchas personas reales comparten cada una de esas direcciones, así que puntúa el clic en lugar de gastar un hueco en ella.
El equipo detrás de la API de GeoIPHub
Escrito por el equipo de GeoIPHub, las personas que crean la API de inteligencia IP de GeoIPHub y su escáner. Los borradores se preparan con ayuda de IA y el equipo los edita; los ejemplos de la API son consultas reales contra la API en producción, salvo que se indique que son ilustrativos.
