The Association of National Advertisers released a report this week with White Ops that puts a number on the problem the industry has been reluctant to quantify: bot traffic will cost digital advertisers $6.3 billion globally in 2015, up from what sources suggest was approximately $4.6 billion in 2014. Those are not small numbers. They represent a systematic transfer of advertiser budget to fraudulent inventory operations, running through programmatic infrastructure that, until recently, had neither the incentive nor the tools to stop it.

The report is uncomfortable reading for anyone in the programmatic supply chain. Bots browsed the study’s analyzed sites at every hour of the day, with the signature of non-human traffic patterns visible in session behavior, browsing speed, and mouse movement data. Bot operators have become sophisticated — modern sophisticated invalid traffic (SIVT) is designed to mimic human browsing patterns in ways that defeat naive detection.

For buyers running programmatic display campaigns, the question is not whether you have bot traffic in your campaigns. You do. The question is what percentage, what your DSP is doing about it at the pre-bid level, and whether your contracts give you any recourse when IVT is detected post-campaign.

GIVT vs SIVT: Why the Distinction Matters Operationally

The industry distinguishes between two categories of invalid traffic, and the difference has significant implications for how you defend against each.

General Invalid Traffic (GIVT) is relatively easy to identify: data center IP addresses running known bots, web crawlers, search engine spiders, declared research panels. GIVT sources are identifiable from publicly maintained blocklists — the Interactive Advertising Bureau’s Invalid Traffic Detection and Filtration Guidelines specify how GIVT should be filtered in measurement systems. Any competent DSP or exchange should be filtering GIVT from impression counts before reporting. If your DSP is counting data center bot impressions in your billing, that is a vendor failure, not an industry inevitability.

Sophisticated Invalid Traffic (SIVT) is the harder problem. SIVT encompasses bots designed to evade detection: they operate from residential IP addresses, use real browser user agents, simulate human-like timing between page events, and sometimes even move a cursor across the page to defeat mouse-movement detection. They are deployed by organized criminal operations running botnet infrastructure on compromised consumer devices. The White Ops research identified SIVT patterns in a significant percentage of the traffic they analyzed, and these signatures are far harder to detect in real time at the DSP bid level.

SIVT detection requires behavioral analysis over time — looking at patterns across multiple impressions and sessions from the same device or IP range, checking against signals like cookie acceptance behavior, JavaScript execution patterns, and engagement signals. This is not something that can be done in the 100-millisecond RTB bid window. It requires post-bid analysis with reporting feedback loops, or pre-bid scoring built on historical SIVT pattern data.

What Pre-Bid vs Post-Bid Verification Actually Means

There are two broad points in the programmatic workflow where IVT verification can occur, and the distinction has significant budget implications.

Pre-bid verification happens before the DSP submits a bid. The DSP evaluates the bid request against an IVT risk score — typically provided by a third-party verification partner with historical SIVT pattern data — and either bids normally, adjusts its bid price downward to reflect fraud risk, or suppresses the bid entirely for high-risk inventory. Pre-bid verification prevents waste at the source: if the DSP doesn’t bid on fraudulent impressions, those budget dollars are never spent and never need to be recovered.

The challenge with pre-bid verification is data quality and coverage. Pre-bid IVT scoring is based on historical pattern data, not real-time bot detection. A newly deployed botnet operating from residential IPs that have never appeared in fraud data will receive clean pre-bid scores and be bid on normally. Pre-bid filtering catches known bad inventory; it doesn’t catch new or evolving SIVT operations.

Post-bid verification happens after impressions are served. Third-party measurement tags from DoubleVerify, Integral Ad Science, or White Ops execute alongside creative delivery and analyze impression-level signals for SIVT patterns after the fact. This catches sophisticated fraud that pre-bid scoring misses, but the budget has already been spent.

The actionable outcome of post-bid verification is credit recovery from your DSP and exchange partners for confirmed invalid impressions, and updated IVT data that informs future pre-bid scoring models. But credit recovery requires contractual provisions — and many DSP and exchange contracts do not currently include IVT credit obligations. This is a contract negotiation point that buyers should be raising today.

Which DSPs Have Third-Party Verification Integrated

The state of third-party IVT verification integration varies significantly across DSPs, and buyers should be asking direct questions rather than accepting platform claims at face value.

The questions to ask: Does the DSP have a pre-bid integration with at least one accredited IVT verification provider? Which provider(s)? Is pre-bid filtering applied by default or does the buyer need to opt in? What is the measurability rate — what percentage of impressions have pre-bid IVT scores available? How is IVT identified post-bid reported, and what is the credit process for confirmed invalid impressions?

AppNexus has been public about its investment in fraud detection infrastructure, both internal and through third-party integrations. Turn has third-party verification partnerships. The DSP market as a whole is moving toward making IVT verification integration a competitive differentiator because buyers are starting to ask for it. But the depth and default status of these integrations varies, and “we have a verification partnership” is not the same as “we filter high-risk inventory before bidding by default.”

DoubleVerify’s fraud protection documentation and the White Ops threat assessment provide useful reference on SIVT detection approaches and what to look for in a verification vendor’s methodology.

Making IVT Reporting a Contract Requirement

The structural lever that buyers have — and largely are not using — is contract language. An insertion order or DSP master services agreement that does not specify IVT measurement, reporting, and credit obligations gives the seller no incentive to prioritize fraud protection on your account.

The minimum language every programmatic buyer should be pushing for: mandatory pre-bid IVT filtering against GIVT sources as a baseline delivery standard, third-party IVT measurement capability for any significant campaign, defined IVT measurement methodology with MRC-accredited vendor options, credit provisions for confirmed SIVT that exceed a defined threshold (industry practice is moving toward 5 to 10 percent SIVT triggering credit), and access to impression-level IVT data for auditing.

Some publishers and exchanges will push back on these terms, particularly the credit provisions. That pushback is itself informative. Partners with high-quality inventory and robust fraud protection have limited liability exposure under these terms. Partners who resist audit-level IVT transparency or credit obligations are protecting something.

The $6 billion figure in the ANA report will continue to grow as long as the programmatic ecosystem treats fraud as a buyer problem rather than a supply chain accountability issue. Buyers forcing contractual accountability upstream is the mechanism that changes incentives. The report gives you the ammunition — the next step is the contract conversation.


Frequently Asked Questions

What is the difference between GIVT and SIVT, and which should I be more worried about? GIVT (General Invalid Traffic) includes known data center bots, crawlers, and spiders that can be identified from IP blocklists. SIVT (Sophisticated Invalid Traffic) includes bots designed to mimic human behavior, operating from residential IPs and evading standard detection. GIVT should be filtered by any competent DSP by default. SIVT is the harder and more expensive problem — it requires behavioral analysis and third-party verification infrastructure to detect.

How much of my current programmatic display spend is going to bots? Industry estimates based on current research suggest that 10 to 30 percent of open exchange programmatic display impressions may be invalid traffic of some kind, with a meaningful share representing SIVT that evades standard detection. The percentage varies significantly by exchange, inventory category, and how aggressively your DSP applies pre-bid filtering. Campaigns running without third-party post-bid verification don’t know their actual IVT rate.

Should I require third-party IVT verification on all campaigns? For any campaign of meaningful scale — generally $25,000+ in programmatic spend — third-party post-bid IVT verification from an MRC-accredited provider should be standard practice. The incremental measurement cost is small relative to the waste you’ll identify and the leverage it gives you in credit negotiations with exchange partners.

Can I get refunds from my DSP for bot traffic? This depends entirely on your contract terms. DSPs without IVT credit obligations in their contracts have no obligation to provide refunds. Buyers should push for credit provisions in new contracts and renewals, specifying IVT thresholds above which credits apply and the measurement vendor whose data governs the determination.