Verification protocols that identify and block invalid traffic—without slowing down performance

Programmatic campaigns move at real-time bidding speed, which means fraud also scales fast: spoofed domains, bot traffic, app/CTV misrepresentation, and “too-good-to-be-true” inventory that drains budgets while inflating vanity metrics. The fix isn’t a single switch—it’s a layered system that validates who is selling, what you’re buying, where ads render, and whether impressions come from humans.

Below is a practical framework ConsulTV teams and agency partners can use to build fraud detection layers across programmatic streams—especially for multi-channel plans spanning display, OTT/CTV, streaming audio, and retargeting—while protecting brand safety and reporting clarity.

Why “layers” matter: IVT is a supply-chain + traffic-quality problem

Invalid traffic (IVT) is not one thing. Some IVT is “general” (GIVT), like known datacenter traffic or invalid user agents. Some is “sophisticated” (SIVT), like hijacked devices, stealth bots, domain/app spoofing, or manipulated CTV traffic patterns that can pass basic filters. The most resilient approach separates detection into two tracks:

Track A: Supply authenticity
Validate sellers, paths, and authorized inventory so you’re not buying “made-up” supply.
Track B: Traffic authenticity
Detect non-human or manipulated traffic signals before (pre-bid) and after (post-bid) impressions.

When you treat those as separate layers, you can troubleshoot faster: if performance spikes, you can determine whether it’s a seller/path issue or a behavioral traffic issue.

Layer 1: Supply-chain verification (ads.txt, app-ads.txt, sellers.json, and schain)

Fraud prevention starts with buying from authorized sellers. The IAB Tech Lab’s sell-side transparency standards—ads.txt (web), app-ads.txt (apps/CTV apps), and sellers.json (seller identity)—exist to reduce domain/app misrepresentation and clarify who is authorized to sell an impression. (iabtechlab.com)

Practical controls to implement
• Enforce ads.txt / app-ads.txt authorization: Only bid when the seller is authorized for that domain/app environment. (iabtechlab.com)
• Validate seller identity using sellers.json: Cross-check seller IDs and domains to reduce spoofed supply. (dev.iabtechlab.com)
• Validate supply path via schain: Prefer transparent paths and avoid unnecessary hops that create room for arbitrage and laundering.
• Use aggregation when you need scale: Aggregated datasets can replace maintaining your own crawler for ads.txt/app-ads.txt/sellers.json monitoring. (iabtechlab.com)
Operational note: ads.txt v1.1 introduced fields like OWNERDOMAIN and MANAGERDOMAIN to improve clarity around ownership/management relationships. (iabtechlab.com)

For OTT/CTV and app-based inventory, app-ads.txt coverage is a frequent weak spot—especially when an app’s “developer website” or marketing URL isn’t maintained cleanly. A consistent audit cadence (weekly for high-spend campaigns, monthly for always-on) keeps authorization drift from becoming a budget leak.

Layer 2: Pre-bid IVT filters (block risk before you pay)

Pre-bid filtration is where you stop obvious waste early: suspicious device types, impossible geography, known datacenter ASNs, abnormal user-agent patterns, or inventory with historically high IVT. The goal is not to over-filter (and starve scale), but to define “non-negotiables” based on brand goals and channel.

Baseline (apply everywhere)
Block known invalid user agents/datacenters, enforce language/device sanity, cap frequency to reduce bot loops, and exclude obvious MFA-like placements when quality is inconsistent.
CTV/OTT-specific
Validate app bundle/store signals, enforce app-ads.txt where possible, and be stricter on anomalies like high completion with near-zero variance across placements.
Retargeting-specific
Require quality site signals (viewability + time-on-site where available), and suppress audiences that show rapid repeat exposure without downstream engagement.

Layer 3: Post-bid detection (prove what happened, then tighten rules)

Post-bid analysis is where you catch what slips through: behaviorally suspicious traffic, click injection patterns, impossible session paths, or CTV device clusters that don’t behave like households. Tie your detection to outcomes:

A step-by-step workflow for tightening IVT control

1) Define a “quality KPI set” per channel: viewability + attention proxies (display/video), completion rate distribution (CTV/OLV), on-site engagement (retargeting), assisted conversions (upper funnel).
2) Flag anomalies: spikes in impressions without corresponding reach growth, identical completion patterns, CTR anomalies by placement, or unusually low-cost pockets that outperform everything else.
3) Correlate to supply path: when performance looks “off,” check if it clusters in specific sellers, reseller paths, or apps/domains with weak authorization signals.
4) Convert flags into rules: add exclusions (apps/sites/sellers), restrict to more direct paths, tighten geo/device controls, or raise thresholds for viewability and fraud scores.
5) Re-test in controlled increments: avoid whiplash optimizations; make 1–2 changes per cycle so you can attribute impact.

If your reporting is white-labeled for clients, keep a separate internal “fraud and quality log” that records: rule changes, excluded supply, and the KPI impact. That turns fraud prevention into a measurable process (not a vague promise).

A quick comparison table: what each fraud layer catches best

Layer
Best for
Watch-outs
Supply-chain verification
Domain/app spoofing, unauthorized reselling, unclear seller identity
Doesn’t detect “human-looking” bots; requires ongoing monitoring
Pre-bid filters
Known IVT signatures, datacenter traffic, obvious anomalies
Over-filtering can reduce scale; rules need channel nuance
Post-bid detection
SIVT patterns, behavioral anomalies, “too perfect” delivery patterns
You may pay before you detect; needs clean log-level signals where possible
Note: Industry benchmarks regularly show IVT risk remains meaningful in channels like CTV, reinforcing why multi-layer controls matter. (globenewswire.com)

Did you know? Quick facts that sharpen your fraud playbook

ads.txt has newer relationship fields
ads.txt v1.1 added OWNERDOMAIN and MANAGERDOMAIN to improve seller relationship transparency. (iabtechlab.com)
You can avoid building your own crawler
Aggregated ads.txt/app-ads.txt/sellers.json datasets exist for teams that want scale without constant maintenance. (iabtechlab.com)
CTV authorization is a common gap
CTV apps and app store signals increase the need for disciplined app-ads.txt enforcement and audits—especially for multi-app supply. (iabtechlab.com)

Local angle: What U.S. teams can standardize across regions and verticals

For U.S. advertisers running multi-market campaigns (or agencies managing many clients), consistency beats heroics. A dependable fraud stack is a set of defaults that can be tightened for sensitive verticals (healthcare, legal, political) without reinventing the wheel.

A “U.S.-ready” baseline checklist

• Always-on supply checks: ads.txt/app-ads.txt/sellers.json validation for any scalable spend.
• Conservative inclusion lists for CTV: begin with premium, well-identified app supply; expand after post-bid stability.
• Separate reporting views: client-friendly KPI dashboards plus internal quality diagnostics (placement/seller/path flags).
• A monthly “authorization drift” audit: seller entries and app mappings change—make this recurring, not reactive.

Want a verification-first programmatic setup with white-labeled reporting?

ConsulTV helps agencies and in-house teams unify channels, tighten supply paths, and implement practical IVT controls—so performance stays credible and scalable.
Talk with ConsulTV

Prefer a platform walkthrough? Use the demo request page for a guided view.

FAQ: Fraud detection layers in programmatic advertising

What’s the difference between IVT and ad verification?
IVT focuses on whether traffic is valid (human, real devices, legitimate behavior). Ad verification is broader—often including brand safety, viewability, geo validation, and fraud measurement. Strong stacks treat IVT as one “lane” inside a bigger verification program.
Which layer should we implement first?
Start with supply authenticity (ads.txt/app-ads.txt/sellers.json + transparent paths) because it prevents purchasing clearly unauthorized inventory. Then add pre-bid filters for efficiency, and finally post-bid anomaly detection to catch sophisticated patterns and continuously improve rules.
How do ads.txt and sellers.json work together?
ads.txt (and app-ads.txt) indicates which sellers are authorized to sell a publisher’s inventory, while sellers.json helps identify the seller entity and relationships in the supply chain. Together, they reduce misrepresentation and make seller validation more actionable. (iabtechlab.com)
Do these controls matter for OTT/CTV as much as display?
Yes. CTV has unique fraud patterns (device spoofing, app misrepresentation, abnormal completion patterns). Ensuring app-ads.txt coverage and tightening app-level supply evaluation helps reduce exposure—especially when scaling budgets. (iabtechlab.com)
How do we keep fraud prevention “client-friendly” in reporting?
Maintain two layers of reporting: (1) a clean KPI view for business outcomes, and (2) an internal diagnostics view that logs exclusions, suspicious supply pockets, and rule changes. That keeps client reporting understandable while preserving auditability for your ops team.

Glossary (plain-English)

IVT (Invalid Traffic)
Traffic that shouldn’t be counted as legitimate ad delivery (non-human, manipulated, or otherwise invalid).
GIVT vs. SIVT
General IVT is easier to detect (known bots/datacenters). Sophisticated IVT uses more advanced tactics designed to evade standard filters.
ads.txt / app-ads.txt
Publisher-posted files that list which companies are authorized to sell their inventory on the web (ads.txt) or for apps (app-ads.txt). (iabtechlab.com)
sellers.json
A file published by ad systems (often SSPs) describing seller identities and types to improve supply-chain transparency. (dev.iabtechlab.com)
Supply path / schain
Data that indicates how an impression traveled from publisher to buyer; helpful for identifying unnecessary intermediaries and reducing spoofing/arbitrage risk.
Pre-bid vs. post-bid
Pre-bid controls stop risky impressions before purchase. Post-bid controls analyze delivered impressions and feed learnings back into stricter buying rules.