A DSP knows which bid requests it won’t bid on. Dynamic Traffic Engine is a standardized proposal for informing the seller of that before it sends them, donated to IAB Tech Lab by Amazon Ads in April.
Sellers already shape traffic without any of it. They cap how many requests a given buyer gets, they rank buyers by how often they bid and cut the least active, and they score each request on how likely that buyer is to answer. All of that reads the buyer’s past behavior, which lags the thing that actually decides what a buyer wants: which campaigns are live today. Nothing stopped a buyer stating its preferences either, it just meant an email, a QPS cap or a bespoke filter, one integration at a time.
It works like a list the buyer hands over, with instructions for reading it. One file says which parts of a bid request to look at, seven of them in the reference setup: app or website, banner or video, which publisher, which country, the ad size, where it sits on the screen, what kind of device. The other file lists the combinations the buyer has an opinion about, one per line, values separated by a vertical bar:
app|banner|123456789|GBR|320×50|a|4
A 320×50 banner in a mobile app, near the top of the screen, publisher 123456789, UK, phone. When a request comes in, the seller pulls those same seven things out of it, joins them into one line, and checks whether that line is on the list. The list sits in memory, 1 to 10MB of it, so the check costs under a millisecond, and it’s re-downloaded every five minutes in case the buyer changed its mind.
The buyer also chooses which way to read the list. A drop list means send everything that isn’t on it. A keep list means drop everything that isn’t on it. Both are documented, and the closed beta ships only the first, so DTE today says what to stop sending. A list too long to move gets swapped for a Bloom filter, a compact structure that trades exactness for size.
Anything that breaks sends the request, and a stale list stops filtering after 24 hours. Broken DTE behaves like DTE nobody installed.
There’s also a holdout written into the wire format. Every forwarded request carries a learning flag, and 20% of traffic in the reference config is control: the library works out it would have dropped it, and the seller forwards it anyway with that verdict attached. The buyer gets a labeled sample of what the filtering costs, and the seller uploads a weekly report splitting fill rate and spend across both groups. The seller runs the experiment and reports the results to the buyer who wrote the model.
Every no-bid gets paid for twice, in CPU at both ends. The seller spends cycles building a request nobody wanted, the buyer spends cycles unpacking it to find out. Co-location removes the distance between them and leaves both costs in place, so dropping the obvious cases is what removes the work.
One line of a text message tells a seller which ads not to send
