Every advertiser discovers click fraud the same way. The spend graph looks normal, the click graph looks great, and the conversion graph looks like a flatline. You open the raw logs, sort by IP, and there it is — the same address, forty times, no conversions, all inside a single afternoon.
So you do the obvious thing. You paste that address into the IP exclusion list.
It works, briefly. Then the clicks come back from a different address, and another, and another, and somewhere around the thirtieth entry in your exclusion list you start to suspect you are playing a game you cannot win. You are. The exclusion list is not a weak version of the right tool. It is the wrong tool, and it is worth understanding exactly why before we look at what replaces it.
What the Ad Platforms Actually Do About Invalid Clicks
Start with the thing most advertisers assume is already handled.
Google does filter invalid traffic, and it says so plainly. Its invalid traffic documentation defines invalid traffic as "clicks and impressions on ads that aren't a result of genuine user interest, including intentionally fraudulent traffic and accidental or duplicate clicks," and states that "when Google determines that clicks are invalid, we try to automatically filter them from your reports and payments so that you're not charged for those clicks."
That is real, and it is not nothing. But read what it protects. It protects the invoice. Google's filtering decides whether you get billed for a click — it does not tell you which campaign, keyword, placement or audience is attracting fraud, it does not stop the traffic from polluting your analytics, and it does not stop a fake conversion from reaching your bidding model. Google is also specific that you "won't receive refunds for invalid traffic": when detection happens after invoicing you get a credit line labelled Invalid Activity, not your money back.
Meta's equivalent disclosure is thinner still. Its invalid-click page says Meta "takes several steps to reduce the risk of abuse from invalid clicks," performs a manual review when suspicious activity is detected or reported, and will not charge you for clicks determined to be invalid. That is the whole commitment.
Both platforms are grading their own homework, on the one metric where their interests and yours diverge. Whatever is left after their filter is your problem — and your problem is measured in strategy, not just in dollars.
The Four Ways an IP Exclusion List Fails
- It runs out of room. Google Ads permits 500 IP address exclusions per campaign — and that is per campaign, not a shared pool you can spend where it matters most.
- It cannot express a network. There is no CIDR support. The only range syntax is a single trailing asterisk replacing the last octet (
203.0.113.*), which gets you a /24 and nothing else. You cannot exclude a hosting provider's /19. You cannot exclude an ASN at all. - It has holes in the campaign types you care about. Campaign-level IP exclusions are unavailable for Performance Max, video, App and Smart Display campaigns. (Account-level exclusions do apply across all campaign types, Performance Max included — so if you use exclusions at all, set them at the account level.)
- It does not exist on Meta. Meta Ads Manager has no IP exclusion feature. Every third-party Meta click-fraud tool works around this by pushing suspect users into a Custom Audience exclusion, which is a fundamentally different and blunter mechanism.
Those are the mechanical limits. The strategic limit is worse.
The addresses rotate faster than you can type
The professional end of ad fraud does not operate from a fixed address. It rents residential IPs by the million.
In 2025 Google sued the operators of the BADBOX 2.0 botnet, which had compromised more than 10 million uncertified Android devices. Read what a single one of those infected devices was used for: residential proxy node creation, programmatic ad fraud, hidden ads, and click fraud — all of it, from one compromised TV box in someone's living room. HUMAN Security's PROXYLIB research found the supply chain feeding it: Android apps, published on Google Play, quietly enrolling their users' phones as proxy exit nodes.
This is the same infrastructure we wrote about in why there are so many residential proxies in your traffic. For an advertiser it means the fraudulent click that just cost you $14 arrived from a real home broadband connection in your target city, belonging to a real person who has no idea their router is for rent. There is no address to ban. There are ten million of them, and tomorrow there will be different ten million.
And banning them hits real customers
Here is the part that quietly costs more than the fraud does.
One public IP address does not mean one person any more. Carrier-grade NAT puts hundreds or thousands of mobile subscribers behind a single public address, and RFC 6269 — the IETF's assessment of what address sharing breaks — called the consequence years ago: when a server penalises a shared address, "one user who fails a number of login attempts may block out other users who have not made any previous attempts."
Swap "login attempts" for "fraudulent clicks" and you have your exclusion list. Permanently exclude the mobile carrier IP that one fraudster happened to be behind, and you have deleted an unknown number of real mobile shoppers from every campaign in the account — silently, with no report, forever. It is the ad-spend version of the false-decline problem we covered in detecting anonymized traffic without blocking real customers.
An exclusion list has no concept of "probably bad." It only has "banned." That is the fatal design flaw, and it is why the answer is not a longer list.
The Reframe: the IP Is Evidence, Not a Verdict
Stop asking "is this address on my bad list?" and start asking "what kind of network is this click coming from, and how much do I trust it?"
That question has a rich answer, because an IP address carries a great deal of context that has nothing to do with its reputation history — context a fraudster cannot easily fake, because it is a property of the infrastructure they are borrowing rather than of the request they are sending.
The industry already formalised this, which is the part most PPC advice misses.
What the Standards Already Require
The Media Rating Council's IVT Detection and Filtration Standards split invalid traffic into two tiers, and the split maps almost perfectly onto how hard the IP is to read.
General Invalid Traffic (GIVT) is, in the MRC's words, "traffic identified through routine means of filtration executed through application of lists or with other standardized parameter checks." The very first category the MRC lists under it is "known invalid data-center traffic." Not bots-in-general. Datacenter traffic, named first. The MRC goes on to require, as a floor, "filtration of invalid data-center traffic originating from IPs associated to the three largest known hosting entities: Amazon AWS, Google and Microsoft."
Sophisticated Invalid Traffic (SIVT) is the harder tier — "more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention." Proxy traffic lives here, explicitly: "invalid proxy traffic (originating from an intermediary proxy device that exists to manipulate traffic counts or create/pass-on invalid traffic)."
TAG's Certified Against Fraud guidelines then make the datacenter half mandatory: any certified company "must implement data center IP threat filtering across all monetizable transactions (including impressions, clicks, conversions, etc.)." And section 4.8.a contains the line every vendor blog gets backwards — companies "whose only means of employing data center IP filtering is use of the TAG Data Center IP List will not be considered compliant." The industry's own shared list is, by its own authors' admission, a starting point and not a solution.
Two things follow for an advertiser. First, if the ad industry's standards bodies consider datacenter IP filtering a compliance floor, an advertiser who is not doing it is below the floor. Second, the standards are telling you the same thing this article is: lists handle the easy tier, and the hard tier needs analysis. (We mapped this taxonomy in more detail when covering how to verify a crawler by IP, where the same GIVT/SIVT line separates a declared bot you can safely allow from one impersonating it.)
The Signals That Actually Catch Click Fraud
Here is what to read from the IP, roughly in order of signal-to-noise for paid traffic.
Note the direction of the last row. A good scoring model does not only add points — it subtracts them. A residential ISP, a verified crawler, a carrier-grade NAT range: these are reasons to be more forgiving, and a system that lacks them will grind your real mobile audience into false positives. That principle is the whole subject of how IP risk scoring works, and it matters more in advertising than almost anywhere else, because on paid traffic a false positive is not a blocked login — it is a customer you paid to acquire and then threw away.
Reading It in One Call
Concretely, this is one lookup against the IP that fired the click, before you decide what it was worth.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/45.83.220.7
The fields that matter for a paid click sit across four groups of the response:
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
ip.detection.is_residential_proxy; // the SIVT tier — inferred, not observed
ip.threat.crawler.spoofed; // claims to be a crawler, isn't in the official ranges
ip.threat.is_cgnat; // shared address — a reason for leniency, not suspicion
ip.threat.blocklist_count; // corroboration across feeds
ip.detection.last_seen; // recency of the evidence — old listings mean little
ip.scoring.fraud_score; // 0–100 composite
ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block"
ip.scoring.detection_methods; // exactly which signals fired — your audit trail
detection_methods is the field that turns this from a black box into something you can defend in a media-quality review. When a click is discounted, you can say precisely why: hosting ASN, spoofed crawler identity, listed on three feeds within the last 24 hours. "The score said so" is not an answer anyone should accept — least of all from their own fraud tooling.
Protect the Bid Signal, Not Just the Click
This is the part that changes the economics, and it is where advertisers consistently under-invest.
Blocking a fraudulent click saves you the cost of that click. Preventing a fraudulent conversion saves you from something considerably more expensive: teaching your bidding algorithm to buy more fraud.
Smart Bidding and Meta's optimisation both work by learning which signal clusters produce conversions and bidding harder toward them. Feed a fake conversion into that loop and you have not lost one click — you have paid to train the model to go find more traffic that looks exactly like the traffic that just defrauded you. The system will pursue it enthusiastically and report excellent results, because by its own measure it is succeeding.
To be precise about what is and is not documented here: Google does not publish a statement that fraudulent conversions poison automated bidding. What Google's Smart Bidding documentation does say is that "if the conversion tracking data are inaccurate, you may see fluctuations in your volume, CPA or ROAS" — while also noting that Smart Bidding can react and adjust to inaccurate data. The stronger claim above is a reasoned argument from how optimisation works, not a quote from Google, and you should treat it as such. It is, however, a straightforward one: an optimiser maximises whatever it is told to count.
The practical control is server-side, and it is the one place where Meta gives you more leverage than Google rather than less. Because the Conversions API is a server-to-server channel, your server decides which events are ever sent to Meta. An IP lookup at the moment of conversion — not at the moment of the click — lets you withhold the event entirely when the "customer" is a datacenter address. Meta never learns to want more of it. The same applies to Google's offline conversion imports.
Score the click to protect the budget. Filter the conversion to protect the model.
The Exclusion List Still Has a Small Job
None of this means you should empty the list. It means you should stop treating it as the strategy.
An exclusion list is the right tool for exactly one situation: a small number of high-confidence, stable, repeat offenders — a competitor's office range, a scraper on a fixed host, an internal IP burning your own budget. That is a handful of entries, they do not rotate, and they will never come close to 500.
Everything else — anything that rotates, anything shared, anything you are less than certain about — belongs in the score, where it can be weighted, decayed, corroborated against other signals, and reversed tomorrow when the evidence changes. Bans are permanent and binary. Fraud is neither.
Where This Runs in Production
I build this on both sides of the wire, and it is worth being open about that. GeoIPHub is the IP intelligence layer described above. ClickFortify is our click-fraud product built on top of it — it scores live ad clicks on Google and Meta, syncs the small set of genuinely high-confidence offenders into Google Ads IP exclusions, and filters suspect conversions before they reach Meta's CAPI and Google's Smart Bidding.
The architecture is the argument of this article, made concrete: the IP intelligence does the scoring, and the exclusion list is used only for the narrow slice of cases where a permanent ban is actually the correct response. If you would rather build that logic yourself, the API above is the same one it calls.
Getting Started This Week
- Log the IP on every ad click. You cannot score what you did not record. Capture the address at the landing-page hit, alongside the
gclid/fbclid. - Score, don't ban. Run each click IP through a lookup and store the score with the session, so you can segment your reporting by risk band retroactively.
- Start with the datacenter floor. Hosting-ASN traffic is the MRC's GIVT baseline and the highest-confidence, lowest-false-positive signal you have. It is the cheapest win available.
- Filter conversions server-side. Withhold conversion events from CAPI and offline imports when the IP is high-risk. This protects the bidding model, which is worth more than the click.
- Cap the risk on shared IPs. Make sure CGNAT and mobile carrier ranges are treated as shared, not as bad. This is the guardrail that stops fraud prevention from becoming revenue prevention.
- Keep the exclusion list short. Reserve it for stable, certain, repeat offenders — and set it at the account level so it covers Performance Max too.
The click already told you where it came from. The only question is whether you were listening carefully enough to hear more than an address.
Start Scoring Every IP in Real Time
GeoIPHub gives fraud, security, and engineering teams a single API for IP geolocation, VPN & proxy detection, threat intelligence, and an explainable 0–100 risk score.
Get Your Free API Key
Sign up in minutes — no credit card required. Upgrade only when you need more volume.
Frequently Asked Questions
How do you detect click fraud by IP address?
Not by matching against a ban list — by scoring the network the click came from. The high-signal fields are the connection type (a click from a hosting/datacenter ASN is not a shopper), anonymizer flags (VPN, public proxy, Tor, residential proxy), threat-feed evidence (botnet, scanner, spammer) with a recency timestamp, and crawler verification (a request claiming to be Googlebot from an IP outside Google's published ranges is spoofed). Each of those is a weighted input to a risk score, and the score — not the raw IP — is what you act on.
How many IP addresses can you exclude in Google Ads?
Google Ads allows up to 500 IP address exclusions per campaign. There is no CIDR support: the only range syntax is a single trailing asterisk that replaces the last octet, so 203.0.113.* excludes a /24 and nothing more granular. Campaign-level IP exclusions are also unavailable for Performance Max, video, App and Smart Display campaigns, though account-level exclusions do apply across all campaign types including Performance Max.
Can you block click fraud on Meta Ads by IP?
No. Meta Ads Manager provides no IP exclusion feature at all — which is why every third-party Meta click-fraud tool works by pushing suspect users into a Custom Audience exclusion instead of blocking an address. On Meta, the leverage is not the click, it is the Conversions API: because CAPI is server-side, your server decides which conversion events get sent to Meta, so a conversion from a datacenter IP can simply be withheld.
Doesn't Google already filter invalid clicks for me?
Google filters some of them, and it is explicit about the limits. Google Ads Help states that when Google determines clicks are invalid it tries to automatically filter them from reports and payments so you are not charged. But that filtering protects Google's billing, not your campaign strategy — and Google is equally explicit that you do not receive refunds for invalid traffic, only credits labelled 'Invalid Activity' when detection happens after invoicing. It also cannot tell you which of your keywords, placements or audiences are attracting the fraud.
Why is blocking a fraudulent IP address dangerous?
Because on the modern internet one public address is routinely shared by many unrelated people. RFC 6269 documented this consequence years ago: when a server penalises a shared address, one abusive user can block out other users who did nothing wrong. Carrier-grade NAT puts hundreds or thousands of mobile subscribers behind a single public IP, so a permanent exclusion aimed at one fraudster can quietly delete a slice of your real mobile audience from every campaign.
Is datacenter traffic officially considered invalid traffic?
Yes. The Media Rating Council's IVT Detection and Filtration Standards list 'known invalid data-center traffic' as the first category of General Invalid Traffic, and the MRC requires filtration of data-center traffic from the three largest hosting entities — Amazon AWS, Google and Microsoft — as a baseline. TAG's Certified Against Fraud guidelines go further and require certified companies to implement datacenter IP threat filtering across all monetizable transactions.
