Buyer readiness

Supply path transparency checklist

A private marketplace package is easier to trust when the commercial path, seller authorization, page placement, and final reporting fields all point to the same inventory story.

Use this checklist before a publisher package, managed demand path, or private marketplace deal goes live. It helps buyers, publishers, and operations teams inspect the supply path without turning seller transparency into a performance claim. The goal is a campaign record that can answer: who is allowed to sell this inventory, which package did the buyer activate, which placement rendered, and what reporting fields survived the flight?

Picture the launch review for a new contextual package. The seller authorization row looks clean, the deal key has been created, and the buyer is ready to approve spend. The weak point is the handoff: no one has checked whether the public seller files, bid-path evidence, deal mapping, placement IDs, and final export will still describe the same inventory after the campaign runs.

Supply-path transparency review desk connecting public seller records, deal setup, and campaign reporting before launch.
Start the review by putting the public seller record, deal setup, placement record, and reporting export on the same desk. The transparency question is whether one campaign story survives across all of those records.
Advertisement

What to reconcile

Supply path transparency is a join problem. The public seller file, the bid path, the deal setup, and the campaign report should not require four different stories to explain the same impression.

Layer stack showing seller authorization, seller disclosure, transaction path, deal setup, placement, and reporting alignment.
The layer stack keeps the review from stopping too early. A package can have an authorized seller row and still need seller disclosure, path sequence, deal key, placement, and reporting fields to line up.
LayerCheck before launchHold or fix when
Publisher domainThe public seller file is reachable from the expected root domain and matches the inventory owner or authorized manager named in the campaign brief.The buyer is asked to accept a domain, subdomain, or managed path that does not match the package evidence.
Authorized seller rowThe seller account, ad system domain, relationship type, and optional owner or manager fields are recorded in the launch notes.The seller row is missing, stale, duplicated without explanation, or cannot be tied to the deal path.
Seller disclosureThe selling system's seller record can be checked against the account ID used in the authorized seller row.The seller record is confidential, missing, or materially different from the campaign path without a written reason.
Supply chain objectThe bid path shows the sequence of sellers and intermediaries expected by the buying path.The path adds unexpected nodes, hides the final seller, or changes after launch without a change log.
Deal keyThe private marketplace deal key maps to one package ID, eligible placement set, and reporting key.The same deal key is used for unlike contexts or multiple package definitions.
Placement and reportThe final report can show package ID, placement ID, device class, creative ID, seller path status, and any supply-path exception.Delivery can only be read as a total, with no join back to the package and seller evidence.

Preflight checklist

Supply-path transparency preflight workflow from seller file capture through path matching, deal binding, exception logging, and launch decision.
The preflight workflow turns transparency into a launch record. Capture the public seller state, match the seller account, write the expected path, bind the deal key, and keep exceptions visible before spend begins.
1. Capture the public seller state.

Save the authorized seller rows that apply to the package, including ad system domain, publisher account ID, relationship type, and any owner or manager fields. Treat this as a launch record, not as proof that the campaign will work.

2. Match seller records to the account ID.

Check whether the seller account used for activation appears in the selling system's seller disclosure. Record whether the seller is direct, intermediary, or confidential, and whether that status matches the buying path.

3. Write down the expected path.

Before launch, name the expected seller path: direct publisher sale, managed publisher sale, reseller path, or private marketplace path through a named buying route. The report should flag delivery that does not follow that expected path.

4. Bind the deal key to a package.

A private marketplace key should map to one package thesis, one included URL or topic set, one placement set, and one reporting key. If the package changes, record the date and the reason.

5. Keep exceptions visible.

If a row is pending, confidential, manager-owned, reseller-only, or missing a seller disclosure, name that condition before launch. Hidden exceptions become expensive during billing, renewal, and performance review.

Read the public files carefully

The public seller files support transparency and authorization checks. They do not establish viewability, audience quality, lead quality, or incrementality.

EvidenceWhat it can supportWhat it cannot support alone
ads.txt or app-ads.txt rowThe publisher has declared a seller account and relationship for a domain or app context.That the impression was viewable, high quality, or incremental.
sellers.json recordThe selling system has published seller information connected to seller IDs, subject to its disclosure status.That the buyer's package, page context, or creative actually matched the plan.
SupplyChain objectThe bid request can expose the sequence of nodes involved in the transaction.That the commercial path is the shortest, cheapest, or best-performing path.
Deal keyThe buyer activated a named commercial path for a package or placement set.That all delivered impressions matched the intended page context.
Placement IDThe report can tie delivery to a visible page slot and size family.That the seller path was clean unless seller-path fields are also preserved.
Seller-path exception logThe team can explain row changes, confidential records, added intermediaries, or managed supply paths.That the exception had no effect on delivery quality or renewal evidence.
Advertisement

Reporting fields

Supply-path fields should sit beside the normal package, placement, creative, and outcome fields. They are most useful when the readout shows what was eligible, what delivered, and what could not be verified.

FieldDefinitionUse in readout
supply_path_statusExpected, changed, pending, confidential, unmanaged, or not checked.Shows whether delivery followed the path agreed before launch.
seller_relationshipDirect, reseller, intermediary, managed, or unknown.Separates direct publisher supply from managed or reseller paths.
seller_account_idThe seller account used in public authorization and activation records.Lets ad operations reconcile seller files, deal setup, and invoice records.
ad_system_domainThe advertising system domain declared for the seller account.Connects public seller authorization to the system where buying occurred.
schain_node_countThe number of nodes visible in the supply chain record when available.Helps flag unexpected path length changes before renewal language is written.
seller_path_exceptionA short explanation for missing, confidential, changed, or unexpected seller-path evidence.Keeps unresolved transparency questions out of performance claims.
package_idThe contextual package sold to the buyer.Connects seller-path checks to the reader context being purchased.
placement_idThe visible ad slot or placement contract where the unit rendered.Prevents seller-path review from floating above page-level delivery evidence.

Worked decision map

Use the same supply-path evidence to choose the launch or renewal language. The decision is not simply pass or fail. Some issues need an operations fix, some need a named exception, and some should stay out of a buyer-facing clean-path claim until the path is rebuilt.

What the evidence showsQuestion to ask before wordingStatus bandCareful buyer-facing language
Authorized seller row, seller disclosure, expected path, deal key, package ID, placement ID, and export fields all align.Can the report preserve the same identifiers after launch?Ready for package activationThe package has a documented seller path and can be read by package, placement, device, and seller-path status after delivery.
The package and placement evidence are sound, but one seller row is stale or a seller record needs an account-ID correction.Who owns the correction and when will the corrected row be captured?Ready after operations fixThe package can proceed after the seller-record fix is completed and attached to the launch handoff.
The seller record is confidential, manager-owned, or routed through a managed path that was disclosed before launch.Will the exception appear in the final export and renewal memo?Report with exceptionThe campaign can be described with a named seller-path exception, not as a fully clean direct path.
A new intermediary appears after launch, the SupplyChain sequence changes, or no change log explains the path difference.Can delivery be split before the path changed and after it changed?Hold for path reviewDo not use clean-path language until the changed route is explained and separated from the report total.
One deal key covers unlike page groups, placement sets, or package promises.Can the deal be split into package-specific IDs before launch or renewal?Hold or rebuild the packageThe buyer should see separate package IDs before the readout claims a specific inventory promise was delivered.
Supply-path transparency decision board sorting clean launch, operations fix, named exception, and hold-for-path-review outcomes.
The decision board keeps the final recommendation bounded. Clean paths, operations fixes, named exceptions, and hold decisions should be separated before the campaign is approved or renewed.

Decision bands

StatusUse whenNext action
Ready for package activationAuthorized seller rows, seller records, expected path, deal key, package ID, and report fields align.Launch with the seller-path fields included in the campaign export.
Ready after operations fixThe package and inventory are sound, but one seller row, seller record, or deal mapping needs correction.Fix before launch, then document the correction in the campaign handoff.
Report with exceptionDelivery can run, but a seller record is confidential, pending, or routed through a managed path.Name the exception and keep performance language descriptive.
Hold for path reviewThe seller path cannot be tied to the package, placement, or deal key.Do not sell or renew the package as a clean private marketplace lane until the path is rebuilt.

Official references

Use official technical references to define the transparency fields, then use the campaign's own records to judge whether a specific package was ready. The IAB Tech Lab ads.txt reference explains authorized seller declarations, the IAB Tech Lab sellers.json and SupplyChain reference explains seller disclosure and supply chain visibility, and the source library groups these references with other measurement and inventory checks.

Pair with

Use this checklist with the programmatic inventory QA checklist for placement and size-map checks, the ad yield and deal-readiness checklist before pricing, the private marketplace reporting field dictionary for package and placement fields, the private marketplace readout export sample for row-level checks, and the ad inventory readiness matrix for the current package contracts.

Takeaway

A transparent supply path is not a performance result. It is a necessary record that lets buyers and publishers know which inventory was authorized, how it moved, where it rendered, and how much confidence the final report deserves.

Keep reading

Choose the next inventory check

Move from this page into slot contracts, supply-path evidence, and yield-readiness checks before adding demand.