CNN.com

2. 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 15 here counts integration surfaces fired in the browser, not buyers competing in the auction. Rows are ordered by bid volume.

3. Supply path coverage

The IAB SupplyChain object (schain) declares who sits between the publisher and the auction on every OpenRTB bid request. Buyers use it to verify the path back to an authorized seller; missing or unverifiable chains mean buyers discount the bid, skip it, or apply a lower cap. This section reads schain coverage per wrapper from the wire-level capture, with server-side wrappers broken out separately because their browser payload does not carry schain (the chain is added on their backend).

4. Auction timing analysis

Three configuration patterns show up clearly across the 3,063 captured bidder attempts. First, a wrapper-level tmax misconfiguration on PubMatic OpenWrap (300ms shelf against an 888ms p50). Second, a 5,000ms tmax shelf on Criteo — 4x the typical Prebid budget, which keeps the auction open longer than any reasonable page-load window. Third, a stack-wide pattern of bidder responses arriving after the auction has already closed. Combined, the result is a bid timeout rate of 98%. Effectively all Prebid-layer bidders miss the window almost all of the time.

The premium ATF banner produced zero Prebid wins

The headline above-the-fold banner (ad_bnr_atf_01) was attempted by 12 bidders across 1,112 attempts. Five responses landed inside tmax (from Rubicon 3, TTD 1, PubMatic 1). Zero of those responses won. The breakdown of responses vs timeouts on this single slot is the cleanest illustration of the structural problem.

With 5 responses across 1,112 attempts and zero Prebid wins, the ATF slot is effectively decided outside the Prebid layer. The wins on this slot during the captured session almost certainly came from GAM line items, direct deals, or other demand paths the browser-side capture does not see. The Prebid layer is participating in an auction it rarely lands in time for, and never wins when it does.

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 888ms 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.

Even the bidders that do respond run close to or above the operative tmax on their slow tail: Medianet p95 1,663ms, PubMatic p95 1,535ms, TTD p95 1,270ms, Rubicon p95 1,237ms. With wrapper tmax shelves ranging from 300ms (PubMatic, Wunderkind) to 5,000ms (Criteo) and an apparent stack-wide failsafeTimeout near 1,000ms (see the DevTools subsection below), most bidders are racing a clock that closes well before their slow tail can land. 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 the publisher controls directly.

Aggregate yield signal

The Prebid layer alone is a thin slice of CNN's overall monetization. The bulk runs through Google Ad Manager line items, direct-sold deals, and server-side paths the browser capture cannot see. The aggregate numbers below characterize what the Prebid layer contributed during the captured session — not CNN's overall ad yield.

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.

5a. 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

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

The runtime view above only covers what fired during the captured 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.

6. What this site gets right

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

1. 1.

   Four wrappers pass schain on 100% of wire-level bids

   Wunderkind (215 of 215 bids), OpenX (4 of 4), Sovrn (4 of 4), and Sharethrough (2 of 2) all carry the SupplyChain object on every captured browser-side bid. PubMatic OpenWrap is close behind at 84% (42 of 50). That five-of-thirteen-wrappers result demonstrates the per-wrapper schain config can be set correctly when the publisher and the SSP both wire it through. The other wrappers may also be adding schain server-side (which we cannot see from a browser-side capture), but where the wire reads zero, the fix lives in per-wrapper config and is straightforward.

2. 2.

   ads.txt authorization is clean at the publisher level

   All 2,342 programmatic bids in the captured session verify cleanly against the publisher's ads.txt, with zero "not authorized" entries and no DIRECT/RESELLER mismatches. A 100% verified rate on a stack this size means the publisher's ads.txt file is well-maintained and the chain of trust between the publisher and each declared SSP holds.

7. Findings and open questions

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

1. 1.

   98% bid timeout rate across 3,063 bidder attempts is the headline operational issue

   Of 3,063 bidder-level attempts captured across the session, 3,002 timed out before a response could land. Only 61 responses came back inside tmax. Six bidders (TripleLift, Criteo, OpenWeb, Nativo, Teads, AppNexus) returned zero measurable responses across the entire capture. The headline ATF banner slot was attempted by 12 bidders across 1,112 attempts; 5 responses landed and 0 wins resulted. With a 99.6% timeout rate and zero wins from Prebid on the premium ATF slot, that auction is effectively decided outside the Prebid layer — almost certainly by GAM line items or direct deals the wire capture does not see. Root cause: a combination of auction-start timing (Prebid's requestBids fires before ad slots are fully defined in the DOM, so bidders race a clock that started early) and per-bidder tmax misconfig (Finding 2 + Finding 3). Independent verification in Chrome DevTools (see Section 5) confirms ten bidder requests abort in a tight 1.00-1.04s cluster, which suggests a failsafeTimeout near 1,000ms is overriding the 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 888ms. Its configured tmax is 300ms. The result is a 96% 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-1,500ms. Notably, PubMatic still passes schain on 84% of its bids (42 of 50) — the schain config is largely correct, but the timing config makes most of those bids moot because they never land. Fix: move pubmatic.com to the 1,250ms shelf, or set a bidder-level override via pbjs.bidderSettings.pubmatic.bidderTimeout = 1250.

3. 3.

   Criteo is on a 5,000ms tmax shelf — 4x the typical Prebid budget

   The captured tmaxByWrapper shows criteo.com configured at 5,000ms — versus the Prebid default of 1,000ms and the typical managed-wrapper range of 1,250-2,000ms. Either Criteo is being treated as a priority demand source the page is willing to wait several seconds for, or it is a left-over override that lets Criteo hold up the auction render when it runs slow. In this capture, Criteo timed out on 100% of its 270 Prebid auction attempts (0 responses inside tmax) — so the 5-second budget did not help; it just sat there. Worth reviewing whether the 5,000ms shelf is intentional. If it is, the audit question is what Criteo is delivering that justifies the wait. If it is not, dropping it to 1,250ms aligns with the rest of the stack and removes a potential 4-second tail on slow page loads.

4. 4.

   Schain coverage gap: 5 of 13 wire-level wrappers pass it on 0% of bids

   Of the 2,355 bid requests fired by wrappers we can evaluate at the wire level (Amazon TAM's 358 and Magnite Prebid Server's 8 bids excluded because both pass schain server-side), 369 (16%) carry the IAB SupplyChain object. Four wrappers pass it on 100% of their bids: Wunderkind (215 of 215), OpenX (4 of 4), Sovrn (4 of 4), Sharethrough (2 of 2). One passes it on a meaningful fraction: PubMatic OpenWrap at 84% (42 of 50). The Trade Desk direct integration sits at 25% (96 of 378). Two wrappers carry a trace amount: IX (4 of 287) and Criteo (2 of 139). Five wrappers show 0% wire-level: Magnite Fastlane, Nativo, TripleLift, Media.net, Kargo. For those five, server-side behavior is not always public; some SSPs 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. The fix typically lives in Prebid.js setConfig({schain}) for adapter wrappers and in each vendor's admin UI for managed wrappers and direct integrations.

5. 5.

   Two schain chains are propagating through the stack — Wunderkind direct and a Spotim wrapper-stamp

   All 369 wire-level schain-carrying bids fall into just two chain shapes. Chain 1 — wunderkind.co (sid 340), single hop — accounts for 351 bids and is observed on Wunderkind, PubMatic OpenWrap, and The Trade Desk direct. This is the publisher's primary schain config propagated through the demand paths that accept it. Chain 2 — spotim.market (sid pub_mM0DBXIIardI), single hop — accounts for 18 bids and is observed on OpenX, Index Exchange, Sovrn, Criteo/Grid, Sharethrough, and PubMatic. Spotim is the parent company of OpenWeb. The presence of the Spotim chain on bids fired through six different SSPs means OpenWeb is wrapping the Prebid auction at some level and stamping its own seller identity (Spotim) onto the chain before those SSP-bound bids fire. Operationally this is something to be aware of: when buyers downstream see those bids, the declared chain points to Spotim, not directly to CNN. Whether that is the intended config for OpenWeb's integration here is worth confirming with the OpenWeb account team.

6. 6.

   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 captured here on www.cnn.com. The international property had The Ozone Project (a UK-focused header bidding consortium) and Sharethrough actively participating, neither of which appears with comparable volume on the US property captured for this issue. The US property here shows Wunderkind, Media.net, Kargo, TripleLift, Nativo, OpenWeb, Teads, OpenX, Sovrn, and AppNexus. 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.