Blog/Publisher

CTV Supply Path Optimization: app-ads.txt, sellers.json, and Transparent Demand

Supply path optimization in CTV means more than trimming SSP hops. app-ads.txt, sellers.json, schain objects, latency budgets, and inventory quality signals are the full picture of supply chain transparency for publishers and buyers.

MS

Manmohan Singh

Head of CTV Product, LtvAdx

2026-05-07 · 13 min read

CTV Supply Path Optimization: app-ads.txt, sellers.json, and Transparent Demand

Supply path optimization (SPO) was initially a buyer-side discipline: DSPs and agencies auditing the number of SSP hops between their bid and the publisher impression, pruning redundant paths, and concentrating spend with supply partners who could demonstrate transparent fees, authoritative sellers.json declarations, and low latency. In CTV, SPO has taken on a different and more consequential shape. The television advertising supply chain carries more complexity than web display — multiple SSP integrations on the same publisher, reseller chains of varying transparency, SSAI stitchers inserting themselves between the auction and the manifest — and the stakes of supply chain opacity are higher because CTV CPMs are substantially larger than display. This guide explains how SPO works in CTV, what both publishers and buyers should understand about it, and how the LtvAdx ad server and exchange infrastructure are designed to minimize supply chain friction.

Why CTV has a supply path problem

A single CTV impression can travel through a chain that involves the publisher's app, an SSAI stitcher, one or two SSPs, a header bidding wrapper adapted for TV environments, a DSP, a trading desk, and an agency buying platform — each layer adding latency, taking fees, and creating a potential point of misrepresentation. The buyer's DSP pays a CPM that includes all of these fees; the publisher receives what remains after each layer extracts its margin. In programmatic display, this chain is well-documented through ads.txt and sellers.json and is increasingly enforceable. In CTV, the equivalent declaration mechanisms — app-ads.txt and sellers.json — are in place but not universally implemented, creating opacity that SPO is designed to eliminate.

The second CTV-specific complexity is the SSAI layer. In a server-side insertion path, the SSAI stitcher makes the ad call to the SSP or exchange rather than the player. The bid request originates from the stitcher's infrastructure, not the viewer's device. This creates a measurement challenge: device-level signals (device type, platform, OS version) must be passed through the stitcher rather than observed directly by the buying platform. Stitchers that do not accurately forward device signals produce bid requests that misrepresent the viewer environment, which is both a measurement problem and a supply quality problem that SPO surfaces.

The LtvAdx SSAI engine forwards all device and content metadata accurately in outbound OpenRTB bid requests, including device type, platform identifier, app bundle, content genre, and SSAI path indicator signals. Publishers on the LtvAdx exchange have a single authoritative supply path — from publisher app through LtvAdx SSAI to LtvAdx SSP — rather than a fragmented web of stitcher-plus-multiple-SSP configurations that buyers struggle to audit.

app-ads.txt: the declaration standard for CTV

The IAB's app-ads.txt specification extends the ads.txt domain authorization framework to mobile apps and CTV apps distributed through app stores. Publishers declare which SSPs and exchanges are authorized to sell their inventory by maintaining an app-ads.txt file hosted at their developer domain, referenced from their app store listing. DSPs that enforce app-ads.txt compliance — which all major programmatic buyers do as a baseline quality control — will reject bid requests from apps whose app-ads.txt does not include the selling platform.

Correct app-ads.txt setup requires: a developer domain claimed in the app store listing, an app-ads.txt file hosted at the root of that domain, and accurate entries declaring each authorized seller with the correct account ID and relationship type (DIRECT or RESELLER). Publishers who route inventory through LtvAdx must declare LtvAdx as a DIRECT relationship with the LtvAdx publisher account ID. Any intermediate platform that resells the inventory must be declared as a RESELLER with its own seller account ID.

A common SPO failure point is outdated app-ads.txt: a publisher adds LtvAdx but retains stale entries for SSPs they no longer work with. Buyers running SPO filters may penalize impressions from apps with unusually large numbers of authorized sellers, treating it as a signal of poor supply chain hygiene. Audit your app-ads.txt quarterly and remove entries for inactive supply relationships. The LtvAdx getting started guide provides the exact app-ads.txt entry format required for correct publisher authorization.

sellers.json and the buyer's view of the supply chain

Sellers.json is the counterpart to app-ads.txt: maintained by the SSP or exchange rather than the publisher, it declares every publisher and intermediary that is authorized to sell inventory through that platform. A buyer's DSP can download the LtvAdx sellers.json, look up a publisher ID from a bid request, and confirm that the publisher is a known, declared participant in the LtvAdx exchange rather than an undeclared reseller or spoofed bundle.

The sellers.json specification also distinguishes between PUBLISHER (direct supply owner), INTERMEDIARY (a network or aggregator reselling multiple publishers' supply), and BOTH (a platform that owns some inventory and resells others). This classification is relevant for SPO because buyers often apply different CPM floors, deal requirements, or traffic quality weightings to PUBLISHER versus INTERMEDIARY entries. LtvAdx maintains a current sellers.json with all active publisher accounts classified correctly — publishers should verify their entry reflects the current relationship type and contact publisher support if corrections are needed.

Supply chain transparency: schain objects in bid requests

The IAB SupplyChain (schain) specification adds a machine-readable transaction history to every bid request, declaring every system through which the inventory passed before reaching the DSP. Each node in the schain object carries the platform domain, account ID, and relationship type. A bid request with a complete, accurate schain gives buyers the ability to verify the entire supply path — not just the final SSP — against their own authorized vendor list.

In OpenRTB 2.6, schain is included in the request by default when multiple parties are involved in the supply path. For LtvAdx publishers selling directly through the LtvAdx exchange, the schain is a single-node declaration: the publisher is the only intermediary, and buyers can confirm they are buying directly from the source. Publishers who also route inventory through other SSPs should ensure those platforms also maintain accurate schain declarations to avoid being penalized in SPO filters as an opaque supply source.

Latency and timeout management in CTV SPO

Supply path length is not only a transparency problem — it is a latency problem. Every additional hop in the supply chain adds milliseconds to the time between the SSAI stitcher's ad call and the creative being available for manifest stitching. CTV players have short timeout windows before they insert slate or skip the break. A supply path with three SSP hops and a DSP that takes 120ms to respond has already consumed most of the available timeout budget before the creative even begins to load.

LtvAdx targets sub-10ms VAST response times at the publisher edge, which preserves the timeout budget for the downstream programmatic call rather than consuming it at the ad server layer. For publishers with complex supply configurations — multiple SSPs, header bidding adaptors, and direct IO — the total latency budget must be allocated deliberately. Configure timeout values in the publisher portal to match your actual demand response time distribution: setting timeouts too tight excludes valuable demand; setting them too loose increases slate insertion on slow-response auctions. The reporting dashboard surfaces timeout rates by demand source and by supply path so latency-driven fill gaps are identifiable.

The buyer's SPO perspective: preferred paths and fee transparency

From the buyer side, supply path optimization in CTV means identifying the shortest, most transparent path to the publisher impression and concentrating spend there. This typically manifests as: preferring direct SSP-to-publisher paths over reseller chains, weighting deal ID-based buying over open auction (because deals require publisher authorization), and deprioritizing supply sources that cannot be validated against app-ads.txt and sellers.json.

Fee transparency is a core SPO metric. A publisher's gross CPM — what the advertiser pays — minus the LtvAdx platform fee equals the publisher's net revenue. Intermediaries with opaque fees extract margin without declared authorization; SPO eliminates them because buyers deprioritize bid requests from supply chains they cannot fully account for. LtvAdx discloses platform fees in the pricing documentation and surfaces gross-to-net reconciliation data in publisher revenue reporting, enabling publishers to compare LtvAdx net revenue against other supply paths using the same gross CPM denominator.

Agencies running formal SPO programs — typically top-10 holding companies with dedicated programmatic operations teams — maintain preferred supply partner lists that channel buying toward platforms that meet transparency, quality, and fee criteria. LtvAdx's single-stack architecture (ad server, SSAI, and SSP in one platform rather than three separate vendors) simplifies the SPO audit because there is one seller entity, one sellers.json entry, and one fee disclosure rather than the distributed accountability of a multi-vendor supply chain. The LtvAdx agency portal provides the reporting depth and supply chain documentation that SPO programs require.

Inventory quality signals in CTV programmatic

Beyond supply path transparency, SPO in CTV involves inventory quality assessment: is this impression from a real CTV device, watching real content, in the context the publisher declared? The CTV inventory quality signals that matter for SPO are: device identifier type (platform-issued advertising ID versus synthesized or spoofed ID), app bundle authenticity (cross-validated against app-ads.txt), content metadata accuracy (declared genre matches ACR or content API verification), and traffic behavior patterns (impression timing, session length, frequency patterns consistent with legitimate viewing).

Impression fraud in CTV is lower than in web display but not absent. Server-side ad injection — where a server generates fake VAST impression events without any real viewer — is the primary CTV fraud vector. VAST verification nodes in VAST 4.2 and player-level beacon validation help distinguish stitcher-fired events from player-fired events, providing a verification signal that SPO-focused buyers can require in deal terms. LtvAdx validates publisher traffic at onboarding and on an ongoing basis using session behavior analysis and device ID verification to maintain inventory quality standards across the exchange.

SPO configuration for FAST channel operators

FAST channel operators have a specific SPO consideration: multiple distribution platforms (Roku, Samsung TV Plus, LG Channels, Amazon Fire TV) may each have their own ad serving relationships alongside the operator's primary exchange. This creates a situation where the same FAST channel content is available through multiple supply paths simultaneously — the operator's direct programmatic path, the distribution platform's own ad serving, and any aggregator network that has licensed the channel for distribution.

SPO for FAST operators requires a clear primary path designation: which supply path is the authoritative, lowest-fee route to this inventory? Typically this is the operator's own exchange relationship — in this case, LtvAdx — with platform distribution paths designated as secondary fills for impressions not sold through the primary path. Configuring this correctly requires app-ads.txt entries that list the primary seller as DIRECT and platform distributors as RESELLER, and maintaining deal structures through the primary path that give preferred demand priority before platform-side backfill. The FAST channel solutions documentation covers this configuration for operators managing multi-platform distribution.

Practical SPO checklist for CTV publishers

A publisher SPO audit should verify the following elements on a quarterly basis. App-ads.txt is current, with active supply relationships declared and inactive ones removed. Sellers.json entry is accurate with the correct relationship type. Schain is passing correctly in outbound bid requests with all nodes declared. Timeout values are calibrated to actual demand latency distributions. Fee structures are documented and reconcilable in net revenue reporting. Traffic quality monitoring is active with alerts on device ID anomalies and impression timing irregularities.

For publishers configuring SPO settings on LtvAdx, the publisher portal exposes supply chain configuration, timeout management, and traffic quality reporting in a single interface. The developer API provides programmatic access to supply chain configuration for operators managing large publisher portfolios. Publishers new to SPO concepts should review the brand safety and supply chain guide alongside this document for the complete picture of supply quality management. To discuss SPO configuration for your specific inventory architecture, contact the publisher team or request a platform demonstration.

Stay ahead of CTV and addressable TV

Get articles on streaming monetization, identity, and programmatic TV.

Subscribe + request demo →
MS

Manmohan Singh

Head of CTV Product, LtvAdx

2026-05-07·13 min read

Related articles

Start trading TV

Ready to monetise CTV inventory?

See how LtvAdx fits your streaming and addressable TV setup — start free or book a walkthrough.

No minimum spend48-hour account reviewVAST 4.2 + SSAI docs includedIAB-compliant stack
Live network

2.4B+

Impressions today

Across CTV & linear pods

Live network

8.2ms

Median VAST latency

p99 under 15ms at edge

Illustrative platform metrics · System status

VAST 4.2VMAP 1.0.1OpenRTB 2.6schainTCF 2.2CCPASCTE-35HouseholdID