The money leak nobody put on the invoice

Every paid-search and paid-social budget has a line item that never appears on the invoice: the clicks you paid for that were never a real prospect. A competitor's script clicking your top keyword to exhaust your daily budget by 10am. A publisher inflating their payout with a rack of phones. A scraper that follows your ad to price-check your landing page. The platform bills you for some of it, refunds some of it, and tells you very little about the rest.

This is click fraud — and more broadly invalid traffic (IVT) — and it is one of the most expensive problems in digital marketing precisely because it is invisible by default. Juniper Research has repeatedly projected advertiser losses to ad fraud in the order of $100bn a year, and the Association of National Advertisers has run multi-year bot-fraud studies showing the problem is structural rather than occasional.

The good news: click fraud is, at its core, an IP-intelligence problem. The clicks come from somewhere, and where they come from is one of the strongest tells you have. This guide covers what invalid traffic actually is, why the ad platforms don't fully protect you, and how to build an IP-level filter that stops paying for it.

TL;DR

• Invalid traffic (IVT) is the umbrella term; click fraud is the deliberate, malicious subset. The industry splits IVT into GIVT (easy-to-filter known bots / data-center) and SIVT (sophisticated: residential proxies, click farms, human fraud).
• Google and Meta filter GIVT automatically, but are deliberately conservative — SIVT routinely gets billed, and platform filtering protects the click, not your landing page or signup.
• The strongest single signal is the click's origin IP: data-center, VPN, proxy, Tor, and repeat-velocity from one IP are all high-confidence invalid-traffic indicators.
• Don't rely on a static IP blocklist. Google Ads caps exclusions at 500 IPs/campaign; real operations rotate through thousands. Use a risk score per click and keep the static list as a backstop.
• Instrument your own landing pages to measure your real number — most advertisers have never actually counted.

What "invalid traffic" actually means

Ad platforms and measurement bodies converged on a shared vocabulary, and it's worth knowing because it tells you exactly where your exposure is. The Media Rating Council's Invalid Traffic Detection guidelines split IVT into two tiers:

General Invalid Traffic (GIVT) is the traffic that can be identified through routine, list-based filtration: known data-center IP ranges, declared bots and crawlers, and activity that fails simple validity checks. This is the easy tier — it's filterable with published lists, and it's mostly what the platforms catch and refund.

Sophisticated Invalid Traffic (SIVT) is everything that needs more than a list: bots running through residential proxy networks to look like real households, click farms of real devices in real hands, hijacked devices, and incentivised or misappropriated clicks. SIVT is where the money actually leaks, because by design it looks like a real user at the moment of the click.

The reason this matters for your strategy: GIVT is largely a solved problem you're already (mostly) protected from. Your job is the SIVT tier, and SIVT is precisely where origin-IP intelligence earns its keep — because even a residential-proxy bot has to egress *somewhere*, and that somewhere is increasingly detectable.

Why the platforms don't fully protect you

Google's Ad Traffic Quality team does filter invalid clicks and issue refunds, and Meta runs similar invalid-activity filtering. The gap exists because of how these systems are designed.

Platform filtering is conservative by necessity. A system that catches too aggressively risks throwing away real customers and real revenue. So the filters target high-confidence invalid traffic and deliberately leave anything ambiguous in the billed column. That conservative bias is exactly where SIVT—the sophisticated fraud that costs you real money—lives and thrives.

Beyond that, platform filtering protects only the click itself. Once that click lands on your property, the platform's job is done. If a proxy-driven bot clicks your ad, lands on your form, and creates a junk lead or a fake trial account, that's your cost to absorb. (We cover these downstream problems separately in how to stop fake signups and WooCommerce fraud prevention.)

Finally, you can't see how the platform makes its decisions. Refunds show up as an aggregate "invalid clicks" line with no IP-level breakdown. You can't tune the filters, can't audit the logic, and can't distinguish a competitor deliberately draining your budget from generic bot noise. Your own IP-layer screening gives you the visibility the platform won't.

The IP signals that expose invalid clicks

Click fraud has to originate from somewhere, and network origins leak intent. The strongest single signal is data-center or hosting origin. Genuine consumers click ads from home ISPs or mobile carriers—not AWS, OVH, Hetzner, or DigitalOcean. A click originating from a hosting range is automation until proven otherwise, and this is the single cleanest tell for separating GIVT from legitimate traffic. (If you want to understand why this distinction matters so much, Residential vs datacenter proxies goes deep on the topic.)

Proxy and VPN egress comes next. Click farms and bot networks route through proxy pools and commercial VPNs to cycle IPs faster than any blocklist can keep up. A VPN alone isn't conclusive—plenty of legitimate users route through VPNs—but a VPN combined with other signals (high velocity, datacenter origin, repeat keywords) starts to look like fraud. (How we detect VPN users has the mechanics.)

Tor exit nodes are nearly unambiguous. Almost no genuine ad-clicking consumer comes through Tor. For most verticals, a Tor egress on a paid click is safe to flag as invalid. (How to block Tor users covers the nuance for edge cases.)

Repeat velocity from a single IP or ASN exposes the pattern directly: five clicks on the same expensive keyword from one IP in an hour is not five customers. Per-IP velocity catches individual attackers; per-ASN velocity catches distributed campaigns hammering you from a single provider's network.

Finally, geo or language mismatch is a useful second-order signal. Clicks from outside your targeted geography that slip through (often via proxies misrepresenting location) correlate with fraud, especially when paired with other risk factors. (How to block visitors by country covers the geolocation layer.)

No single signal is a verdict. The durable approach is to fold them into one 0–100 risk score and act on the score — which is exactly the model we describe in IP risk scoring explained.

Block by risk, not by blocklist

The instinct is to collect bad IPs and block them. Google Ads does let you exclude IPs — up to 500 per campaign — and that's a genuinely useful backstop for a persistent, identifiable offender (a competitor's office, a single abusive ASN). But as a primary defence it fails for the same reason WordPress blocklists fail: real operations rotate faster than you can curate. A residential-proxy network has tens of thousands of egress IPs; your 500-slot list is full before lunch.

The model that scales is the same one that protects a checkout page:

The practical workflow has two halves. Measure first: log every inbound ad click's IP on your landing page, classify it, and quantify what share is Tier 3. Then enforce: feed your worst persistent offenders into the platform's IP-exclusion list, and on your own forms gate the conversion behind the risk score so junk clicks that do land never become junk leads.

Instrument your landing pages (the part most people skip)

You can't manage what you don't measure, and almost nobody measures their own click-fraud rate. The minimal version is a few lines on the landing page that captures ad clicks — identified by the gclid (Google) or fbclid (Meta) URL parameter the platforms append — and classifies the visitor's IP:

import os, requests
from flask import request

PREDAX_API_KEY = os.environ["PREDAX_API_KEY"]

def classify_ip(ip):
    r = requests.post(
        "https://predax.io/api/v1/check/ip",
        headers={"X-API-Key": PREDAX_API_KEY},
        json={"ip": ip},
        timeout=2,
    )
    return r.json()

def is_paid_click():
    # Google appends gclid, Meta appends fbclid to ad-destination URLs
    return bool(request.args.get("gclid") or request.args.get("fbclid"))

@app.route("/lp/offer")
def landing_page():
    ip = request.headers.get("CF-Connecting-IP") or request.remote_addr
    if is_paid_click():
        info = classify_ip(ip)
        c = info.get("classification", {})
        invalid = (
            c.get("is_datacenter")
            or c.get("is_tor")
            or c.get("is_proxy")
            or c.get("risk_score", 0) >= 75
        )
        # Log it either way — measurement is the whole point
        log_ad_click(ip=ip, gclid=request.args.get("gclid"),
                     risk=c.get("risk_score"), invalid=invalid)
        # Optional: suppress the conversion pixel for invalid clicks
        # so your CPA and ROAS reflect real prospects only
        request.environ["suppress_conversion"] = invalid
    return render_landing_page()

Run that for a week and you'll have something you've probably never had: a real, IP-level invalid-click rate for your own campaigns, broken down by keyword, campaign, and source network. That number is what turns "I think we're being click-frauded" into an exclusion list and a budget you can defend.

How Predax helps

Every /api/v1/check/ip response from Predax returns the signals this whole strategy depends on: `is_datacenter`, `is_vpn`, `is_proxy`, `is_tor`, the originating ASN, geolocation, and a composite `risk_score` (0–100) — in a single sub-second call you can drop into a landing page, a tag-manager custom template, or a server-side conversion endpoint. Results are cached, so repeat visitors add no latency, and the API fails open so an outage never breaks your funnel.

For teams running paid traffic into WordPress or WooCommerce, the Predax VPN & bot blocker plugin for WordPress and WooCommerce Fraud Prevention extensions already classify every visitor with these signals and log them to a threat dashboard — so an ad click that arrives from a data-center or proxy IP is visible (and optionally blocked) without writing any code. The same flags power the bot-traffic detection and chargeback-prevention workflows, so one integration covers click fraud, fake signups, and payment fraud together.

View pricing — the free tier includes the data-center, proxy, VPN, and Tor flags plus risk scoring, which is enough to start measuring your own invalid-click rate today.

Frequently Asked Questions

What is the difference between click fraud and invalid traffic?

Invalid traffic (IVT) is the umbrella term ad platforms use for any click or impression that shouldn't be billed — accidental double-clicks, known data-center bots, crawlers, and deliberate fraud all fall under it. The industry splits it into GIVT (General Invalid Traffic, the easy-to-filter known-bot and data-center category) and SIVT (Sophisticated Invalid Traffic, the harder category: residential-proxy bots, click farms, and human fraud farms). Click fraud is the deliberate, malicious subset of IVT — clicks generated specifically to drain a competitor's budget or to inflate a publisher's payout. All click fraud is invalid traffic; not all invalid traffic is click fraud.

Doesn't Google already filter invalid clicks automatically?

Google's Ad Traffic Quality team does filter a large amount of GIVT and refunds it, and Meta does the same — but the protection has two gaps. First, it is platform-wide and conservative: it catches the obvious known-bot and data-center traffic but is deliberately cautious about filtering anything that might be a real user, so sophisticated invalid traffic (residential proxies, distributed click farms) routinely gets through and billed. Second, the filtering only covers clicks on the ad itself — it does nothing about what happens after the click on your own landing page or signup form. Your own IP-level layer catches the SIVT the platform misses and protects the conversion event, not just the click.

Can I block click fraud just by blocking an IP address?

IP blocking is a useful first lever but a blunt one on its own. Google Ads lets you exclude up to 500 IP addresses per campaign, which is enough to shut out a single noisy office or a known abuser, but real click-fraud operations rotate through thousands of residential-proxy and data-center IPs far faster than a 500-entry static list can keep up. The durable approach is risk-based: classify each click's IP in real time (data-center, VPN, proxy, Tor, repeat-velocity) and act on the risk signal rather than maintaining a hand-curated blocklist. The static exclusion list then becomes a backstop for the handful of persistent offenders, not your primary defence.

How much of my ad budget is realistically lost to click fraud?

It varies enormously by vertical, but it is rarely zero and is often double digits. High-value verticals where a single click can cost £20–£80 ($25–$100) — insurance, legal, locksmiths, addiction services, B2B SaaS — attract the most deliberate competitor click fraud and see the highest waste. Juniper Research has repeatedly projected total advertiser losses to ad fraud in the order of $100bn per year globally. The practical way to find your own number is to instrument your landing pages: log every ad-click IP, classify it, and measure what share lands on data-center or proxy IPs with no genuine engagement. Most advertisers who do this for the first time are unpleasantly surprised.

Will filtering clicks by IP hurt my conversion tracking or Quality Score?

Done correctly, it helps both. Excluding invalid traffic improves your click-through-rate-to-conversion ratio because you stop paying for clicks that were never going to convert, which over time sharpens the platform's own optimisation and tends to support Quality Score rather than harm it. The risk is over-blocking real users — which is why the same rule that protects checkout applies here: never hard-block an entire category like 'all VPNs', use a risk-score threshold, keep verified search-engine crawlers allowed, and monitor your conversion rate after enabling enforcement so you can tell signal from noise.