Monetizing CTV Inventory: A Beginner's Guide for Digital Publishers

IAB projects United States digital video ad spending to surpass 80 billion dollars in 2026, growing 11 percent year over year, about 20 percent faster than the total ad market. CTV grows 11 percent inside that total, and the same projection expects digital video to exceed 60 percent of total TV and video ad spend for the first time. Those figures come from IAB's 2026 video spend projection, and the money behind them clears through ad pods, stitched manifests, and server-side beacons rather than display-style ad slots. Publishers above one million monthly pageviews already tune their display stacks weekly, yet many hand their CTV streams to a player vendor and lose sight of pod structure, fill, and price. This guide walks the mechanics end to end, from platform capabilities to pod math to payment terms, so your team can run CTV with the control you already apply to display.

What counts as CTV inventory

CTV inventory is any ad opportunity inside a stream that a television renders: your owned apps on smart TVs, your VOD catalog on tvOS and Chromecast, your live linear channels carried into living rooms. Repackaged linear feeds count too, because a playlist of back catalog streamed as a channel sells with the same pod structure as scheduled linear. Three structural facts separate all of it from display.

First, one stream carries everything. Every ad decision gates playback, so a slow auction stalls the show instead of refreshing a slot. Your latency budget lives inside the player start path, not inside a refresh cycle, and buyers see every stall in their delivery reports.

Second, buyers purchase pods rather than single impressions. Your sale looks like a 90-second mid-roll break, not one 30-second placement, and buyers price the break as a package. Pod shape therefore changes your yield math from per-impression floors to per-break floors.

Third, identity leans on device graphs and content context, because TV apps lack third-party cookies. Ship context signals with every bid request: content genre, series and episode metadata, stream type, live or VOD, and the app's device class. Buyers with verified audiences bid against those signals, so weak metadata costs you directly.

Capability spread compounds all three facts. An HTML5 app on a current television handles JS tags and the full VAST feature set, while older smart TVs choke on both and demand simpler XML delivery. Your platform matrix decides your tag format, your bidder set, and your measurement ceiling, so build it before you sell a single pod.

Content type splits the work further. Live linear stitches continuously and demands stable manifest assembly at concurrency peaks. Long-form VOD assembles each pod once per asset, so you can cache pod manifests and reuse them across viewers of the same episode. Short-form clips rarely carry mid-roll pods at all, because a 30-second slot inside a 60-second clip destroys completion rates. Match pod strategy to content length, never to page count.

The platform matrix comes first

Before any integration work, document four answers per platform. This matrix drives every later decision in this guide, from tag format to measurement path to floor structure.

• Runtime and screen: HTML5 on smart TV, Android TV, tvOS, iOS, Chromecast, and the DAI API where you stream through it.
• Tag support: full JS tags, XML only, or SDK-only delivery.
• VAST version ceiling: 2.6 on older runtimes, up to 4.x on current players.
• Measurement surface: OMID SDK support in the app, or server-side beacons only.

Two consequences follow. Bidder eligibility shrinks as runtimes age, because a bidder that returns JS wrappers has no path into an XML-only app. Measurement also splits by platform, which forces a reconciliation workflow rather than a single reporting line. Publishers who skip this matrix end up re-cutting integrations per platform mid-season, at the worst possible moment: after a buyer has committed to a pod deal against capabilities the app does not have.

Two delivery roads, one decision per platform

In client-side delivery, your player fetches a VAST tag, parses the XML, selects a media file, and fires tracking beacons. Modern app players handle this well. Client side buys you full VAST 2.6 to 4.3 behavior, in-app OMID measurement, and client-side verification, at the cost of latency in front of the stream and visible gaps when a creative fails.

In server-side ad insertion, a stitcher requests demand upstream, transcodes the winning creative segments, and merges them into the content manifest, so the player renders one continuous stream. SSAI scales across any device, tolerates weak players, and switches creatives without buffering. The cost: measurement moves server side, because client pixels never fire inside a stitched manifest.

We run both modes at the video layer: VAST 2.6 to 4.3, client side or stitched server side, delivered through XML or JS tags, with CTV pod orchestration covered across our in-stream and out-stream stack. Match the mode to the platform, not the other way around. Client side belongs where interactive formats and OMID matter, and SSAI belongs on live linear and on legacy device bases. Hybrid setups also work: SSAI owns manifest assembly while an in-app SDK adds client-side verification on top, which gives buyers a second measurement source without touching the stitch.

Two disciplines make the choice stick. On client-side paths, budget the auction inside the player start path: your timeout gates stream start, so set it against player start tolerance and measure abandoned pods weekly. On SSAI paths, filter creatives by codec and resolution at ingest, because your stitcher transcodes whatever wins, and a creative it cannot transcode becomes a dropped beacon or a stalled manifest at concurrency peak.

Ad pods are the unit of sale

OpenRTB 2.6 introduced ad pods for CTV transactions, and three fields carry the structure. podid marks an impression opportunity belonging to a video ad pod. podseq reports that opportunity's position inside the pod. rqddurs states the precise acceptable durations for each slot.

Work the arithmetic on a 90-second mid-roll break built from three 30-second slots. podid identifies the break, podseq runs 1, 2, 3 across the slots, and rqddurs tells each buyer the slot accepts exactly 30-second creatives. A 45-second bid cannot stitch into a 30-second slot, so it never wins that auction, and buyers who price pods as pods know the constraint before they bid. The same 90-second budget also accepts two 45-second slots or a 60-second slot plus a 30, which is why you publish the split rather than the total.

Define pod structure before you sell it. Pre-roll works as a single slot. Typical long-form mid-roll breaks run 60 to 90 seconds. Keep slot durations uniform inside a pod, because uniform pods widen compatible demand, simplify floors, and cut duration mismatch losses at stitch time. Publish the structure in your placement docs, per content type and per break position, so buyers can build pod-level deals against a stable target.

Pod Serving keeps the manifest with you

Google Ad Manager DAI Pod Serving lets you request ad pods from Google or third-party ad servers for live and video-on-demand streams. The product manages only ad pod building and creative conditioning: it assembles the break, conditions the creatives, and hands you ready-to-stitch ad pods. It also gives ownership of the manifest back to you, the partner. That last clause carries the economics. Your CDN delivers the stream, your stitcher assembles it, and your beacon logs feed your reporting.

Two paths split by content type. Pod serving redirect retrieves manifest segments so you implement server-side ad insertion, which suits live streams where stitching runs continuously. Pod serving manifest retrieves the complete ad pod manifest, and for VOD, Ad Manager returns complete ad pod manifests, so you assemble once per asset. Both paths cover HTML5, Android, iOS, tvOS, the DAI API, and Chromecast, and the Pod Serving API reference documents the calls per platform.

Manifest ownership changes your workflow in three places. Capacity planning lands on your stitcher, so load-test manifest assembly at concurrency peaks before a live event, never during one. Beacon logging lands in your logs, so build the reconciliation job before the first campaign ships. And deal packaging lands with you, because you control which ad servers feed each pod, in which order, at which floors.

Prebid ad pods for long-form demand

Client-side auctions still have a place on CTV, and Prebid's Programmatic OTT tutorial documents the path. The tutorial sets up Prebid.js ad pods delivered through Google Ad Manager, and it requires at least one video-enabled bidder supporting adpod. The Ad Pod module does the heavy lifting: it validates, caches, and modifies long-form video bids so a pod assembles cleanly.

Each verb covers a real failure mode. Validation checks each bid against the slot's acceptable durations before it enters the pod. Caching stores the creative for pod assembly, so a pod fills without refetching media mid-break. Modification reshapes long-form bids, for example a single 90-second creative into consecutive 30-second slots, so the resulting pod stays valid against the requested structure.

Run this pattern on long-form VOD apps with modern players, and pair it with server-side demand wherever SSAI owns the stitch. On stitched streams the auction completes before the manifest assembles, which is where OpenRTB 2.6 seats earn their keep. Keep the timeout honest: measure pod fill rate and player start delay together, because a timeout that wins a few cents per pod and costs seconds of start latency loses more in churn than it earns in yield.

Where our stack plugs in

At OnlyMedia we run an ad network, an SSP, and an agency inside one company, and we work with thousands of publishers, each above one million monthly pageviews. Our seats speak OpenRTB 2.6, and we integrate Prebid for header and server-side demand, so your pod requests reach curated buy-side teams rather than an undifferentiated feed.

Both sides of the trade route through the same pipes. Buy-side teams reach this supply through curated OpenRTB 2.6 buying paths with verified audiences. On the sell side, publishers join our curated programmatic demand network, take Net 30 payouts on CPM based terms, and hold floor structure per podseq position. Day to day, the ten minute reporting console covers fill by pod position, floor lift, and discrepancy trends in one view, with the workflow and Net 30 payment terms on our publisher monetization page.

Price by pod position

Pods price by position, so set floors per podseq, not per pod. The first mid-roll slot clears at a premium over the third, because attention decays through the break and buyers measure completion accordingly. Pre-roll prices above mid-roll for the same reason, and post-roll prices at a discount in most content types.

Package pod-level deals against the published structure. A buyer commits to a shape, three 30-second slots per 90-second break, two breaks per episode, at a pod CPM, and you commit to that shape in the placement docs and hold it across the flight. Deal stability beats the last increment of auction yield on CTV, because buyers re-plan around structure they can trust and pull spend from pods that mutate mid-quarter. Private marketplaces and programmatic guaranteed both work here: guaranteed suits flagship inventory where the buyer needs certainty, and the open auction mops up the remaining slots.

Review floors monthly against three signals: fill by podseq position, average clearing price by position, and the share of unfilled slots per break. A floor that lifts price and drops fill by more than the price gain is a net loss per break, and the math is simple enough to run in the reporting console weekly.

Measurement lives where the beacons live

In SSAI, the stitcher fires the beacons, so server-side counts are your source of truth. Reconcile stitcher counts against ad server counts weekly, and treat a widening gap as one of three causes: dropped beacons, creatives the stitcher could not transcode, or manifest timeouts at concurrency peak. Each cause has its own fix, so split the discrepancy by platform before you act.

Where your app SDK supports OMID, keep in-app measurement on the client-side path and let server-side reporting own the stitched path. Report both to buyers with the methodology stated, because a completion-rate dispute that starts without an agreed beacon source ends in a payment dispute.

We filter creatives against platform capability profiles before they reach a manifest: VAST version ceiling, codec, resolution, and duration against the slot's rqddurs. Filtering costs a little scale and saves the pod, because the failure modes below all begin as creatives that slipped past an ingest check.

Five failure modes that bleed CTV revenue

Most CTV revenue loss we see traces back to five failure modes, and they compound. Audit for each, in this order.

• Duration mismatch: a 31-second creative in a 30-second slot skews manifest timing and drops beacons downstream.
• VAST version mismatch: a creative that relies on newer VAST behavior than the runtime supports stalls playback rather than degrading gracefully.
• Beacon loss: platforms that suppress server callbacks report ghost impressions and invite payment disputes.
• Manifest timeouts: concurrency spikes exhaust stitching capacity and return empty pods.
• Over-podding: too many mid-roll pods per hour drives churn up and completion down, and buyers see both in their delivery reports.

None of these require new spend to fix, only configuration discipline. Cap pod frequency per hour by content type, validate durations and codecs at ingest, and monitor beacon coverage per platform, and the list shrinks fast.

A ninety day rollout, in order

Sequence matters more than speed here, because each step feeds the next. Hold each step until reporting confirms it before you start the following one.

1. Inventory platforms and player capabilities: HTML5, Android, iOS, tvOS, the DAI API, and Chromecast, plus device ages across your install base.
2. Map content into pod structures: pre-roll as a single slot, mid-roll breaks of 60 to 90 seconds, post-roll only where the format carries value.
3. Decide the stitching owner: your own packager with Pod Serving, or a vendor for the device tiers that need one.
4. Wire the paths: pod serving redirect for live, pod serving manifest for VOD, and request the pods from Google or third-party ad servers.
5. Enable at least one Prebid adpod bidder for long-form VOD in modern players.
6. Set floors per podseq position, then package pod-level deals against the published structure.
7. Instrument server-side beacons, reconcile stitcher counts against ad server counts weekly, and track beacon coverage per platform.
8. Bill CPM based on reconciled counts, on Net 30 terms.

Hold the terms, not just the yield

The 80 billion dollar projection lands in 2026 with or without your configuration. The publishers who capture it own the manifest, define the pod before the deal, and enforce payment terms that do not slide. OnlyMedia pays Net 30, CPM based, no chasing, no sliding terms, because a monetized stream with a slow receivable is a worse asset than a smaller check that clears. Configure the pods, own the manifest, and bill on time, and CTV stops being the part of the stack you hand to a vendor and starts being the part you run.