Skip to main content
Thrad’s approach to invalid traffic (IVT) is layered and transparent: we filter at the edge, forward the full client signal at bid time, and fire verification pixels on the user’s device on render — so your DSP (and any third-party verification vendor you already use — DoubleVerify, IAS, HUMAN, or in-house) can validate independently of Thrad’s servers. Thrad is not MRC accredited and does not bundle an in-house sIVT vendor. The integration is designed so the DSP-side verification stack runs against Thrad’s forwarded signal.

​
Defense layers

​
1. Edge filtering (pre-bid)

All inbound traffic to the Thrad SSP passes through Cloudflare Bot Management before any bid request is generated. This strips General Invalid Traffic (GIVT) at the edge:
  • Known crawlers and spiders
  • Headless browsers and automation frameworks
  • Known datacenter IP ranges
  • Requests failing TLS / HTTP-level integrity checks
Traffic filtered at the edge never reaches your DSP as a bid request. You are never billed for it.

​
2. Bid-time signal forwarding

Every bid request carries the end-user signal needed for DSP-side IVT checks — IP and User-Agent in the request headers, plus a stable session identifier (device.ifa) for per-user velocity and anomaly detection. source.ext.schain carries the IAB SupplyChain object rooted in Thrad’s sellers.json. Full field map: Targeting Signals.

​
3. Impression verification

On render, two independent signals reach your infrastructure.

​
Client-side — independent trust channel

Thrad’s publisher-side measurement layer verifies viewability against the IAB/MRC display standard: 1 second at 50% of pixels in-view. On viewability-met, any tracker URLs you supplied in the bid response fire directly from the user’s device to your endpoint. The TCP connection lands on your server from the real user, with native IP and User-Agent in the request headers — no Thrad server in the middle. This is the signal your verification vendor (DV / IAS / HUMAN) needs to run client-observed validation. Include trackers in adm — for native, use the eventtrackers array (Native 1.2) with event: 1 (impression) and method: 1 (image pixel). That pair is the only one Thrad advertises and fires; event: 2 (viewable-MRC50) and method: 2 (JavaScript) are not supported yet. Because the pixel fires on viewability-met, your event: 1 tracker already counts only viewable impressions. Only the first tracker you declare is fired — see Viewability and impression counting.

​
Server-side — billing reconciliation

On impression confirmation, Thrad fires burl server-to-server with:
  • X-Forwarded-For set to the end-user IP
  • User-Agent set to the end-user UA
  • Auction macros substituted (${AUCTION_PRICE}, ${AUCTION_ID})
Events are deduplicated per bidId — one billable impression produces at most one burl call. nurl fires on win (before delivery) and does not confirm render; lurl fires on loss with a reason code. See Overview for the full lifecycle.

​
4. Human-originated vs agent-originated traffic

Thrad operates exclusively on traffic from contracted publishers with authenticated Thrad integrations, inside consumer conversational products. Bid requests originate from those authenticated publisher integrations; open API ingestion of conversation traffic from unauthenticated sources is not supported. Every publisher is identifiable in the bid request (site.publisher.id) and declared in sellers.json.