CNN.com

2. The stack at a glance

3. Wrappers and adapters detected

Eleven wrappers detected at the page lifecycle level. Each wrapper is a gateway into a wider demand pool, not a single bidder. A single Prebid adapter call to Criteo can route to dozens of advertisers via Criteo's own auction. A single Amazon TAM call routes to the full TAM bidder list. The 11 here counts integration surfaces fired in the browser, not buyers competing in the auction. Rows are ordered by bid volume.

4. Supply path coverage

This is the section that only a live wire capture can produce. Static analysis can tell you which wrappers a stack uses. It cannot tell you which of them are actually passing the supply chain signal that downstream buyers verify against.

5. Auction timing analysis

Two configuration patterns show up clearly in the timing capture. The first is a wrapper-level tmax misconfiguration on PubMatic OpenWrap. The second is a stack-wide pattern of bidder responses arriving after the auction has already closed. Combined, the result is a bid timeout rate of 89% across the captured session. Eight of every ten bidder attempts never make it back in time to compete.

The premium ATF banner is decided by one bidder

The headline above-the-fold banner (ad_bnr_atf_01) was attempted by all eleven bidders during the session. The breakdown of responses vs timeouts on this single slot is the cleanest illustration of the structural problem.

With one bidder consistently responding and ten consistently absent, the slot is not generating competitive price pressure in this session. The one bidder responding is TTD via a direct DSP integration rather than an SSP forwarding multiple buyers, so the auction's competitive structure (multiple SSPs each forwarding their own demand pool) is not producing observable pressure on the clearing price on this slot in this window.

Why this happens

Two non-mutually-exclusive root causes match the data:

1. 1.

   Auction start timing.

   Prebid's requestBids() fires before the ad slots are fully defined in the DOM. Every bidder is racing a clock that started early. The documented Prebid pattern (see the basic example) is to call requestBids inside a googletag.cmd.push callback after slot definition, then call setTargetingForGPTAsync in the bidsBackHandler before googletag.pubads().refresh(). If the wrapper does this in a different order, every bidder sees a tmax that has been ticking since before they were given anything to bid on. This is the most likely cause of the six bidders at 100% timeout rate.

2. 2.

   Per-bidder tmax misconfig.

   The PubMatic case above is the clearest example: a bidder whose p50 latency is 1,236ms placed on a 300ms shelf. Per the Prebid timeout-defaults docs, the default bidder timeout is 1,000ms with failsafeTimeout at 1,100ms; managed wrappers and direct integrations often need 1,250-1,500ms. Per-bidder overrides are explicitly supported via pbjs.bidderSettings.<bidder>.bidderTimeout = N.

The TTD, IX, Medianet bidders that did respond all show p95 latencies of 3,000+ms while the wrapper tmax is 1,250ms. This means even the bidders that respond have their slow tail killed by the timer. Setting failsafeTimeout above the bidder timeout, as Prebid recommends, would let in-flight bids land after tmax expires without blocking the auction render. That is a wrapper-level config that the publisher controls directly.

Verify in your own Chrome DevTools

Everything counted above is observable in plain Chrome DevTools with no extension at all. Open DevTools, switch to the Network panel, filter by Fetch/XHR, and reload www.cnn.com. You will see the same ten bidder requests get aborted as the tmax timer expires.

Three observations from the network layer that the bidder-timing capture above does not surface directly:

• 1.

  Ten bidders aborted in a 40ms window around 1,000ms.

  TTD, Index Exchange, Media.net, Criteo, Magnite Fastlane, Magnite Prebid Server, TripleLift, PubMatic OpenWrap, Teads, and PubMatic all show status canceled at 1.00-1.04s with 0kB returned. That cluster is the network-layer signature of Prebid's bidTimeout event firing. It is also tighter than the 1,250ms tmax shown in tmaxByWrapper, which suggests a separate failsafeTimeout at ~1,000ms is overriding per-wrapper tmax stack-wide. Both ride in the same Prebid timeouts config (see the Prebid timeout-defaults doc).

• 2.

  Kargo's own telemetry confirms the timeout from the SSP side.

  The 200 OK request to krk2.kargo.com/api/v1/event is Kargo's client-side ping back to its own servers, and the URL parameter is literally named timeout. Kargo is logging on its own side that this page killed its bid before it could respond. SSP account teams can pull these telemetry reports for any given publisher; the evidence the timeout is happening exists on both sides of the wire.

• 3.

  Prebid runs inside an anti-tracking iframe.

  Every bidder request in the panel above shows frame_ant.js:2 as its initiator. The ant prefix is CNN's anti-tracking iframe wrapper, which means every bid request crosses an iframe boundary on its way out. This is a defensible privacy architecture but adds latency overhead to every bidder request, compounding the tmax pressure documented above.

The takeaway: the findings in this section do not rely on a proprietary capture tool. Anyone at CNN's ad ops team (or anyone evaluating this teardown) can reproduce the timeout pattern by opening Chrome DevTools on www.cnn.com. The Beamflow capture adds bidder-level attribution and the per-bidder response/timeout breakdown; the network-layer evidence stands on its own.

Two views. First, the per-wrapper authorization status as observed in the runtime session above. Second, the full ads.txt and sellers.json audit across every declared seller on the file (not just what fired in this session), run through Beamflow.co.

6a. Per-wrapper authorization (this session)

Authorization is the second half of the supply chain story. Even if a bid carries a chain, downstream buyers verify the path against the publisher's ads.txt and each declared SSP's sellers.json. A break anywhere in that path means the buyer either skips the bid or prices it lower.

Per-wrapper status

6b. Full ads.txt audit via Beamflow.co

The runtime view above only covers what fired in the 5-minute session. The full picture lives in the publisher's ads.txt file itself, which declares every seller authorized to monetize cnn.com inventory. Beamflow.co crawls that file and cross-references every entry against the corresponding SSP's sellers.json. Server response: HTTPS, 30ms response, 2 redirects, text/plain.

7. What this site gets right

Architectural and configuration choices in the CNN.com stack worth copying or benchmarking against.

1. 1.

   Wunderkind and PubMatic OpenWrap pass schain on 100% of bids (wire-level)

   Two wrappers in the stack pass the schain parameter on every bid request fired in the browser: Wunderkind on all 47 of its bids, PubMatic OpenWrap on all 9. That demonstrates the per-wrapper config can be set correctly. The other wrappers may or may not be adding schain server-side (we cannot tell from a wire capture), but where the wire reads zero, the fix lives in per-wrapper config. (See the timing section for a separate issue with PubMatic that makes its 100% schain coverage less useful than it should be in this session.)

2. 2.

   ads.txt authorization is clean at the publisher level

   Of 462 programmatic bids, 377 (82%) verify cleanly against the publisher's ads.txt with zero "not authorized" entries. Earlier captures of CNN properties showed not-authorized counts in the 13-44 range; the current zero is a meaningful improvement. The 18% unverified portion is entirely SSP-side sellers.json gaps (notably Criteo's missing file), not publisher-side ads.txt issues.

8. Findings and open questions

Observations and open questions about the stack, ordered by estimated yield and risk impact.

1. 1.

   89% bid timeout rate across the session is the headline operational issue

   Of 463 bidder-level attempts across the captured session, 412 timed out before a response could land (51 responded inside tmax). Six bidders (TripleLift, Nativo, OpenWeb, Criteo, Kargo, Teads) returned zero measurable responses across the entire 5-minute window. The headline ATF banner slot was attempted by 11 bidders, with only one (The Trade Desk) consistently responding. With one bidder consistently in the auction and ten consistently absent, the slot is not generating competitive price pressure. Per Prebid's documented auction patterns, the most common root cause is auction-start timing relative to ad slot DOM creation (the auction timer starts before slots are defined, so bidders are racing a clock they cannot see). The secondary contributor is per-bidder tmax misconfig (see Finding 2). Both are correctable in the wrapper config. Refined estimate: independent verification in Chrome DevTools (see the new subsection at the end of Section 5) shows ten bidder requests aborting in a tight 1.00-1.04s cluster, which suggests the operative tmax is closer to 1,000ms than the 1,250ms reported in tmaxByWrapper. A tighter failsafeTimeout is likely overriding per-wrapper tmax stack-wide.

2. 2.

   PubMatic OpenWrap is misconfigured on the wrong tmax shelf

   PubMatic's measured p50 latency in this session is 1,236ms. Its configured tmax is 300ms. The result is a 91% bid timeout rate on the wrapper. The 300ms shelf is reasonable for very-fast in-page banner adapters but PubMatic OpenWrap is a managed wrapper that orchestrates a server-side auction with multiple downstream demand sources; its real-world latency budget is closer to 800-1500ms. Ironically, PubMatic is the only wrapper passing schain on 100% of bids in the session, so the schain config is correct, but the timing config makes the schain config moot because no bid lands in time. Fix: move pubmatic.com to the 1250ms shelf, or set a bidder-level override via pbjs.bidderSettings.pubmatic.bidderTimeout = 1250.

3. 3.

   Schain coverage gap: 9 of 11 wrappers pass it on 0% of wire-level bids

   15% of bid requests in the session carry the IAB SupplyChain object (schain) in the wire-level OpenRTB payload. Two wrappers (Wunderkind, PubMatic OpenWrap) pass it on 100% of bids. One (The Trade Desk direct) passes it on 36%. Eight others (Criteo, Magnite, Amazon TAM, Index Exchange, TripleLift, Media.net, Nativo, Kargo) show 0% wire-level. Amazon TAM is a known server-side case, so its zero is expected. For the other seven, the wire-level zero is what the browser-facing bid request shows; server-side behavior is not always public, and some SSPs may add schain on their backend before forwarding to demand. The publisher's correct move is to confirm with each SSP rep what happens server-side, then act on the per-wrapper config gap where it remains. Per Prebid's schain module docs, the global config via pbjs.setConfig({schain: ...}) should be sufficient for most adapter wrappers; for managed wrappers and direct integrations, the config lives in each vendor's own admin UI.

4. 4.

   Criteo sellers.json was missing at scan time

   Criteo fired 85 bids in the session, the highest bid volume of any wrapper. The criteo.com domain returned no sellers.json when the audit ran. That is a Criteo-side problem (the SSP is supposed to publish this file), not a publisher-side problem, but the practical effect is that buyers cannot verify the chain end-to-end for any of those 85 bids. Worth raising with the Criteo account manager and re-scanning periodically because sellers.json availability can flip without notice.

5. 5.

   Wrapper stack appears geo-segmented between US and international CNN properties

   A separate capture on edition.cnn.com (CNN's international property, run during tool development before this issue went to draft) showed a materially different wrapper stack than the one published here. The international property had Sharethrough and The Ozone Project (a UK-focused header bidding consortium) actively participating, neither of which appears on the US property captured for this issue. The US property shows Wunderkind, Media.net, Kargo, TripleLift, Nativo, OpenWeb, and Teads instead. Geo-segmented wrapper configs are common at this publisher size and align with how Ozone in particular is documented. Worth a dedicated follow-up issue covering both properties side by side to characterize the demand-stack split.

9. What an operator should take from this

• ·A timeout rate this high is rarely a single-bidder problem. The first thing to check is whether the auction timer starts before ad slots are defined in the DOM. Prebid's documented pattern is requestBids() inside googletag.cmd.push, then setTargetingForGPTAsync in the bidsBackHandler before googletag.pubads().refresh(). Starting earlier means every bidder races a clock they cannot see.
• ·Per-bidder tmax overrides exist for a reason. If one wrapper consistently runs slower than the global tmax allows, set pbjs.bidderSettings.<bidder>.bidderTimeout = N. Or move the wrapper to a slower tmax shelf. Either way, do not leave a wrapper bidding into a closed door.
• ·Schain is configurable per wrapper. If two wrappers in the same stack pass schain on 100% of bids in the wire-level OpenRTB payload and seven show 0% wire-level, the per-wrapper config is the publisher's lever where the wire shows zero. Some SSPs add schain server-side, so wire-level zero is not the same as end-to-end zero; confirm with each SSP rep before assuming the fix is needed there. The fix when needed lives in pbjs.setConfig({schain}) for adapters and in each vendor's admin UI for managed wrappers and direct integrations.
• ·A wire-level capture counts integration surfaces fired in the browser, not buyers competing in the auction. A single wrapper call can route to dozens of demand sources. Schain coverage and bid timeout rate are the measurable things at this level.
• ·A missing sellers.json on the SSP side breaks chain verification even when the publisher's ads.txt is clean. The publisher cannot fix this directly. Raising it with the SSP rep is the path.
• ·Run the Beamflow Chrome extension on your own site as a starting point. If your bid timeout rate is over 50%, the problem is upstream of any specific bidder and the fix is in the wrapper config, not in any individual SSP integration.