If you've ever built or maintained anything that spends money on paid search, here's an uncomfortable number to sit with: independent studies and industry data put invalid traffic at roughly 15–30% of ad spend. That's not a rounding error. On a modest €10k/month Google Ads budget, you're potentially burning €1,500–€3,000 on clicks that were never going to convert — bots, competitors draining your daily cap, click farms, and misconfigured automation.
The instinctive engineering reaction is: "I'll just block the bad IPs." I had the same reaction. It doesn't work, and the reasons it doesn't work are a genuinely interesting distributed-systems and security problem. Let's dig into why click fraud is hard to detect, and what a realistic defense actually looks like. (If you just want the short version, ProtectAds has a plain-English breakdown of what click fraud is.)
The naive solution and why it falls apart
The first design everyone reaches for is a blocklist:
1. Log the IP of every ad click
2. Count clicks per IP in a time window
3. If count > threshold, add IP to the platform's exclusion list
It feels reasonable. It also breaks on contact with reality:
- IPs are cheap and disposable. Residential proxy networks and mobile carrier NAT mean a single "user" can rotate through thousands of IPs in an hour, and thousands of real users can share one carrier-grade NAT IP. Block by IP and you'll ban legitimate customers while the fraud walks around you.
- Thresholds are a guessing game. Set it low and you nuke real repeat visitors (someone comparing prices across three sessions). Set it high and the fraud sails under it.
- Ad platforms exclude, they don't refund automatically. Google Ads and Microsoft Ads let you add IP exclusions, but the click already happened and you already paid. By the time your batch job notices, the budget's gone.
- It's stateless about intent. An IP tells you where, not who or why. Two clicks from the same IP can be a household sharing a router or a script in a loop. Raw IP counts can't tell them apart.
Blocklisting is the if (password == "admin") of fraud prevention: it looks like security, but it's pattern-matching the laziest 1% of attackers.
Why the problem is fundamentally hard
Click fraud is an adversarial problem, which puts it in the same bucket as spam filtering, fraud scoring, and intrusion detection. The thing you're trying to detect is actively trying not to be detected. That changes the engineering math in a few ways.
1. Sophisticated invalid traffic mimics humans
Modern automated traffic isn't a curl loop with a python-requests user agent anymore. It runs headless browsers that execute JavaScript, render the DOM, carry cookies, generate plausible mouse movement, and rotate through real residential IPs. From the perspective of a single request, it can look indistinguishable from a real visit. The signal that gives it away usually isn't in any one click — it's in the shape of behavior across many clicks over time, which means you need continuous, large-scale analysis rather than a per-request rule.
2. The base rate makes precision brutal
If ~20% of clicks are invalid, your classifier has to be careful in both directions. A false positive (blocking a real customer) costs you a sale and is invisible — you never see the conversion you prevented. A false negative (letting fraud through) costs you ad budget. Optimizing one trades off the other, and the cost of each isn't symmetric or even easy to measure. This is a classic precision/recall problem where the "ground truth" labels are themselves fuzzy.
3. You're working with incomplete telemetry
You don't own the ad platform. You get the click, a referrer, a timestamp, some campaign metadata — and then the visitor lands on your property where you do control instrumentation. Stitching those two worlds together, attributing a landing-page session back to the paid click that caused it, and doing it across Google Ads and Microsoft Ads (which expose different APIs and data shapes), is most of the actual engineering work.
4. It has to be real-time to matter
A nightly report that says "you got defrauded yesterday" is an autopsy, not a defense. To actually protect budget you need to react inside the campaign's serving window — fast enough that the same bad actor doesn't keep getting served your ads for the rest of the day. That's a streaming/low-latency requirement layered on top of the classification problem.
Build vs. buy: the honest trade-off
Could you build this in-house? Sure — engineers build hard things. But be clear-eyed about the scope before you put it on a roadmap:
| Concern | What it actually requires |
|---|
| Data collection | Reliable click + session capture across multiple ad platforms and their differing APIs |
| Detection | Continuously updated behavioral analysis, not static rules, because attackers adapt |
| Scale | Streaming analysis over potentially millions of events with low latency |
| Action | Pushing exclusions back to Google/Bing automatically, in-window |
| Evidence | Audit-ready reports if you ever want to dispute charges with the platform |
| Maintenance | A permanent commitment — the adversary never stops, so neither can you |
That last row is the killer. Fraud detection isn't a project you ship and forget; it's an ongoing arms race that needs continuous tuning. For most teams whose core product isn't ad-fraud detection, this is a textbook "buy" — the same call you'd make for payments or auth. You can roll your own Stripe, but you probably shouldn't.
What a real defense looks like
Whether you build or buy, an effective click-fraud defense shares the same shape:
- Observe across the full funnel — the click, the session it produced, and how it behaved, joined together.
- Analyze behavior over time, not single requests, because that's where automated traffic reveals itself.
- Act automatically and fast, feeding exclusions back to the ad platform inside the serving window.
- Keep evidence, so blocked traffic is defensible and you can see what your protection actually caught.
This is the model ProtectAds is built on. It protects Google Ads (including Performance Max) and Microsoft / Bing Ads — those two platforms, done properly, rather than a shallow integration with everything. You connect your ad account, it monitors clicks and the traffic they generate, and it pushes exclusions automatically while keeping a record of what it blocked and why. The detection runs continuously so it keeps pace with traffic that's deliberately trying to look human. If you want the conceptual overview without the marketing gloss, the how-it-works page walks through the flow, and there's a separate primer on invalid traffic if you want to understand the categories first.
A quick gut-check before you spend more
If you're not sure this applies to you, do the cheap diagnostic first: look at your analytics for paid-search sessions with near-zero dwell time, immediate bounces, impossible geographies relative to your targeting, or suspicious bursts against your daily budget. If a meaningful slice of your paid clicks look like that, you're somewhere in that 15–30% band, and it's worth quantifying. ProtectAds has a wasted-spend calculator that estimates the euros at stake from your spend and platform.
Takeaways for engineers
- Click fraud is an adversarial, behavioral, real-time problem — not a blocklist.
- IP-based blocking fails because IPs are disposable and shared; intent doesn't live in an IP.
- The hard part is joining ad-platform clicks to on-site behavior, classifying with asymmetric error costs, and acting fast enough to protect a live budget.
- It's a permanent arms race, which makes it a strong candidate to buy rather than build unless ad fraud is your core product.
If you run paid search on Google or Bing and want to stop guessing how much of your budget is real, ProtectAds offers a free trial you can cancel anytime (a card is required to start). Even if you never buy anything, understanding why the problem is hard will make you a sharper operator of your own campaigns.