What is supply path optimization (SPO)?
Short answer
Supply path optimization is a buyer's practice of deciding which intermediaries to buy an impression through, then cutting the rest. The same impression is usually offered by several exchanges and resellers at once, at different prices and fees, so buyers compare paths on cost, win rate, and how verifiable the seller chain is, then concentrate spend on the shortest defensible path. In OpenRTB the evidence for that decision lives in source.schain, cross-checked against the publisher's ads.txt and each intermediary's sellers.json.
Why the same impression reaches a buyer more than once
A publisher rarely sells through one exchange. A page runs header bidding with several demand partners, the ad server has its own programmatic demand, and some of those partners resell to other exchanges. The result is that a single impression opportunity fans out and arrives at a large DSP through multiple paths, each with its own fee stack and its own claim to be selling the same thing.
OpenRTB anticipates this. source.tid is a transaction id shared by every participant offering the same impression, so a buyer can recognise duplicates, and source.fd says whether the exchange sending the request is the entity that makes the final decision or is passing it along. Both fields exist because the entity talking to you is often not the one who owns the inventory. See OpenRTB versus header bidding for how the duplication arises.
What SPO actually optimises
Supply path optimization means picking which of those paths to keep. The comparisons that matter, in rough order of how much money they move:
- Net cost. Every hop takes a cut. Two paths to the same impression can differ by double digits in what actually reaches the publisher.
- Win rate on identical inventory. If two paths offer the same
source.tidand one wins consistently cheaper, the other is noise you are paying to process. - Request quality. A path that drops
schain, sends stalevideo.placementinstead ofvideo.plcmt, or omits privacy signals forces you to bid blind or not at all. - Latency. A path that arrives late against
tmaxloses auctions you priced correctly. See tmax and bidder timeouts. - Auditability. A chain that cannot be reconciled against ads.txt and sellers.json is a chain you cannot defend to a client.
The sell-side mirror image is demand path optimization: publishers and SSPs cutting the demand sources that cost more to serve than they return.
The fields that make a path checkable
SPO decisions are only as good as the evidence in the request. Three artefacts do the work together, and each covers a gap the others leave:
| Artefact | Where it lives | What it establishes |
|---|---|---|
| ads.txt / app-ads.txt | Publisher domain | Which sellers the publisher authorises to sell its inventory, and as what |
| sellers.json | Each intermediary's domain | Who the seller account ids belong to, and whether they are publishers or intermediaries |
source.schain | The bid request itself | The ordered chain of sellers that handled this specific impression |
The SupplyChain object requires complete, nodes, and ver; each SupplyChainNode requires asi and sid, and sets hp when the node is in the payment path. complete: 1 asserts that every intermediary between publisher and buyer is present. Full field semantics are in the schain reference, and the cross-checking model is in the supply chain trust stack.
What you can catch before the analysis starts
Half of the paths that look unattributable are just malformed. RTBlint flags the structural failures directly from a payload: openrtb.schain.duplicate_node when the same asi and sid pair appears twice in one chain, openrtb.schain.node.identifier_empty when a node ships an empty asi or sid, and openrtb.schain.node.hp_missing when a node omits the payment-path flag. Run a real request through the tester before concluding a partner is hiding something.