Zum Inhalt springen
Betrugsprävention

Klickbetrug per IP-Adresse erkennen (ohne Ausschlussliste)

Erkennen Sie Klickbetrug per IP-Adresse mit Scoring statt Ausschlusslisten: Google Ads begrenzt diese auf 500 pro Kampagne, und Betrugs-IPs rotieren schneller, als Sie sie eintragen.

VonGeoIPHub-TeamVeröffentlichtAktualisiertLesezeit17 Min. Lesezeit
Ein Lichtstrahl, der wiederholt auf eine Kachel klickt, mit geisterhaften Umrissen, als Sinnbild für per IP-Adresse erkannten Klickbetrug

Jeder Werbetreibende entdeckt Klickbetrug auf dieselbe Weise. Die Ausgabenkurve sieht normal aus, die Klickkurve sieht großartig aus, und die Conversion-Kurve ist eine flache Linie. Sie öffnen die Roh-Logs, sortieren nach IP, und da ist es: dieselbe Adresse, vierzigmal, keine Conversions, alles an einem einzigen Nachmittag.

Also tun Sie das Naheliegende. Sie tragen diese Adresse in die IP-Ausschlussliste ein.

Das funktioniert, kurz. Dann kommen die Klicks von einer anderen Adresse zurück, und von noch einer, und noch einer, und irgendwo um den dreißigsten Eintrag in Ihrer Ausschlussliste beschleicht Sie der Verdacht, dass Sie ein Spiel spielen, das Sie nicht gewinnen können. So ist es. Die Ausschlussliste ist keine schwache Version des richtigen Werkzeugs. Sie ist das falsche Werkzeug, und es lohnt sich, genau zu verstehen, warum, bevor wir uns ansehen, was sie ersetzt: ein Risikoscore für das Netzwerk hinter jedem Klick.

Eine Lichtskala von Blau bis Indigo mit einem darauf platzierten Klickknoten, als Sinnbild dafür, die IP eines Klicks zu bewerten, statt sie aufzulisten
Bewerten Sie die IP jedes Klicks beim Landen; Ausschlusslisten kommen nicht hinterher.

Was die Werbeplattformen tatsächlich gegen ungültige Klicks tun

Beginnen wir mit dem, was die meisten Werbetreibenden für bereits erledigt halten.

Google filtert ungültigen Traffic, und sagt das auch klar. Seine Dokumentation zu ungültigem Traffic definiert ungültigen Traffic als „Traffic, der kein echtes Interesse an Ihrem Unternehmen darstellt“, und hält fest: „Wenn Google eine Interaktion vor Ende des Abrechnungszeitraums als ungültig erkennt, zahlen Sie nicht dafür.“ Wir haben diese Seite am 13.10.2026 erneut gelesen; sie wurde umgeschrieben, daher geben die Zitate in diesem Abschnitt ihren aktuellen Wortlaut wieder.

Das ist real, und es ist nicht nichts. Aber lesen Sie, was es schützt. Es schützt die Rechnung. Ungültiger Traffic, der vor Monatsende erkannt wird, „wird automatisch aus Ihrer Abrechnung und Ihren Kampagnenberichten entfernt, sodass keine Erstattungen nötig sind“. Findet Google ihn nach Ihrer Abrechnung, „erhalten Sie Gutschriften in Form einer Abrechnungskorrektur in Höhe des Werts der ungültigen Aktivität“. Nichts davon sagt Ihnen, welches Keyword, welches Placement oder welche Zielgruppe Betrug anzieht. Es verhindert nicht, dass der Traffic Ihre Analytics verunreinigt, und es verhindert nicht, dass eine gefälschte Conversion Ihr Gebotsmodell erreicht.

Sie können Google bitten, Traffic zu untersuchen, der durchgerutscht ist, in Grenzen. Google „beschränkt Untersuchungen auf die letzten 60 Tage“, und dieselbe Seite warnt, dass „eine Untersuchung nicht bestätigen kann, ob bestimmte Klicks als gültig oder ungültig eingestuft wurden“. Als Grund nennt Google, dass die Weitergabe dieser Details böswilligen Akteuren helfen würde, seine Abwehr zu umgehen. Das ist ein nachvollziehbarer Grund, und er lässt Sie trotzdem ohne Antwort auf Klickebene.

Am nächsten an einer Aufschlüsselung kommt der Bericht zu Gutschriften für ungültige Aktivitäten. Er „schlüsselt diese Gutschriften nach Kampagne und Netzwerk auf“ und ergänzt die Klicks und Interaktionen hinter jeder Gutschrift. Er ist nur für Such- und Performance-Max-Kampagnen verfügbar und umfasst Gutschriften, die für ungültige Aktivitäten ausgestellt werden, die nach einer Rechnung gefunden wurden. Traffic, den Google vor der Abrechnung herausgefiltert hat, wird nie zu einer Gutschrift und taucht daher in diesem Bericht nicht auf.

Die entsprechende Offenlegung von Meta ist noch dünner. Seine Seite zu ungültigen Klicks sagt, Meta „unternimmt mehrere Schritte, um das Risiko von Missbrauch durch ungültige Klicks zu verringern“, führt eine manuelle Prüfung durch, wenn verdächtige Aktivität erkannt oder gemeldet wird, und berechnet Ihnen keine Klicks, die als ungültig eingestuft wurden. Das ist die gesamte Zusage.

Beide Plattformen benoten ihre eigenen Hausaufgaben, und zwar bei genau der Kennzahl, bei der ihre Interessen und Ihre auseinanderlaufen. Was nach ihrem Filter übrig bleibt, ist Ihr Problem, und Ihr Problem bemisst sich in Strategie, nicht nur in Geld.

Warum eine IP-Ausschlussliste scheitert

  • Ihr geht der Platz aus, und sie kann kein Netzwerk benennen. Google Ads begrenzt IP-Ausschlüsse auf 500 pro Kampagne und 500 pro Konto, die Oberfläche dokumentiert nur einen Platzhalter für das letzte Oktett, und Performance Max akzeptiert Ausschlüsse nur auf Kontoebene. Die genauen Limits, CIDR-Einträge über die API und welche Adressen einen Platz verdienen, behandeln wir im Leitfaden zum Limit für IP-Ausschlüsse in Google Ads.
  • Bei Meta gibt es sie nicht. Der Meta-Werbeanzeigenmanager hat keine Funktion zum Ausschließen von IPs. Jedes Drittanbieter-Tool gegen Klickbetrug bei Meta umgeht das, indem es verdächtige Nutzer in einen Ausschluss per Custom Audience schiebt, was ein grundlegend anderer und gröberer Mechanismus ist.

Das sind die mechanischen Grenzen. Die strategische Grenze ist schlimmer.

Die Adressen rotieren schneller, als Sie tippen können

Das professionelle Ende des Werbebetrugs arbeitet nicht von einer festen Adresse aus. Es mietet Residential-IPs millionenfach.

2025 verklagte Google die Betreiber des Botnets BADBOX 2.0, das mehr als 10 Millionen nicht zertifizierte Android-Geräte kompromittiert hatte. Lesen Sie, wofür ein einziges dieser infizierten Geräte genutzt wurde: zum Aufbau von Residential-Proxy-Knoten, für programmatischen Werbebetrug, versteckte Anzeigen und Klickbetrug. All das kam von einer einzigen kompromittierten TV-Box im Wohnzimmer von irgendjemandem. Die PROXYLIB-Forschung von HUMAN Security fand die Lieferkette, die es speist: Android-Apps, veröffentlicht bei Google Play, die die Smartphones ihrer Nutzer unbemerkt als Proxy-Exit-Nodes einbinden.

Das ist dieselbe Infrastruktur, über die wir in warum so viele Residential Proxies in Ihrem Traffic sind geschrieben haben. Für einen Werbetreibenden heißt das: Der betrügerische Klick, der Sie gerade 14 $ gekostet hat, kam von einem echten Breitbandanschluss in Ihrer Zielstadt, der einer echten Person gehört, die keine Ahnung hat, dass ihr Router vermietet wird. Es gibt keine Adresse, die man sperren könnte. Es gibt zehn Millionen davon, und morgen werden es andere zehn Millionen sein.

Und sie zu sperren trifft echte Kunden

Hier ist der Teil, der unbemerkt mehr kostet als der Betrug selbst.

Eine öffentliche IP-Adresse bedeutet nicht mehr eine Person. Carrier-Grade NAT bündelt Hunderte oder Tausende Mobilfunkkunden hinter einer einzigen öffentlichen Adresse, und RFC 6269, die Bewertung der IETF, was Adress-Sharing kaputt macht, hat die Folge schon vor Jahren benannt: Wenn ein Server eine geteilte Adresse bestraft, „kann ein Nutzer, der eine Reihe von Login-Versuchen nicht besteht, andere Nutzer aussperren, die zuvor keinerlei Versuche unternommen haben“.

Ersetzen Sie „Login-Versuche“ durch „betrügerische Klicks“, und Sie haben Ihre Ausschlussliste. Schließen Sie die Mobilfunk-IP dauerhaft aus, hinter der zufällig ein Betrüger saß, und Sie haben eine unbekannte Zahl echter mobiler Käufer aus jeder Kampagne im Konto gelöscht: lautlos, ohne Bericht, für immer. Es ist die Werbebudget-Version des Problems falscher Ablehnungen, das wir in anonymisierten Traffic erkennen, ohne echte Kunden zu blockieren behandelt haben.

Eine Ausschlussliste kennt kein „wahrscheinlich schlecht“. Sie kennt nur „gesperrt“. Das ist der fatale Konstruktionsfehler, und deshalb ist die Antwort keine längere Liste.

Der Perspektivwechsel: Die IP ist ein Beleg, kein Urteil

Hören Sie auf zu fragen „Steht diese Adresse auf meiner Sperrliste?“, und fragen Sie stattdessen „Aus welcher Art von Netzwerk kommt dieser Klick, und wie sehr vertraue ich ihm?“

Auf diese Frage gibt es eine reichhaltige Antwort, denn eine IP-Adresse trägt viel Kontext, der mit ihrer Reputationshistorie nichts zu tun hat. Dieser Kontext ist für einen Betrüger schwer zu fälschen, weil er eine Eigenschaft der Infrastruktur ist, die er sich leiht, und nicht der Anfrage, die er sendet.

Die Branche hat das bereits formalisiert, und genau diesen Teil übersehen die meisten PPC-Ratschläge.

Was die Standards bereits verlangen

Die IVT Detection and Filtration Standards des Media Rating Council teilen ungültigen Traffic in zwei Stufen, und diese Aufteilung entspricht fast genau dem, wie schwer die IP zu lesen ist. General Invalid Traffic (GIVT) wird „durch die Anwendung von Listen oder mit anderen standardisierten Parameterprüfungen“ erfasst, und die erste Kategorie, die der MRC darunter aufführt, ist bekannter ungültiger Rechenzentrums-Traffic. Sophisticated Invalid Traffic (SIVT) ist die schwierigere Stufe, die „fortgeschrittene Analysen, Bestätigung und Abstimmung über mehrere Punkte, erheblichen menschlichen Eingriff“ erfordert, und ungültiger Proxy-Traffic gehört dorthin. Jede Kategorie beider Stufen gehen wir neben den neun von Google selbst durch und sagen, welche davon eine IP-Abfrage sehen kann, in GIVT vs. SIVT: Googles Kategorien ungültigen Traffics.

Die Certified-Against-Fraud-Richtlinien der TAG machen die Rechenzentrumshälfte verpflichtend: Ein zertifiziertes Unternehmen „muss Rechenzentrums-IP-Threat-Filtering bei allen monetarisierbaren Transaktionen umsetzen (einschließlich Impressionen, Klicks, Conversions usw.)“, und Abschnitt 4.8.a ergänzt, dass die alleinige Nutzung der TAG Data Center IP List nicht ausreicht. Daraus folgen für einen Werbetreibenden zwei Dinge. Wenn die Standardisierungsgremien Rechenzentrums-IP-Filterung als Compliance-Untergrenze behandeln, liegt ein Werbetreibender, der sie nicht umsetzt, unter dieser Grenze. Und die Standards sagen dasselbe wie dieser Artikel: Listen erledigen die einfache Stufe, und die schwierige Stufe braucht Analyse.

Die IP-Signale, die Klickbetrug erkennen

Hier ist, was Sie aus der IP lesen sollten, grob geordnet nach Signal-Rausch-Verhältnis für bezahlten Traffic. Für dieselben Flags, angewendet auf Bots jenseits von Anzeigenklicks, und dafür, wo jedes davon blind wird, siehe welche IP-Signale Bots identifizieren.

SignalWas es erfasstWie Sie es behandeln
Verbindungstyp / ASN-Typ ist HostingBots, Skripte, Scraper, in der Cloud betriebene Klickfarmen. Die erste GIVT-Kategorie des MRC.Stark negativ. Menschen kaufen nicht aus AWS heraus ein.
Gefälschter CrawlerTraffic, der sich als Googlebot/GPTBot ausgibt, aber von einer IP außerhalb der veröffentlichten Bereiche des Betreibers kommt.Stark negativ. Unsere API prüft die IP gegen die veröffentlichten Bereiche des Betreibers (`threat.crawler.verified`); Ihr Code vergleicht das mit dem User-Agent, den die Anfrage angibt.
Flags für Scanner / Botnet / SpammerInfrastruktur mit aktivem Missbrauchseintrag in öffentlichen Threat-Feeds.Stark negativ, wenn aktuell. Nach last_seen gewichten, nicht nach bloßer Listung.
Öffentlicher Proxy / Tor / VPNBewusste Verschleierung der Herkunft.Für sich allein schwach, denn viele echte Käufer nutzen ein VPN. Gewichten, nie allein deshalb sperren.
Residential / mobiler ProxyDer teure Betrug: Traffic der BADBOX-Klasse im Gewand eines echten Privatkunden-ISP.Die schwierige Stufe (SIVT). Eine einzelne IP-Abfrage kann ihn nicht erfassen: GeoIPHub bewertet diese Adressen als Privatanschluss. Nutzen Sie Klickgeschwindigkeit, Conversion-Raten und einen spezialisierten Anbieter.
BogonNicht zugewiesener oder reservierter Adressraum, aus dem legitimerweise kein Klick stammen kann.Stark negativ. Ein Klick aus einem Bogon ist defekt oder gefälscht.
CGNAT / geteilte AdresseMobilfunknutzer und Nutzer geteilter Anschlüsse hinter einer öffentlichen IP.Entlastend, nicht belastend. Deckeln Sie hier das Risiko, sonst bestrafen Sie echte Menschen.

Beachten Sie die Richtung der letzten Zeile. Ein gutes Scoring-Modell addiert nicht nur Punkte. Es zieht auch welche ab. Ein Privatkunden-ISP und ein verifizierter Crawler sind Gründe, nachsichtiger zu sein, ein Carrier-Grade-NAT-Bereich bekommt seinen Score gedeckelt, und ein System ohne diese Mechanismen zermahlt Ihre echte mobile Zielgruppe zu Falsch-Positiven. Dieses Prinzip wird Grund für Grund in den entlastenden Gründen hinter einem Risikoscore erläutert, und es ist in der Werbung wichtiger als fast überall sonst, denn bei bezahltem Traffic ist ein Falsch-Positiv kein blockierter Login. Es ist ein Kunde, für dessen Gewinnung Sie bezahlt haben und den Sie dann weggeworfen haben.

Alles in einem Aufruf lesen

Konkret ist das eine Abfrage gegen die IP, die den Klick ausgelöst hat, bevor Sie entscheiden, was er wert war. Dieselbe Prüfung können Sie von Hand im kostenlosen IP-Fraud-Score-Checker durchführen.

GeoIPHub API
curl -H "x-api-key: YOUR_API_KEY" \ https://api.geoiphub.com/v1/lookup/45.33.32.156

Die Felder, die für einen bezahlten Klick zählen, verteilen sich auf vier Gruppen der Antwort:

GeoIPHub API
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${clickIp}`, { headers: { "x-api-key": process.env.GEOIPHUB_API_KEY }, }); const ip = await res.json(); ip.asn.asn_type; // "hosting": the MRC's first GIVT category ip.asn.connection_type; // "datacenter" | "residential" | "mobile" ip.detection.is_hosting; // true for cloud and hosting ranges ip.threat.crawler.verified; // true only inside an operator's published ranges; compare with the User-Agent in your code ip.threat.is_cgnat; // shared address: a reason for leniency, not suspicion ip.scoring.fraud_score; // 0 to 100 composite ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block" ip.scoring.detection_methods; // exactly which signals fired: your audit trail

Ein Hosting-Klick bekommt einen niedrigen Score, ein Tor-Klick 100

Der Score allein wertet einen Rechenzentrums-Klick nicht für Sie ab, und zwei reale Abfragen zeigen, warum Sie trotzdem die Felder lesen. Wir haben beide Adressen am 13.10.2026 abgefragt und am 14.10.2026 mit denselben Werten erneut abgefragt; der erste Block ist die Antwort vom 14.10.2026. Die Ergebnisse ändern sich, wenn sich Bereiche verschieben. Die erste ist die Hosting-IP aus der Anfrage oben: scanme.nmap.org, der öffentliche Testhost, den Nmap auf Akamai Connected Cloud in Fremont, Kalifornien, betreibt. Er hat auf niemandes Anzeige geklickt. Er steht stellvertretend für jeden gewöhnlichen Cloud-Server:

GeoIPHub API
{ "ip": "45.33.32.156", "asn": { "asn": 63949, "org": "AKAMAI-LINODE-AP - Akamai Connected Cloud", "asn_type": "hosting", "connection_type": "datacenter" }, "detection": { "is_vpn": false, "is_tor": false, "is_hosting": true }, "threat": { "is_cgnat": false, "crawler": { "verified": false } }, "scoring": { "fraud_score": 10, "recommended_action": "allow", "detection_methods": ["datacenter_ip"] } }

Die zweite ist ein Tor-Exit in Hamburg:

GeoIPHub API
{ "ip": "185.220.101.1", "asn": { "asn": 60729, "org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit", "asn_type": "hosting", "connection_type": "datacenter" }, "detection": { "is_tor": true, "is_hosting": true, "anonymity_level": "high" }, "threat": { "is_spammer": true, "threat_types": ["spammer", "tor"] }, "scoring": { "fraud_score": 100, "recommended_action": "block", "detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"] } }

Der Cloud-Server bekommt einen Score von 10 und allow, mit datacenter_ip als einziger Methode. Das ist Absicht: Der allgemeine Score ist für jede Art von Traffic gebaut, einschließlich API-Aufrufen und ausgehendem Unternehmens-Traffic, wo eine Hosting-Adresse allein kein Betrug ist. Ein bezahlter Klick ist anders, denn ein Käufer klickt Ihre Anzeige nicht von einem Server aus an. Wenden Sie bei Anzeigen-Traffic also Ihre eigene Regel auf asn.connection_type oder detection.is_hosting an, statt darauf zu warten, dass der Score block sagt. Der Tor-Exit braucht keine zusätzliche Regel: Er bekommt 100 und block, und detection_methods nennt vier unabhängige Gründe (Tor-Exit, ein Rechenzentrumsbereich auf einer Sperrliste, Tor-typisches Reverse DNS, ein bekannter Spammer).

Ein VPN liegt dazwischen. Bis zu dieser Aktualisierung nutzte dieser Beitrag 45.83.220.7 als einfaches Hosting-Beispiel. Am 13.10.2026 benennt die API sie als Mullvad-Server und bewertet sie mit 46, review, mit known_vpn_server und datacenter_ip. Das ist genau die Gewichtung, die die Signaltabelle verlangt: Ein VPN-Klick ist ein Grund, genauer hinzusehen, nicht zu sperren, und zugleich eine Erinnerung, jede Abfrage erneut auszuführen, bevor Sie einem alten Ergebnis vertrauen.

Dieses Feld ist es, was aus einer Blackbox etwas macht, das Sie in einer Prüfung der Medienqualität verteidigen können. Wenn ein Klick abgewertet wird, können Sie genau sagen, warum: Rechenzentrumsverbindung bei einem bezahlten Klick oder Tor-Exit plus Spam-Listung. „Der Score hat es gesagt“ ist keine Antwort, die irgendjemand akzeptieren sollte, am allerwenigsten von den eigenen Betrugswerkzeugen.

Schützen Sie das Gebotssignal, nicht nur den Klick

Das ist der Teil, der die Wirtschaftlichkeit verändert, und genau hier investieren Werbetreibende durchweg zu wenig.

Einen betrügerischen Klick zu blockieren spart Ihnen die Kosten dieses Klicks. Eine betrügerische Conversion zu verhindern bewahrt Sie vor etwas erheblich Teurerem: Ihrem Gebotsalgorithmus beizubringen, mehr Betrug einzukaufen.

Smart Bidding und die Optimierung von Meta funktionieren beide, indem sie lernen, welche Signalcluster Conversions erzeugen, und gezielter darauf bieten. Speisen Sie eine gefälschte Conversion in diese Schleife ein, und Sie haben nicht einen Klick verloren. Sie haben dafür bezahlt, das Modell darauf zu trainieren, mehr Traffic zu suchen, der genau so aussieht wie der Traffic, der Sie gerade betrogen hat. Das System wird ihn begeistert verfolgen und hervorragende Ergebnisse melden, denn nach seinem eigenen Maßstab ist es erfolgreich.

Um genau zu sein, was hier dokumentiert ist und was nicht: Google veröffentlicht keine Aussage, dass betrügerische Conversions automatisierte Gebote vergiften. Was Googles Smart-Bidding-Dokumentation sagt, ist: „Wenn die Daten des Conversion-Trackings ungenau sind, können Schwankungen bei Ihrem Volumen, Ihrem CPA oder Ihrem ROAS auftreten“, wobei zugleich festgehalten wird, dass Smart Bidding auf ungenaue Daten reagieren und sich anpassen kann. Die stärkere Behauptung oben ist ein begründetes Argument aus der Funktionsweise der Optimierung, kein Zitat von Google, und Sie sollten sie auch so behandeln. Es ist allerdings ein naheliegendes Argument: Ein Optimierer maximiert, was auch immer er zählen soll.

Die praktische Kontrolle liegt serverseitig, und es ist die eine Stelle, an der Meta Ihnen mehr Kontrolle gibt als Google statt weniger. Weil die Conversions API ein Server-zu-Server-Kanal ist, entscheidet Ihr Server, welche Events überhaupt an Meta gesendet werden. Eine IP-Abfrage zum Zeitpunkt der Conversion (nicht zum Zeitpunkt des Klicks) erlaubt es Ihnen, das Event vollständig zurückzuhalten, wenn der „Kunde“ eine Rechenzentrumsadresse ist. Meta lernt nie, mehr davon zu wollen. Dasselbe gilt für Googles Offline-Conversion-Importe.

Bewerten Sie den Klick, um das Budget zu schützen. Filtern Sie die Conversion, um das Modell zu schützen.

Die Ausschlussliste hat weiterhin eine kleine Aufgabe

Nichts davon bedeutet, dass Sie die Liste leeren sollten. Es bedeutet, dass Sie aufhören sollten, sie als Strategie zu behandeln.

Eine Ausschlussliste ist das richtige Werkzeug für genau eine Situation: eine kleine Zahl stabiler Wiederholungstäter, bei denen Sie sich sehr sicher sind: der Bürobereich eines Wettbewerbers, ein Scraper auf einem festen Host, eine interne IP, die Ihr eigenes Budget verbrennt. Das sind eine Handvoll Einträge, sie rotieren nicht, und sie kommen nie auch nur in die Nähe von 500.

Alles andere (alles, was rotiert, alles Geteilte, alles, bei dem Sie sich nicht ganz sicher sind) gehört in den Score, wo es gewichtet, abgeschwächt, mit anderen Signalen abgeglichen und morgen rückgängig gemacht werden kann, wenn sich die Beweislage ändert. Sperren sind dauerhaft und binär. Betrug ist weder das eine noch das andere.

Wo das in der Produktion läuft

Ich baue das auf beiden Seiten der Leitung, und das sollte ich offen sagen. GeoIPHub ist die oben beschriebene IP-Intelligence-Ebene. ClickFortify ist unser darauf aufbauendes Produkt gegen Klickbetrug. Es bewertet Live-Anzeigenklicks bei Google und Meta, synchronisiert die kleine Menge wirklich sicherer Wiederholungstäter in die IP-Ausschlüsse von Google Ads und filtert verdächtige Conversions, bevor sie Metas CAPI und Googles Smart Bidding erreichen.

Die Architektur ist das Argument dieses Artikels, konkret umgesetzt: Die IP-Intelligence übernimmt das Scoring, und die Ausschlussliste wird nur für den schmalen Ausschnitt von Fällen genutzt, in denen eine dauerhafte Sperre tatsächlich die richtige Reaktion ist. Wenn Sie diese Logik lieber selbst bauen, ist die API oben dieselbe, die es aufruft.

Sechs Änderungen vor Ihrer nächsten Kampagne

  • Protokollieren Sie die IP bei jedem Anzeigenklick. Was Sie nicht erfasst haben, können Sie nicht bewerten. Speichern Sie die Adresse beim Aufruf der Landingpage, zusammen mit der gclid/fbclid.
  • Bewerten statt sperren. Schicken Sie jede Klick-IP durch eine Abfrage und speichern Sie den Score mit der Sitzung, damit Sie Ihre Berichte rückwirkend nach Risikobereichen segmentieren können.
  • Beginnen Sie mit der Rechenzentrums-Untergrenze. Traffic aus Hosting-ASNs ist die GIVT-Grundlage des MRC und das Signal mit der höchsten Sicherheit und den wenigsten Falsch-Positiven, das Sie haben. Es ist der günstigste verfügbare Gewinn.
  • Filtern Sie Conversions serverseitig. Halten Sie Conversion-Events aus CAPI und Offline-Importen zurück, wenn die IP ein hohes Risiko hat. Das schützt das Gebotsmodell, und das ist mehr wert als der Klick.
  • Deckeln Sie das Risiko bei geteilten IPs. Stellen Sie sicher, dass CGNAT- und Mobilfunkbereiche als geteilt behandelt werden, nicht als schlecht. Das ist die Leitplanke, die verhindert, dass aus Betrugsprävention Umsatzprävention wird.
  • Halten Sie die Ausschlussliste kurz. Reservieren Sie sie für stabile, sichere Wiederholungstäter und legen Sie sie auf Kontoebene an, damit sie auch Performance Max abdeckt.

Der Klick hat Ihnen bereits gesagt, woher er kam. Die einzige Frage ist, ob Sie genau genug hingehört haben, um mehr als eine Adresse zu hören.

Häufig gestellte Fragen

Wie erkennt man Klickbetrug per IP-Adresse?

Nicht durch Abgleich mit einer Sperrliste, sondern indem man das Netzwerk bewertet, aus dem der Klick kam. Die aussagekräftigsten Felder sind der Verbindungstyp (ein Klick aus einer Hosting- oder Rechenzentrums-ASN ist kein Käufer), Anonymisierungs-Flags (VPN, öffentlicher Proxy, Tor), Belege aus Threat-Feeds (Botnet, Scanner, Spammer) mit Zeitstempel zur Aktualität und die Crawler-Verifizierung (eine Anfrage, die sich als Googlebot ausgibt, aber von einer IP außerhalb der von Google veröffentlichten Bereiche kommt, besteht die Verifizierung nicht; Ihr Code vergleicht diese Behauptung mit dem verifizierten Feld der API). Jedes davon ist eine gewichtete Eingabe für einen Risikoscore, und auf den Score, nicht auf die rohe IP, reagieren Sie.

Kann man Klickbetrug bei Meta Ads per IP blockieren?

Nein. Der Meta-Werbeanzeigenmanager bietet überhaupt keine Funktion zum Ausschließen von IPs, weshalb jedes Drittanbieter-Tool gegen Klickbetrug bei Meta verdächtige Nutzer in einen Ausschluss per Custom Audience schiebt, statt eine Adresse zu sperren. Bei Meta ist der Hebel nicht der Klick, sondern die Conversions API: Weil CAPI serverseitig läuft, entscheidet Ihr Server, welche Conversion-Events an Meta gesendet werden, sodass eine Conversion von einer Rechenzentrums-IP einfach zurückgehalten werden kann.

Filtert Google ungültige Klicks nicht schon für mich?

Google filtert einen Teil davon und sagt klar, wie. In der Google-Ads-Hilfe heißt es, dass ungültiger Traffic, der vor Monatsende erkannt wird, „automatisch aus Ihrer Abrechnung und Ihren Kampagnenberichten entfernt wird, sodass keine Erstattungen nötig sind“, und ungültiger Traffic, der nach der Abrechnung gefunden wird, kommt als „Gutschriften in Form einer Abrechnungskorrektur“ zurück. Das schützt Ihre Rechnung, nicht Ihre Kampagnenstrategie. Untersuchungen decken nur die letzten 60 Tage ab, und laut Google „kann eine Untersuchung nicht bestätigen, ob bestimmte Klicks als gültig oder ungültig eingestuft wurden“, sodass Sie den Betrug nicht auf die Keywords, Placements oder Zielgruppen zurückführen können, die ihn anziehen.

Warum ist es gefährlich, eine betrügerische IP-Adresse zu sperren?

Weil im heutigen Internet eine öffentliche Adresse routinemäßig von vielen nicht zusammenhängenden Personen geteilt wird. RFC 6269 hat diese Folge schon vor Jahren dokumentiert: Wenn ein Server eine geteilte Adresse bestraft, kann ein missbräuchlicher Nutzer andere Nutzer aussperren, die nichts falsch gemacht haben. Carrier-Grade NAT bündelt Hunderte oder Tausende Mobilfunkkunden hinter einer einzigen öffentlichen IP, sodass ein dauerhafter Ausschluss, der auf einen Betrüger zielt, unbemerkt einen Teil Ihrer echten mobilen Zielgruppe aus jeder Kampagne löschen kann.

Gilt Rechenzentrums-Traffic offiziell als ungültiger Traffic?

Bekannter ungültiger Rechenzentrums-Traffic ja, aber nicht jeder Rechenzentrums-Traffic. Die IVT Detection and Filtration Standards des Media Rating Council führen „bekannten ungültigen Rechenzentrums-Traffic“ als erste Kategorie des General Invalid Traffic, nehmen aber legitimes Surfen über virtuelle Maschinen und Routing-Artefakte echter Nutzer aus, und der MRC verlangt als Grundlage die Filterung von Rechenzentrums-Traffic der drei größten Hosting-Anbieter (Amazon AWS, Google und Microsoft). Die Certified-Against-Fraud-Richtlinien der TAG gehen weiter und verpflichten zertifizierte Unternehmen, Rechenzentrums-IP-Threat-Filtering bei allen monetarisierbaren Transaktionen umzusetzen.

Verfasst von

GeoIPHub-Team

Das Team hinter der GeoIPHub-API

Verfasst vom GeoIPHub-Team, den Menschen, die die GeoIPHub-API für IP-Intelligence und ihren Scanner entwickeln. Entwürfe entstehen mit KI-Unterstützung und werden vom Team redigiert; API-Beispiele sind echte Abfragen gegen die Live-API, sofern nicht als illustrativ gekennzeichnet.

Artikel teilen
Weitere Artikel

Verwandte Beiträge