Prévention de la fraudeLimite d'exclusion d'IP dans Google Ads : le plafond de 500, le CIDR et ce qu'elle ne peut pas bloquer
La limite d'exclusion d'IP de Google Ads est de 500 par campagne et de 500 par compte. Comment le CIDR étire chaque emplacement, et quelles IP en méritent un, d'après six requêtes réelles.
Vous avez un journal de clics. Une poignée d'adresses reviennent sans cesse, le champ d'exclusion en accepte 500, et vous vous demandez ce qui se passera quand il sera plein. Cherchez cette limite et presque toutes les pages qui vous répondent viennent d'éditeurs anti-fraude au clic, et presque toutes les réponses se terminent de la même façon : notre outil fait tourner la liste pour vous.
Nous pensons que ce n'est pas la bonne question. La documentation de l'API de Google compte la limite en « blocs IP », donc une entrée peut couvrir une plage entière, et la question utile devient : quelles plages méritent un emplacement ? Notre position est simple. Une liste d'exclusion sert aux nuisances stables, comme votre propre bureau ou un bloc d'hébergement qui revient sans cesse, pas à la fraude. Google indique qu'il filtre déjà les clics incorrects de son côté, et nous citons cette page vers la fin.
Ci-dessous, nous donnons les deux limites dans les termes de Google, montrons comment saisir une plage dans l'interface et en CIDR via l'API, passons six adresses réelles dans notre API pour décider lesquelles méritent un emplacement, et listons ce qu'aucune exclusion ne peut empêcher. Pour l'argumentaire plus large en faveur de l'évaluation de chaque clic plutôt que son bannissement, commencez par notre guide sur la fraude au clic.
Limite d'exclusion d'IP dans Google Ads : combien d'adresses pouvez-vous exclure ?
Vous pouvez exclure 500 entrées IP par campagne et 500 par compte. Les deux chiffres figurent sur des pages Google différentes, ce qui explique pourquoi tant d'articles se trompent sur le second.
Nous avons ouvert chaque page Google citée dans cet article à 06:12 UTC le 14 octobre 2026. Le plafond par campagne figure sur la page d'aide de Google, Exclude IP addresses :
« Vous pouvez exclure jusqu'à 500 adresses IP par campagne. » (« You can exclude up to 500 IP addresses per campaign. »)
La page d'aide ne donne aucun chiffre pour le niveau du compte. Le plafond du compte se trouve dans la référence de l'API Google Ads pour CustomerNegativeCriterion, la ressource qui contient les exclusions au niveau du compte. Son champ ip_block indique : « Immutable. IpBlock. You can exclude up to 500 IP addresses per account. » Certaines pages bien classées passent à côté. L'article de Lunio sur la limite de 500, que nous avons ouvert au même moment, affirme « The 500 IP exclusion limit applies per campaign, not per account. » (la limite s'appliquerait par campagne et non par compte). La référence de Google indique que la liste du compte a son propre plafond de 500.
L'unité compte plus que le chiffre. Le tableau des limites système de l'API de Google intitule la ligne « Excluded IP blocks per campaign », valeur « 500 », erreur ResourceCountLimitExceededError.CAMPAIGN_LIMIT. Un critère est créé par adresse ou par bloc CIDR, donc dans la documentation de l'API Google, un /24 saisi une fois compte pour une entrée. Nous ne l'avons pas testé sur un compte réel. C'est pourquoi nous parlons de 500 emplacements, et non de 500 adresses.
Lorsque les deux niveaux contiennent des entrées, la page d'aide de Google indique que les listes fusionnent :
« Si vous avez configuré des exclusions d'IP à la fois au niveau du compte et au niveau de la campagne sous le même CID : Google Ads fusionne les listes d'exclusion. Cela signifie que toutes les adresses IP exclues à l'un ou l'autre niveau ne pourront pas voir vos annonces pour cette campagne. »
L'exemple de Google : « Imaginez que vous excluez les adresses IP 1, 2 et 3 au niveau de la campagne (campagne A). Puis vous excluez les adresses IP 4 et 5 au niveau du compte. Pour la campagne que vous avez configurée (campagne A), Google Ads bloquera effectivement les adresses IP 1, 2, 3, 4 et 5. » Google n'en dit pas plus sur l'interaction entre les deux plafonds, nous non plus.
| Niveau | Plafond | Où Google l'indique | Couvre |
|---|---|---|---|
| Campagne | 500 | Page d'aide 2456098 ; API CampaignCriterion.ip_block | Une campagne, et pas tous les types de campagne |
| Compte | 500 | API CustomerNegativeCriterion.ip_block uniquement | Toutes les campagnes du compte, Performance Max compris |
| Les deux | Les listes fusionnent par campagne | Page d'aide 2456098 | Chaque campagne bloque ses propres entrées plus celles du compte |
Niveau du compte ou de la campagne : où ajouter les exclusions d'IP
Ajoutez une exclusion au niveau du compte lorsqu'elle doit s'appliquer partout, et au niveau de la campagne seulement lorsqu'une campagne a un problème qui lui est propre. L'exemple de bonne exclusion que donne Google est votre propre personnel : « vous décidez d'exclure l'adresse IP du réseau de votre entreprise ». Cette adresse a sa place au niveau du compte.
Voici les étapes de Google pour le niveau du compte, tirées de la même page d'aide :
- Dans votre compte Google Ads, cliquez sur l'icône Administration.
- Cliquez sur Paramètres du compte.
- Accédez à la section « Exclusions d'adresses IP ».
- Saisissez les adresses IP auxquelles vous ne voulez pas montrer vos annonces.
- Cliquez sur Enregistrer.
Et pour une campagne :
- Dans votre compte Google Ads, cliquez sur l'icône Campagnes.
- Cliquez sur le menu déroulant Campagnes dans le menu de section.
- Cliquez sur Campagnes, puis sur Paramètres.
- Sélectionnez la campagne dont vous voulez exclure des adresses IP.
- Sur la page « Paramètres », cliquez sur Paramètres supplémentaires.
- Développez la section « Exclusions d'adresses IP », saisissez les adresses et cliquez sur Enregistrer.
Supprimer une entrée passe par le même chemin, quel que soit le niveau. Les instructions de Google consistent à suivre les étapes ci-dessus, à « supprimer les exclusions d'adresses IP que vous ne souhaitez pas appliquer », puis à cliquer sur Enregistrer. Un piège : « Vous ne pouvez pas modifier ni supprimer les exclusions au niveau du compte depuis les campagnes individuelles. » Si une entrée semble bloquée dans une campagne, regardez dans les paramètres du compte.
De bonnes entrées au niveau du compte sont votre bureau, celui de votre agence, et un bloc d'hébergement confirmé qui continue de cliquer. La plage fixe du bureau d'un concurrent mérite elle aussi un emplacement au niveau de la campagne. Si votre véritable objectif est géographique, Google vous oriente ailleurs : « Si vous essayez d'empêcher vos annonces de s'afficher dans certaines zones géographiques, excluez plutôt une zone géographique au lieu d'exclure des adresses IP. »
Quels types de campagne ne peuvent pas utiliser les exclusions d'IP au niveau de la campagne ?
Les campagnes vidéo, d'hôtel, App, Performance Max et Display intelligentes n'acceptent pas les exclusions d'IP au niveau de la campagne. La page d'aide de Google le dit dans une seule note :
« Remarque : Les exclusions d'adresses IP ne sont pas disponibles pour les campagnes vidéo, les campagnes d'hôtel, les campagnes App, les campagnes Performance Max et les campagnes Display intelligentes. »
Le niveau du compte va plus loin. Google indique que vous pouvez l'utiliser « pour empêcher des adresses IP spécifiques de voir vos annonces dans toutes les campagnes de votre compte, y compris Performance Max, Demand Gen, Réseau de Recherche, Shopping, Display, Discover et YouTube ». Performance Max n'accepte donc les exclusions d'IP qu'au niveau du compte, et cette liste correspond aux mêmes 500 entrées que partagent toutes les autres campagnes.
| Type de campagne | Exclusions au niveau de la campagne | Exclusions au niveau du compte |
|---|---|---|
| Réseau de Recherche, Shopping, Display | Disponibles | Citées par Google |
| Performance Max | Non disponibles | Citées par Google |
| Vidéo | Non disponibles | Google cite YouTube |
| Hôtel, App, Display intelligente | Non disponibles | Non précisé sur la page |
| Demand Gen | Absente de la liste des types non pris en charge | Citées par Google |
Les pages des éditeurs se contredisent sur cette liste, en partie parce que les propres pages de Google diffèrent. L'ancienne page d'aide de Search Ads 360 cite les campagnes vidéo, App, Display intelligentes et Discovery. Nous nous en tenons aux cinq types de la page Google Ads actuelle.
Comment exclure une plage d'IP : l'astérisque, le CIDR et l'IPv6
Dans l'interface, la forme de plage documentée est un astérisque sur le dernier octet. Via l'API, n'importe quel bloc CIDR IPv4 ou IPv6 compte pour une entrée.
La page d'aide de Google indique : « Vous pouvez saisir des adresses IP spécifiques, ou utiliser un astérisque (*) pour remplacer les trois derniers chiffres si vous souhaitez exclure un bloc d'adresses. » Les trois derniers chiffres désignent le dernier octet : 198.51.100.* couvre 256 adresses, comme un /24. Google documente un seul astérisque à cette position, rien d'autre. Des formes avec deux astérisques, ou un astérisque en tête, apparaissent sur certaines pages bien classées, mais Google ne documente aucune syntaxe de ce genre : ne comptez pas dessus.
L'API est plus souple. La référence IpBlockInfo de Google indique : « 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. » (exclusion d'adresses individuelles ou de blocs CIDR, un critère IpBlockInfo par adresse ou par bloc). Ses exemples sont 192.168.0.0/24 et une adresse unique sous la forme 192.168.0.1/32 pour l'IPv4, et 2001:db8::/48 et 2001:db8:a0b:12f0::1/128 pour l'IPv6.
L'interface documente les adresses uniques et l'astérisque. Les blocs CIDR et IPv6 sont documentés pour l'API. Nous n'avons pas testé ce que fait l'interface d'une entrée CIDR ou IPv6, nous ne vous dirons donc pas que cela fonctionne.
C'est dans le calcul des emplacements que le CIDR rapporte. Prenez une plage de 194.83.41.0 à 194.83.47.255, l'exemple qu'utilise une agence britannique sur WebSuccess Insights. Nous l'avons passée dans ipaddress.summarize_address_range de Python :
| Ce que vous saisissez | Où | Adresses couvertes | Entrées utilisées |
|---|---|---|---|
194.83.41.* à 194.83.47.*, une ligne par /24 | Interface | 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 sous-réseaux /64 | 1 |
L'exemple IPv6 de Google est un /48, qui contient 65 536 sous-réseaux /64. Le réseau d'un seul appareil est généralement un /64, tandis que les FAI attribuent couramment un /56 ou un /48 à un foyer : une entrée /48 peut donc couvrir tout le site d'un client. Nous expliquons ce que couvre un /48 par rapport à un /64 dans notre article sur l'IPv6.
Google ajoute une ligne : « Les adresses IP peuvent exister dans différentes versions ; veillez donc à utiliser toutes les versions de l'adresse IP que vous souhaitez exclure. » Comprenez : un bureau ou un serveur qui a à la fois une adresse IPv4 et une adresse IPv6 nécessite les deux entrées.
Ajouter des exclusions d'IP en masse via l'API Google Ads
Via l'API, une exclusion de campagne est un CampaignCriterion négatif avec un ip_block, et une exclusion de compte est un CustomerNegativeCriterion avec un ip_block. Le tableau des critères de Google indique que le bloc IP ne peut qu'être exclu, aux niveaux de la campagne et du client.
Avant d'envoyer quoi que ce soit, réduisez la liste. Ce script transforme les adresses et blocs candidats en un nombre minimal d'entrées CIDR qui les couvrent, les plus actives en premier, avec un plafond de 500. C'est le code exact que nous avons exécuté le 14 octobre, sous Python 3.9.6, avec la seule bibliothèque standard :
"""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)
Nous n'avons pas de vrais journaux de clics à publier, nous lui avons donc fourni un échantillon synthétique construit uniquement à partir de plages d'adresses de documentation. Ce ne sont pas de vrais clics et elles n'ont jamais été interrogées :
# 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
L'exécution de python3 -I build_exclusions.py < synthetic_clicks.txt a affiché :
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
Huit lignes sont devenues quatre entrées. Nous lui avons aussi fourni 600 /32 synthétiques non adjacents tirés de 198.18.0.0/15 : il a conservé les 500 plus actifs et signalé 100 entrées au-delà de la limite.
Trois choses que le script ne fait volontairement pas :
- Il n'élargit jamais une adresse.
collapse_addressesne fusionne que les blocs qui se touchent ou se chevauchent. Transformer une adresse en son /24 est une décision que vous prenez après une requête RDAP, pas quelque chose que le code doit deviner. - Il ignore la syntaxe de l'interface. Un /31 ou un /48 convient à l'API. Dans l'interface, vous saisiriez le /31 sous forme de deux adresses, et Google n'y documente aucune forme de plage IPv6.
- Il ne filtre pas les adresses partagées. Exécutez-le uniquement après que la règle des sections suivantes a retiré les adresses de relais et de NAT d'opérateur.
Il n'appelle jamais non plus notre API. Si vous ajoutez une étape de requête, c'est un GET par adresse avec l'IP dans le chemin et votre clé dans l'en-tête x-api-key, comme le montre la référence de l'API. Il n'existe pas d'appel par lots. Depuis urllib en Python, définissez un User-Agent explicite, car notre API renvoie actuellement une 403 au User-Agent par défaut d'urllib.
L'envoi d'une entrée ressemble à ceci. Nous l'avons écrit à partir des références IpBlockInfo et CampaignCriterion de Google, qui affichaient la v25 le 14 octobre, avec les noms de la bibliothèque cliente Python. Nous ne l'avons pas exécuté sur un compte réel.
# 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 ne documente l'erreur que pour le plafond de la campagne. Nous n'avons trouvé aucun code d'erreur documenté pour le plafond du compte, nous n'en citons donc aucun. Les notes de la version 2.11 de Google Ads Editor comportent une rubrique « Account-level placement and IP exclusions », mais nous n'avons pas testé Editor, nous ne donnons donc aucune étape pour Editor.
Pourquoi 500 entrées ne peuvent pas contenir un réseau d'hébergement
Cinq cents entrées ne peuvent pas contenir un grand fournisseur cloud, car Google ne documente aucun moyen d'exclure un réseau par son ASN et un grand fournisseur annonce des milliers de préfixes. Nous avons compté à 06:14 UTC le 14 octobre :
| Réseau | Entrées nécessaires | Source |
|---|---|---|
| AS16509 (Amazon) | 27 319 préfixes annoncés (21 267 IPv4, 6 052 IPv6) | RIPEstat announced-prefixes, fenêtre du 2026-09-30 au 2026-10-14 |
| Plages publiées par AWS | 11 336 préfixes uniques (7 863 IPv4, 3 473 IPv6) | ip-ranges.amazonaws.com, createDate 2026-10-14-03-37-06 |
| AS63949 (Akamai Connected Cloud, anciennement Linode) | 452 (354 IPv4, 98 IPv6) | RIPEstat, même fenêtre |
| AS39351 (31173 Services, le réseau de Mullvad) | 74 (53 IPv4, 21 IPv6) | RIPEstat, même fenêtre |
| AS60729 (TORSERVERS-NET) | 6 (3 IPv4, 3 IPv6) | RIPEstat, même fenêtre |
Les décomptes de RIPEstat incluent les préfixes plus spécifiques qui se chevauchent et tout ce qui a été vu pendant la fenêtre de deux semaines : considérez-les comme une borne haute du nombre d'entrées, pas comme un espace d'adressage unique. Ils évoluent chaque jour. Malgré cela, Amazon à lui seul nécessite bien plus d'entrées que vos deux listes réunies.
La question de l'hébergement n'est donc pas « puis-je exclure le cloud ? ». Vous ne le pouvez pas. C'est « quels blocs d'hébergement reviennent sans cesse dans mon propre journal ? ». Nous expliquons séparément ce qui fait d'une adresse une IP de datacenter. Notre API signale l'hébergement à partir de 853 ASN d'hébergement sélectionnés, plus les plages officielles de 10 fournisseurs cloud, et vous pouvez tester une adresse dans l'outil gratuit de vérification d'IP de datacenter.
Une précaution avant d'écrire une règle sur ce signal. Le trafic d'hébergement est la première catégorie de trafic incorrect général (GIVT) dans la norme du MRC, mais cette même norme en exclut le routage VPN légitime et la navigation depuis des machines virtuelles, ce que nous détaillons dans GIVT vs SIVT : les catégories de trafic incorrect de Google. L'hébergement seul obtient volontairement un score faible : 45.33.32.156 ci-dessous renvoie detection.is_hosting: true et un score de 10, allow. Pour les clics payants, décider si le trafic d'hébergement doit voir vos annonces relève de votre règle, pas du score.
Quelles adresses méritent l'un de vos 500 emplacements
Un emplacement doit revenir à une plage stable que personne d'autre ne partage et que vous avez vue dans votre propre journal de clics. Pour montrer à quoi cela ressemble, nous avons interrogé six adresses publiques à 06:12 UTC le 14 octobre avec un GET https://api.geoiphub.com/v1/lookup/{ip} anonyme. Les six ont renvoyé HTTP 200. Aucune n'a cliqué sur l'annonce de qui que ce soit. Elles représentent les types d'adresses que contient un journal de clics.
Notre réponse ne contient pas de champ de préfixe, nous avons donc relevé chaque bloc enregistré dans RDAP à 06:14 UTC, via rdap.org, qui a redirigé vers l'ARIN et le RIPE.
| IP, de quoi il s'agit | asn / org | user_type | is_hosting | is_vpn | is_relay | is_cgnat | Score, action | detection_methods | Bloc RDAP | Emplacement ? |
|---|---|---|---|---|---|---|---|---|---|---|
| 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) | Seulement si ce bloc revient dans votre journal de clics, selon votre propre règle pour le trafic publicitaire |
| 185.220.101.1, sortie Tor, Hambourg | 60729 TORSERVERS-NET | hosting | true | false | false | false | 100, block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer | 185.220.101.0/27 (ARTIKEL10) | Oui : un bloc d'opérateur stable avec quatre raisons indépendantes |
| 45.83.220.7, réseau 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 | Non par défaut : évaluez-le au moment du 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 | Possible, mais le même opérateur a obtenu 46 sur la ligne précédente |
| 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) | Jamais |
| 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) | Jamais. Un relais avec is_hosting: true |
Deux lignes méritent une remarque. Le nom de VPN sur 45.83.220.7 provient de notre table des réseaux d'hébergement VPN, avec une confiance de 85, et non de la liste de serveurs de Mullvad elle-même, qui ne l'incluait pas lors de notre vérification le 13 octobre. Et 104.28.46.99 se trouve dans le /12 enregistré de Cloudflare mais en dehors des plages que Cloudflare publie pour son propre réseau : « exclure le bloc de Cloudflare » couperait donc des utilisateurs du relais d'Apple, pas des serveurs de Cloudflare.
Une adresse, de bout en bout
Suivez 185.220.101.1 du clic jusqu'à l'entrée. Avec le marquage automatique activé, Google ajoute un GCLID à votre URL de destination, « www.example.com/?gclid=123xyz » dans l'exemple de Google. Enregistrez l'IP du client à côté de ce gclid sur votre page de destination, car c'est cette association qui relie une adresse à un clic payant.
Interrogez ensuite l'adresse. Voici une copie abrégée de notre réponse de 06:12 UTC, imbrication conservée, valeurs non modifiées :
{
"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 vaut true, le score est de 100, et quatre méthodes distinctes se sont déclenchées. La réponse nomme le réseau enregistré mais pas sa taille, nous avons donc interrogé RDAP : 185.220.101.0 à 185.220.101.31, un /27. Ce bloc devient une entrée, 185.220.101.0/27, via l'API. Il coûte un emplacement sur 500 et couvre 32 adresses exploitées par un seul opérateur Tor. C'est un bon échange.
La règle que nous suivrions
- Ne consacrez des emplacements qu'à des plages stables et non partagées que vous avez vues dans votre propre journal de clics : blocs d'hébergement avec
is_relay: false, et blocs d'opérateurs Tor. - Ne consacrez jamais d'emplacement à une adresse dont
detection.is_relayouthreat.is_cgnatvaut true, quel que soit le score. - Évaluez tout le reste clic par clic à l'arrivée, VPN compris, car un même opérateur VPN a obtenu 46 et 100 sur deux de ses adresses.
- Prenez le bloc dans RDAP ou dans le fichier de plages du fournisseur, pas dans notre réponse.
Les tranches de score derrière ces actions sont allow jusqu'à 25, review jusqu'à 50, step_up jusqu'à 75 et block au-dessus de 75. Nous expliquons le fonctionnement des tranches du score de fraude dans un article distinct, et vous pouvez vérifier une adresse dans l'outil gratuit de score de fraude IP avant d'y consacrer un emplacement.
Ne consacrez jamais d'emplacement à une adresse partagée : NAT d'opérateur et Private Relay
Les adresses de NAT d'opérateur et d'iCloud Private Relay transportent de nombreuses personnes réelles à la fois : en exclure une masque vos annonces à toutes. Aucun score ni aucun nombre de clics n'y change rien.
Commencez par Private Relay. De nombreux utilisateurs Apple partagent chaque adresse de sortie, et notre scoring plafonne un relais à 60 : une IP Private Relay ne peut donc jamais atteindre block. Le piège se trouve dans le tableau ci-dessus. 172.224.226.1 figure sur la liste de relais d'Apple et renvoie pourtant detection.is_hosting: true, parce qu'elle fonctionne dans les datacenters d'Akamai. Une règle du type « exclure tous les blocs d'hébergement » exclurait des utilisateurs Apple. Vérifiez is_relay avant toute autre chose, comme nous l'expliquons dans laisser passer les utilisateurs de relais et de VPN.
Le NAT d'opérateur est la version mobile du même problème. Nous n'avons aucune adresse d'opérateur sûre à vous montrer, car nous n'interrogeons ni ne publions jamais d'adresses de particuliers : cette partie reste donc en prose. threat.is_cgnat signale les adresses partagées par de nombreux abonnés d'un opérateur, et notre scoring applique un plafond de NAT d'opérateur à 50 : une adresse d'opérateur partagée sans autre élément à charge reste en dessous de step_up. La plage de la RFC 6598, 100.64.0.0/10, correspond au côté interne de l'opérateur et n'apparaît jamais comme IP de clic. Vous verrez à la place l'adresse publique de l'opérateur.
Le coût d'une erreur a été décrit il y a des années. La RFC 6269 avertit qu'avec des adresses partagées, « 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 utilisateur qui échoue à plusieurs tentatives de connexion peut bloquer d'autres utilisateurs qui n'ont fait aucune tentative et échoueront dès la première). Remplacez les tentatives de connexion par des clics publicitaires et vous obtenez le problème des exclusions. Notre article pilier explique plus en détail pourquoi bannir une adresse partagée touche de vrais clients.
Ce qu'une exclusion d'IP ne peut pas bloquer
Une exclusion d'IP ne peut pas empêcher tous les clics d'une adresse, ne peut pas viser un réseau et n'a aucun effet sur les clics déjà payés. Google le dit lui-même pour la première partie, sur Why do I get clicks from excluded IP addresses? :
« Lorsque vous utilisez l'outil d'exclusion d'adresses IP (Internet Protocol), des clics provenant d'adresses IP exclues peuvent tout de même apparaître dans vos journaux web. »
Il donne trois raisons :
- La rotation. « Certains fournisseurs d'accès à Internet font tourner en permanence les adresses IP de leurs utilisateurs. » L'annonce s'affiche sur une adresse et le clic arrive depuis une autre.
- Les données manquantes. « Certains sites du Réseau Google ne fournissent pas d'informations IP ; les utilisateurs disposant de vos adresses IP exclues peuvent donc voir votre annonce sur ces sites. Nous ne pouvons pas garantir qu'il n'y aura aucun clic depuis une adresse IP donnée. »
- Les clics naturels. « l'URL de provenance d'un clic sur les résultats de recherche naturels de Google et sur une annonce est la même. L'exclusion d'adresses IP ne s'appliquant qu'aux annonces, il est possible que le clic que vous voyez provienne en réalité de nos résultats de recherche. »
Puis vient la phrase qui fonde toute notre position :
« Google filtre automatiquement et de manière proactive les clics incorrects de votre compte. Vous n'avez rien à faire pour bénéficier de cette protection. Vous pouvez toutefois utiliser l'outil d'exclusion d'adresses IP pour mieux contrôler les emplacements de vos annonces. »
Contrôle des emplacements, selon les termes de Google, et non défense contre la fraude. Google ne documente par ailleurs aucun paramètre d'exclusion par ASN, FAI, VPN, proxy ou datacenter, et une exclusion ne vous rembourse pas les clics déjà facturés.
Notre côté a lui aussi ses limites. Notre API classe une IP que vous lui fournissez. Elle ne voit ni vos clics Google Ads ni vos GCLID, qui ne proviennent que de votre propre journal de page de destination. Elle ne renvoie aucun préfixe, le bloc vient donc toujours de RDAP. Et les résultats évoluent : jusqu'au 13 octobre, notre guide sur la fraude au clic utilisait 45.83.220.7 comme simple exemple d'hébergement, et aujourd'hui l'API l'identifie comme le réseau de Mullvad. Datez chaque résultat sur lequel vous agissez.
Que faire de chaque type d'adresse :
| Type d'adresse | Que faire | Pourquoi |
|---|---|---|
| Votre bureau, la plage fixe du bureau d'un concurrent, un bloc d'hébergement ou Tor stable vu à plusieurs reprises dans votre journal | Exclure, une entrée CIDR par bloc, au niveau du compte | Stable, non partagé, peu d'entrées |
NAT d'opérateur (threat.is_cgnat: true), iCloud Private Relay (is_relay: true) | Ne jamais exclure | De nombreux utilisateurs réels par adresse |
| Sorties VPN, adresses d'hébergement ponctuelles, tout ce qui tourne | Évaluer à l'arrivée avec scoring.recommended_action | Le même opérateur a obtenu 46 et 100 |
Deux vérifications à faire cette semaine sur votre propre liste d'exclusion :
- Réduisez-la. Exportez vos entrées actuelles et passez-les dans le script ci-dessus. Les entrées qui fusionnent libèrent des emplacements : comptez ce qui reste avant d'ajouter quoi que ce soit.
- Retirez les adresses partagées. Interrogez une adresse de chaque entrée dans l'outil de score de fraude. Supprimez toute entrée pour laquelle
is_relayouis_cgnatrenvoie true.
Questions fréquentes
Combien d'adresses IP peut-on exclure dans Google Ads ?
Jusqu'à 500 par campagne, et la référence de l'API Google fixe le même plafond de 500 pour les exclusions au niveau du compte. La liste du compte n'est pas une réserve plus grande.
Peut-on utiliser le CIDR ou l'IPv6 dans les exclusions d'IP de Google Ads ?
Via l'API Google Ads, oui : chaque bloc CIDR IPv4 ou IPv6 compte pour une entrée. La page d'aide de Google ne documente, pour l'interface, que des adresses uniques et un astérisque sur le dernier octet.
Peut-on exclure des adresses IP de Performance Max ?
Uniquement au niveau du compte. Les exclusions d'IP au niveau de la campagne ne sont pas disponibles pour les campagnes vidéo, d'hôtel, App, Performance Max et Display intelligentes.
Pourquoi des clics arrivent-ils encore depuis des adresses IP exclues ?
Google donne trois raisons : certains FAI font tourner les adresses de leurs utilisateurs, certains sites du Réseau Google ne fournissent pas d'informations IP, et les clics naturels et payants partagent le même référent.
Exclure une adresse IP rembourse-t-il les clics déjà payés ?
Non. Une exclusion empêche vos annonces de s'afficher pour cette adresse à partir de ce moment. Les crédits pour clics incorrects relèvent d'une procédure distincte.
Faut-il exclure une IP d'opérateur mobile ou d'iCloud Private Relay ?
Non. De nombreuses personnes réelles partagent chacune de ces adresses : évaluez le clic au lieu d'y consacrer un emplacement.
L'équipe derrière l'API GeoIPHub
Rédigé par l'équipe GeoIPHub, les personnes qui développent l'API de renseignement IP GeoIPHub et son scanner. Les brouillons sont préparés avec l'aide de l'IA et relus par l'équipe ; les exemples d'API sont de vraies requêtes sur l'API en production, sauf mention « illustratif ».
