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 stable session identifiers (userId / chatId on the AI-native path, device.ifa on the oRTB path) for per-user velocity and anomaly detection. On the oRTB path, source.ext.schain carries the IAB SupplyChain object rooted in Thrad’s sellers.json. Full field map: Targeting Signals (oRTB) and the bid endpoint reference (AI-native).

​
3. Impression verification

On render, two independent signals reach your infrastructure.

​
Client-side — independent trust channel

Thrad’s publisher SDK measures viewability against the IAB/MRC display standard: 1 second at 50% of pixels in-view. On viewability-met, the SDK fires any tracker URLs you supplied in the bid response 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.
  • AI-native path: include your view/verification URLs in the bid response; the SDK fires them on viewability.
  • oRTB path: include trackers in adm — for native, use the eventtrackers array (Native 1.2) with event: 1 (impression) or event: 2 (viewable-MRC50).

​
Server-side — billing reconciliation (oRTB)

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 integrated via Thrad’s authenticated SDK, inside consumer conversational products. Bid requests are generated by Thrad’s SDK embedded in publisher applications; open API ingestion of conversation traffic from unauthenticated sources is not supported. Every publisher is identifiable in the bid request (site.publisher.id on oRTB; publisher metadata on the AI-native path) and declared in sellers.json.