Blog

Supply Path Optimization: How to Be the Path Buyers Keep

SPO is a decision made about you, not by you. What a DSP actually measures when it ranks supply paths, and how an exchange stays on the list.

16 min read By the Floxis engineering team

The same impression reaching one buyer through five supply paths, four of which are cut, with the surviving path chosen on fee transparency, latency, duplication and signal quality

A single impression on a mid-sized news site leaves the page and, within a hundred milliseconds, arrives at the same DSP five separate times. Once through the publisher’s primary exchange. Once through a second exchange the publisher added last year. Three more times through resellers, each of which bought the inventory from one of the first two.

The DSP is now looking at five bid requests for one ad slot. It can win the impression through any of them, and the price it pays differs by every fee taken along each route. It cannot tell from the request alone which paths are duplicates of which — but it can find out, and increasingly it has.

So it does the obvious thing. It picks the paths it trusts, buys through those, and stops listening to the rest.

That decision is supply path optimization, and the thing to understand about it if you operate an exchange is that SPO is something done to you. You do not run an SPO programme; your buyers do, and the output is a list with your name on one side of a line or the other. This article is about what actually determines which side.

Table of Contents

What is supply path optimization?

Supply path optimization is the practice, on the buy side, of deliberately restricting which routes a buyer uses to reach a given piece of inventory — rather than bidding on every request that arrives and letting the auction sort it out.

The mechanics are unremarkable. A DSP collects its own logs, groups requests by the inventory they represent, discovers that many of them are the same opportunity arriving by different routes, and evaluates each route on cost, reliability and quality. Routes that survive get spend, preferential QPS and sometimes a direct commercial agreement. Routes that do not are throttled, deprioritized or switched off entirely.

What makes it consequential is that the evaluation is relative. You are not being measured against a standard you can read and satisfy; you are being measured against the other paths to the same impression. A path can be perfectly well-run and still get cut for being the third-best route to inventory the buyer can reach two better ways. This is why “we are compliant and our latency is fine” is not a defence, and why the section on duplication below matters more than the ones on hygiene.

Why did buyers start cutting paths?

Three pressures arrived at roughly the same time, and each on its own would have been survivable.

Infrastructure cost became visible. Bid requests are not free to receive. A DSP evaluating a million QPS is paying for the servers that parse, filter and score every one of them, and a large share of that volume is duplicate representations of impressions it will consider once. Cutting paths is one of the few cost levers that does not reduce the addressable inventory.

Fees compounded in ways nobody could see. An impression passing through two intermediaries is subject to two take rates, and historically the buyer could observe neither. As the gap between what advertisers spent and what publishers received became a subject of industry study and client scrutiny, the buy side acquired a strong interest in shortening chains it could not audit.

The paperwork finally made the chain legible. Before ads.txt, sellers.json and the supply chain object, a buyer genuinely could not tell whether two requests were the same inventory arriving twice. Those standards made the chain machine-readable — which is what turned a suspicion into a spreadsheet, and a spreadsheet into a cut list. We covered the mechanics of those files in our ads.txt and sellers.json validation guide; the point here is that their existence is what made SPO operationally possible.

How does a DSP actually rank your path?

Every buyer’s model is different and none of them are published, but the inputs are not mysterious, because they follow from what a DSP is trying to protect: media cost, infrastructure cost and delivery reliability. In rough order of how much they move the decision:

Input What the buyer computes What it decides
Effective cost price paid versus estimated publisher payout, per path whether your fee is competitive for the same impression
Duplication how often your path represents inventory another path also offers whether you are the primary route or a redundant one
Win rate bids submitted versus impressions won on your path whether spending QPS on you converts into delivery
Latency your response time distribution, especially the tail whether you cost them timeouts on paths they would have won
Signal completeness how much of the request is populated whether their targeting and optimization can even engage
Declaration integrity schain, sellers.json and ads.txt agreement whether you are auditable at all

Two observations about this table that operators tend to get wrong.

The first is that win rate is a trap when read alone. A path with a high win rate may simply be one where the buyer faces no competition, which often means inventory nobody else wanted. A path with a lower win rate against strong competition can be the more valuable one. Buyers who rank purely on win rate make mistakes, and the useful response is not to game the metric but to give them the evidence that contextualizes it.

The second is that the bottom two rows are qualifiers, not scores. Failing them does not lower your rank; it removes you from the analysis. That is why they come last in the ranking and first in the remediation.

Fee transparency is the fastest way to get cut

If there is one thing that ends a supply relationship faster than anything else in this article, it is a buyer discovering a fee they were not told about.

The dynamics are worth stating plainly because they are asymmetric. A high disclosed take rate is a negotiation. An undisclosed take rate — of any size — is a trust event, and it generalizes: a buyer who finds one unexplained gap does not adjust your fee estimate, they downgrade their confidence in everything you report. Paths get cut over the second thing, not the first.

The practices that keep you on the right side of this:

Publish the take rate and be able to reconcile it. A buyer should be able to take an auction, apply your stated fee, and land on a publisher payout that matches what the publisher was actually paid. If those numbers do not reconcile, the explanation needs to exist before someone asks.

Take the fee in one place. Fees encoded into bid prices, applied at multiple stages, or varying by demand partner without a stated rule are all forms of the same problem: they make the effective rate impossible to derive from the outside. One fee, applied at a stated point, is auditable.

Do not let net and gross drift between your reports and theirs. A large share of “your numbers do not match ours” disputes are a definitional mismatch rather than a discrepancy. State which side of the fee every figure you publish sits on, everywhere you publish it.

Treat the publisher’s view as the same document as the buyer’s. If a publisher can see what was bid and what they received, and a buyer can see what they paid and what the publisher received, the two views describe one transaction. Platforms where those views are reconstructed separately are where undisclosed spread lives, whether or not anyone intended it.

Duplicate paths: when you and your reseller are the same inventory

This is the mechanic that decides most cut lists, and it is the one operators most consistently underestimate — because from inside a single exchange, duplication is invisible. You see one request for one impression. The buyer sees five.

When a DSP identifies a cluster of paths carrying the same inventory, it keeps the ones that are shortest, cheapest and most reliable. In practice that means the direct path usually survives and the resold paths usually do not, because the resold path carries at least one additional fee and at least one additional hop by construction.

For an exchange this cuts two ways, and both deserve a deliberate decision.

When you resell, you are adding a hop to somebody else’s path. That is defensible when you add something — demand the origin exchange does not have, enrichment that materially improves the request, a market they do not serve. It is not defensible when you are a pass-through, and a buyer running duplication analysis will identify a pure pass-through quickly. The commercial question to ask before taking on resold supply is simply: when this inventory is compared against its direct path, what is our answer?

When you are resold, other people’s hops are attached to your name. Your inventory arrives at buyers through paths you do not control, at prices inflated by fees you do not collect, and the duplication is attributed to your supply. This is the case for knowing who resells you, declaring it correctly in sellers.json, and being able to show a buyer which requests came direct.

The instrument for all of this is the supply chain object. A complete, accurate schain on every request is what lets a buyer distinguish your direct path from a three-hop version of the same impression — and if you are the direct path, that distinction is entirely in your favour. Exchanges that transmit incomplete chains are, in effect, declining to prove the one thing that would save them.

Latency, timeouts and the cost you impose on the buyer

Latency shows up in SPO analysis in a way that surprises people: not as an average, but as a tail.

A buyer’s bid timeout is a fixed budget. When your response arrives after it, the bid does not merely lose — it was never in the auction, and every millisecond spent on it was wasted infrastructure. A path with a good median and a heavy tail costs the buyer more than its average suggests, and DSPs increasingly measure it that way.

The operator-side implications are unglamorous and mostly about consistency rather than speed:

  • Your outbound timeout must be shorter than your inbound one, with enough headroom for your own processing. An exchange that passes through its own timeout has guaranteed that its slowest partner determines whether it responds at all.
  • Timeouts must be enforced, not hoped for. A partner that occasionally takes 400 ms against a 200 ms configuration is a partner whose behaviour is not actually bounded.
  • Failure should be fast and quiet. A demand partner that is down should be dropped from the auction by a circuit breaker, not waited on. Failing fast preserves the auction for everyone else in it.
  • Measure the tail you actually serve. The 99th percentile of your response time, per demand partner, is the number that matches what buyers observe. A median is a number that makes you feel better.

The 200–300 ms budget that a typical DSP allows is not a target to approach. It is a ceiling with everyone else’s latency already inside it.

Signal quality: the tiebreak nobody talks about

Suppose two paths offer the same impression, at the same price, with the same latency and clean declarations on both sides. The buyer keeps one. Which?

The one that describes the impression better. And this is the part of SPO that operators can actually change quickly, because unlike fee structure or duplication, it does not require a commercial renegotiation — it requires filling in fields.

A request that arrives with city-level geography, a resolvable user identifier, a stable placement identifier and populated content categories is a request the buyer’s targeting and optimization can engage with. A request with the same impression described in half those fields will lose on eligibility before price is ever considered. From the buyer’s side this reads as your path performs better, and performance is what the cut list is built from.

This is the commercial argument for everything in our bid request enrichment guide, stated from the buy side: enrichment is not only a per-request revenue lever, it is a path-survival lever. Two exchanges carrying identical inventory can be ranked differently purely on how completely they describe it, and the one that describes it better keeps the spend.

One warning that belongs here rather than anywhere else. The temptation, once you understand that signal completeness affects ranking, is to fill fields with plausible values. Do not. Buyers running SPO analysis are exactly the buyers with the log-level data to notice that your city distribution is too clean or your match rate is impossible, and fabricated signal does not get you ranked lower — it gets you removed and discussed.

The paperwork that gets you disqualified before the analysis

Three files and one object decide whether a buyer can evaluate you at all. None of them earn you anything; all of them can lose you everything.

sellers.json must be complete and current. Every seller ID you transact under needs an entry with the right type — PUBLISHER when you pay the publisher, INTERMEDIARY when you bought it from someone else. Misdeclared intermediary relationships are the single most common finding in supply audits, and they read as either sloppiness or concealment.

ads.txt and app-ads.txt must match reality. Your seller ID needs to appear on the publisher’s file under the right relationship, and it needs to still be there. Entries rot when publishers reorganize their files, and a rotted entry makes your legitimate inventory look unauthorized.

The supply chain object must be complete on every request. Every hop, in order, with the correct hp and node identifiers, and complete set truthfully. A chain that claims completeness while missing a hop is worse than an incomplete one honestly declared.

Your own domain declarations must agree with all three. The most damaging inconsistencies are internal — a seller ID that appears in your sellers.json with one type and in your schain nodes with another. That is not a discrepancy a buyer forgives, because it makes every other number you publish unverifiable.

The good news is that this is the cheapest category of work in this article: it is a validation job with a definite finish line, and it can be automated end to end.

What an exchange should actually do about SPO

A concrete programme, in the order the work pays off:

  1. Fix the declarations. Validate sellers.json, your publishers’ ads.txt coverage and your schain output continuously, not annually. Alert on drift. This clears the qualifier gates.
  2. Know your duplication. For your top inventory, determine which other paths carry it and how many hops they add. You cannot argue you are the primary path without knowing what the buyer is comparing you against.
  3. Make the fee auditable. One fee, stated, reconcilable from the buyer’s side to the publisher’s payout. Fix any place where the effective rate cannot be derived from your own reports.
  4. Bound the tail. Enforce outbound timeouts, break circuits on failing partners, and monitor the 99th percentile per demand partner rather than the mean.
  5. Close the signal gaps. Measure fill rate per enrichable field and fix the biggest gaps first. This is usually the fastest win available, and it compounds with everything else.
  6. Then go and talk to your buyers. Once the first five are true, ask your largest demand partners where you sit in their path analysis. Buyers running SPO programmes are, in our experience, unusually willing to say — the analysis is expensive for them too, and a supply partner who wants to fix things is cheaper than a replacement.

The sixth step is the one that gets skipped, and it is the only one that tells you whether the other five worked.

The publisher’s side: your own path count

If you operate an exchange you are also, usually, somebody’s supply — and the same logic applies inward.

Publishers spent a decade adding demand partners on the theory that more competition raises clearing prices. Past a point it does not: each additional partner adds page weight or server cost, adds another copy of the impression into the ecosystem, and dilutes the volume any single partner sees, which weakens the performance history their optimizers depend on. Meanwhile the duplication you are creating is being counted against every path carrying your inventory.

The audit is straightforward and worth running annually: for each demand partner, what share of revenue do they actually contribute, and what would happen if they were removed? A meaningful number of partners on a typical setup contribute a rounding error while adding a full copy of your inventory to the duplication analysis. Removing them costs almost nothing and makes the paths you keep measurably cleaner.

The Prebid.js and Prebid Server trade-offs are the practical version of this question: server-side consolidation reduces the client-side cost of running many partners, which changes where the line sits — but it does not remove the line.

What SPO does not mean

Four misreadings, each of which produces bad decisions.

It is not a race to the lowest fee. Buyers consolidate onto paths that deliver, not paths that are cheapest. A path with a higher disclosed fee and materially better signal, reliability and inventory access wins against a cheap pass-through. The fee has to be defensible and visible, not minimal.

It is not “direct is always better”. A direct path with poor signal, a heavy latency tail or unreliable declarations loses to a well-run intermediary. Directness is an advantage to be spent, not a guarantee.

It is not a one-time project. Path analysis is re-run continuously, and your position moves when your competitors change, not only when you do. A clean audit last quarter is not a position this quarter.

It is not only about you. Much of what determines your ranking is the behaviour of intermediaries reselling your inventory and publishers listing you alongside a dozen alternatives. Knowing who resells you, and what your publishers’ files say, is part of managing your own path.

Key takeaways

  • SPO is a decision buyers make about you. Your influence is over the inputs, not the outcome.
  • The evaluation is relative: you are ranked against the other routes to the same impression, so being well-run is not sufficient.
  • Declarations — sellers.json, ads.txt, schain — are qualifiers. Failing them removes you from consideration entirely.
  • Undisclosed fees end relationships faster than high fees. One fee, stated once, reconcilable from both sides.
  • Duplication decides most cut lists. The direct path usually survives; a pass-through reseller usually does not.
  • Latency is judged on the tail, not the average, because the tail is what costs the buyer timeouts.
  • Signal completeness is the tiebreak between otherwise equivalent paths, and it is the input you can improve fastest.
  • Ask your buyers where you rank. It is the only step that verifies the others.

Running a clean supply path on Floxis

Floxis is a white-label RTB exchange you run as your own — your domain, your branding, your margin — and most of the SPO checklist above is platform behaviour rather than a project you staff.

The supply chain object is transmitted in full on every request, and ads.txt, app-ads.txt and sellers.json validation is built in and continuously re-crawled rather than checked at onboarding, so declaration drift surfaces as an alert instead of a buyer’s audit finding. Fees are configured in one place and visible on both sides of the transaction: the same log-level reporting that shows a buyer what cleared shows the publisher what they earned, roughly a minute behind the event. Per-endpoint QPS, timeout and schain configuration means outbound bounds are enforced per demand partner rather than inherited, and demand-side reporting breaks out win rate, latency and drop reasons per endpoint — which is the same evidence your buyers are using, before they use it.

On the signal side, requests are enriched before they leave: geography resolved to city, region, metro and time zone; identity restored where a wrapper hop dropped it; a stable placement identifier synthesized where supply omits one; content categories and language filled from the property record. That is the tiebreak input, and it is on by default rather than a professional-services engagement.

If you are evaluating platforms, the SPO questions belong beside the ones in our white label ad exchange guide: is schain complete on every request, can the fee be reconciled from both sides, and can you see per-endpoint latency at the tail. Book a demo and we will walk your own supply mix through the checklist above.

Sources worth bookmarking