Supply Path Explorer

See who sells a property, and which seller IDs they use on each exchange.

Property
Not chosen
Period
Trailing 30 days

Connect to the Data API

Your key stays in this browser tab and is sent only to the Jounce Data API.

About This Data

  • A website matches its ads.txt domain on Web inventory; an app matches its bundle ID. Both must match exactly, ignoring case.
  • Share of supply is the share of observed bid requests and share of demand the share of observed DSP spend, over the trailing 30 days, across all exchanges. Each column is rescaled so the property totals 100%.
  • A path is a distinct seller ID on an exchange for that seller, directness and classification on this property. Only exchanges Jounce has mapped to a parent organization are included. The Exchange menu narrows the seller IDs to one exchange and greys out sellers with no paths on it; the seller mix itself always covers all exchanges.
  • Path shows how a seller reaches the exchange. Direct and Content Syndication sellers sell to the exchange themselves. For anyone else, the page checks where that seller is itself the exchange on this property: if any of those paths is direct, it buys from the primary seller; if none is, it buys only through other intermediaries; if there are none, its source is unknown (?). Hover a path for the details.
  • The classification shows the directness alongside it when the two differ, for example Premium Proprietary Placement.
  • The ads.txt location is the publisher domain’s ads.txt for Web inventory and its app-ads.txt for apps.
  • Environment and primary seller come from the same 30-day data; where a property has several, the one with the most requests is shown first. The classification mix shows requests and spend side by side, each as 100%.

API Calls

Every request this page makes to the Jounce Data API, in order, with why it is made and the exact body sent. Open a call to copy it as curl.

  1. Check the key. A one-row search; a 401 means the key is wrong. Every request sends Authorization: Bearer <key>.
  2. Find the property and load its seller mix. One Monetization search returns the property’s rows grouped by seller, directness, classification, environment and primary seller, with summed shares. That single response fills the summary and the table.
  3. Prefetch every seller ID. For a website this starts at the same moment; for an app, as soon as step 2 returns the app’s publisher domains, which make the search much faster. One Classifications search returns every seller ID on every mapped exchange (exchange parent ID not null) for the property, so the Path column fills in and every row opens with no further request. The Exchange menu filters this same result in the browser, so choosing an exchange makes no new request. For apps, a second search fetches the app name.
  4. Background jobs. Classifications searches can outlast the ~30s an upstream gateway allows, so they send Prefer: respond-async with an Idempotency-Key, get a job back at once, poll /v1/query-jobs/{id} and then fetch /v1/query-jobs/{id}/result. Jobs no longer needed are cancelled with POST /v1/query-jobs/{id}/cancel.