Ad networks catch fraudulent traffic by layering several checks on every impression: IP and device reputation, authorized-seller verification, behavioral analysis, and comparison against traffic-quality benchmarks. No single check catches everything, which is exactly why networks stack them — a bot that spoofs one signal usually trips another. Understanding how ad networks detect fraud is useful even if you never build a detection system yourself, because it tells you what to check in your own traffic before a network (or an advertiser) flags it for you.
This guide walks through the same checks a network runs, adapted so a publisher or advertiser can apply them directly. You don't need a fraud-detection team to do this — most of it is available in the reporting you already have, plus a handful of free tools.
Before you start
You'll need access to your ad network's reporting dashboard (impressions, clicks, and — if available — invalid traffic or IVT reports), your site or app's server logs, and your ads.txt or app-ads.txt file if you're a publisher. If you're an advertiser, you'll want your campaign's placement-level reporting instead of just the account-level summary; fraud usually concentrates in a handful of placements, and an account average hides that.
You don't need specialized fraud software to do the first pass. The Media Rating Council sets the industry definitions for invalid traffic that most networks build their detection against, and it's worth knowing the two categories it splits fraud into: General Invalid Traffic (GIVT) — traffic from known bots, spiders, and datacenters, filtered with static lists — and Sophisticated Invalid Traffic (SIVT), which mimics human behavior and requires the behavioral checks below to catch.
Step-by-step: how ad networks detect fraud
1. Cross-check IP and device reputation. Every ad request carries an IP address and device signals (user agent, device ID). Networks match these against known datacenter ranges, VPN exit nodes, and blocklists of devices already tied to fraud. This step alone catches most GIVT — traffic from data centers has no business generating "real" ad impressions, so a high share of datacenter IPs in your traffic is an immediate red flag. You can run a lightweight version of this yourself by pulling the IP list from your server logs and checking a sample against a public IP-reputation lookup.
2. Verify the seller is authorized. This is where ads.txt and app-ads.txt come in. Both are IAB Tech Lab standards that let a publisher publish a public, plain-text list of who's allowed to sell their inventory. A network checks that an impression is being sold through an authorized path before bidding on it; if it isn't listed, the impression is treated as suspect regardless of how legitimate the traffic looks. If you're a publisher, this is the cheapest fraud-prevention step available — it's a text file, not a system:
curl -s https://example.com/ads.txt | head -20
If that command returns nothing, or a path that isn't your own ad partners, that's the first thing to fix — not a detection problem, a configuration one. The IAB Tech Lab's ads.txt spec has the full format if you're setting it up for the first time.
3. Analyze behavioral signals. This is the layer that catches SIVT — traffic built to look human. Networks look at click timing (a real user doesn't click 40 milliseconds after a page loads), mouse movement and scroll behavior on the page, session length, and whether the same fingerprint shows up across sites that have nothing in common. None of these signals is damning alone; a fast click can be a returning visitor who knows exactly what they want. It's the combination, scored together, that separates a bot pattern from a human one.
4. Compare traffic quality against benchmarks. Networks maintain a baseline for what normal traffic looks like — bounce rate, session duration, click-through rate, conversion rate — segmented by vertical and geography, and flag placements that deviate sharply. A sudden spike in traffic volume with a flat or falling engagement rate is one of the most reliable fraud tells there is, because real audience growth almost never arrives disengaged. Pull your own week-over-week numbers by placement, not just by account, since fraud is rarely spread evenly.
5. Layer in third-party verification. Most networks don't rely purely on their own detection — they run traffic through independent verification vendors (MRC-accredited firms like DoubleVerify, IAS, or HUMAN) as a second opinion, because a vendor that only ever grades its own traffic has an obvious incentive problem. This is also the point where a pooled-demand network earns its keep for a publisher: a platform like Adsy runs these checks at the marketplace level, before an impression ever reaches an advertiser, which is harder to replicate site-by-site on your own.
6. Maintain and update blocklists. Fraud patterns shift, so static lists go stale. Networks continuously add newly identified bad IPs, device IDs, and domains to their blocklists and retire ones that no longer see abuse, rather than treating the list as a one-time setup. If you maintain your own list — of referrers, IPs, or apps you've caught passing bad traffic — review it monthly, not once.
How to tell it's working
The clearest signal is your invalid traffic rate trending down or staying flat while volume grows — if traffic and IVT rate rise together, your detection isn't catching the new sources. Watch the same benchmark metrics from step 4 (bounce rate, session duration, click-through rate) for stability rather than expecting them to spike; the goal of detection isn't higher engagement, it's removing the traffic that was never going to engage in the first place. If you're a publisher, revenue per thousand impressions (RPM) is a good confirming metric — advertisers and networks pay less for inventory with a fraud history, so a stable or rising RPM alongside a falling IVT rate is a strong sign the cleanup is being noticed on the demand side.
Give any change at least a week before judging it. Fraud sources often rotate IPs and device fingerprints on a delay, so a filter that looks effective on day one can get routed around by day five.
Troubleshooting
Fill rate drops after you tighten filtering. This is expected to some degree — you're removing bids you were previously winning with bad traffic. The problem is if fill rate drops more than your IVT rate did; that means the filter is also catching legitimate traffic. Narrow the rule (for example, block a specific IP range instead of an entire ASN) and re-check.
ads.txt is correct but you're still seeing unauthorized reseller traffic. Some fraud specifically exploits gaps between ads.txt and the actual bidding chain — an intermediary claims authorization it doesn't have. Cross-reference against sellers.json from your supply-side partners, which lists who each seller actually is, and report mismatches to your network.
Behavioral signals look clean but conversion rate is still near zero. Sophisticated bots increasingly mimic engagement (scroll depth, dwell time) without ever converting, because conversion is harder to fake convincingly. Treat "engaged but never converts" as its own category worth investigating, not proof the traffic is legitimate.
You can't tell if a spike is fraud or a real traffic event. Check whether the spike correlates with something explainable — a mention on another site, a paid campaign launch, a seasonal pattern. If there's no explanation and the new traffic's engagement metrics look flat, treat it as suspect until proven otherwise rather than assuming good faith.
FAQ
What's the difference between ad fraud and invalid traffic?
Invalid traffic (IVT) is the broader technical category — any traffic that doesn't represent a genuine ad opportunity, including honest mistakes like accidental bot crawls. Ad fraud is invalid traffic generated deliberately to extract ad revenue or drain a competitor's budget. All fraud is invalid traffic; not all invalid traffic is fraud.
Can small publishers realistically detect fraud without expensive tools?
Yes, to a meaningful degree. ads.txt/app-ads.txt setup, IP log review, and watching engagement metrics by placement are all free and catch a large share of basic fraud. Sophisticated SIVT is harder to catch without a verification vendor or a network that runs one on your behalf.
Does ad fraud affect advertisers or publishers more?
Both, in different ways. Advertisers pay for impressions or clicks that never had a chance to convert, directly losing budget. Publishers with a high fraud rate get deprioritized or dropped by demand partners, which shows up as falling fill rates and CPMs even on their legitimate traffic.
How often should traffic quality be reviewed?
Weekly at a minimum for active campaigns or high-traffic placements, since fraud sources rotate faster than a monthly review can catch. A monthly deeper review of blocklists and benchmark drift is a reasonable cadence on top of that.
Is ads.txt enough on its own to prevent fraud?
No. It closes off one specific exploit — unauthorized resale of inventory — but does nothing against bots, click farms, or device spoofing. It's a necessary first layer, not a complete fraud defense.
Conclusion
Ad networks detect fraud by stacking several checks — IP and device reputation, authorized-seller verification, behavioral analysis, benchmark comparison, third-party verification, and continuously updated blocklists — because no single check reliably catches everything on its own. Publishers and advertisers can run lighter versions of most of these checks directly, using reporting they likely already have access to, without needing a dedicated fraud team.
Key takeaways
- Fraud detection works in layers; a single check (like ads.txt alone) closes one exploit, not all of them.
- Datacenter IPs and missing/incorrect ads.txt are the cheapest fraud signals to check first.
- Sudden traffic growth with flat or falling engagement is one of the most reliable fraud tells.
- Give filtering changes at least a week to show results, since fraud sources rotate to route around new rules.
- Review blocklists and benchmarks on a recurring schedule — fraud patterns shift faster than a one-time setup accounts for.
