Amazon Open-Sources Its Traffic Engine: What It Means for Publisher Bid Rates

On April 15, IAB Tech Lab announced that Amazon Ads had donated its Dynamic Traffic Engine (DTE) to the Tech Lab's open source initiative. The framework gives demand-side platforms a standard way to tell supply-side platforms which kinds of bid requests they want over a given period, so SSPs can stop sending the rest. Amazon Ads built it for its own DSP. It now sits under industry governance, with code published on GitHub.

It sounds like plumbing between DSPs and SSPs, and it is. But that plumbing decides whether your impressions ever reach a buyer, so publishers should understand how it works.

The problem DTE addresses

Programmatic has a volume problem. A single page view can generate many bid requests: several SSPs in a wrapper, each forwarding to many DSPs, often with the same impression reaching a DSP through multiple paths. DSPs cannot process everything they receive, so they cap the queries per second (QPS) they accept from each SSP. SSPs then have to choose which requests to send within those caps. That choice is traffic shaping, and each SSP has historically done it with its own models, predicting which requests a given DSP is likely to bid on.

When the prediction is wrong, a request a buyer would have valued never reaches it. From the publisher side, this looks like low bid rates from a partner that should want your inventory, or bid rates that swing without an obvious cause.

Waste is expensive on both ends. Every request a DSP receives and ignores costs it compute, and every request an SSP sends that goes nowhere costs it bandwidth and servers. Those costs get priced into the fees that sit between the advertiser's dollar and the publisher's payout. The Tech Lab framed DTE around exactly this: reducing unnecessary bid requests and lowering QPS pressure across the supply chain. Less waste does not automatically mean more money for publishers, but a leaner pipe is one where valuable impressions are less likely to be lost in the noise.

What DTE changes

DTE replaces some of the prediction with a declaration. Per the announcement, it uses a file-based approach: the DSP publishes the types of requests it prioritizes, from broad acceptance rules down to specific inventory or audience preferences, and SSPs poll that information and filter accordingly. Amazon Ads' Pieter de Zwart described the shift as moving “from guessing to knowing.” The Tech Lab also said early proposals include updating DTE through its Agentic Real-Time Framework, part of the broader Agentic Advertising Management Protocols (AAMP) effort.

Because it is open source under Tech Lab governance, any DSP and SSP can adopt it without building a one-off integration for each pair.

What it means for publishers

Your requests will be judged more precisely

If DSPs declare what they want and SSPs filter to match, the quality of the signals in your bid requests matters more. An impression with an accurate page URL, correct ad sizes, the right format and device data, valid consent strings and a clean supply chain object is easier to match against a buyer's declared preferences. Missing or wrong fields make it more likely a request is filtered out before any buyer sees it.

Duplicate paths look worse

If a buyer can signal that it wants an impression once, through a preferred path, the extra copies arriving through other SSPs become easier to drop. Publishers running many SSPs that all resell the same inventory may see some partners' bid rates fall as buyers get more efficient. Supply path optimization has pushed this way for years; DTE gives it better tools.

Bid rate becomes a diagnostic

If a partner's bid rate drops after it adopts declared-preference filtering, that tells you buyers downstream are not prioritizing what that partner sends from your site. Ask partners whether they use DSP-declared preferences, and ask for bid rate by DSP where they will share it.

What to do now

1. Audit bid request quality. Pull sample requests from your wrapper and check the basics: page URL and domain, sizes that match the slot, correct mediaTypes, device data, consent signals and the schain object. Fix what is missing.
2. Review your SSP roster. List each SSP, its share of revenue and how much of your inventory it overlaps with others. Partners that add little unique demand but multiply requests are candidates to remove or move server-side.
3. Keep ads.txt and sellers.json tidy. Buyers who shape traffic tend to favor direct, verifiable paths. Remove stale reseller lines and make sure direct relationships are labeled correctly.
4. Track bid rates by partner. Watch bid rate and win rate per SSP over time, and investigate sudden changes before assuming demand disappeared.
5. Ask about adoption. Adoption will take time. Ask your SSPs whether they plan to support DTE and how they currently shape traffic toward buyers.

Where this fits for app and gaming publishers

The same dynamics apply in app and gaming inventory, where request volumes are high and many mediation and bidding partners can represent the same impression. Declared buyer preferences reward accurate app metadata, correct app-ads.txt entries and clear format signals (rewarded, interstitial, banner). If your in-app bid requests carry thin metadata, fixing that is likely to matter more over time, not less.

The bigger picture

For years, publishers answered weak demand by adding more demand partners. That made sense when buyers saw nearly everything. As DSPs get better tools to say what they want and ignore the rest, more requests do not guarantee more bids. Clean, well-described, direct inventory does. DTE is one piece of that shift, and it is being built in the open, which is good for everyone who has to live with the results. A well-run wrapper, in-house or managed, should already be pruning partners on this basis.