Header bidding exists on CTV, but it works differently from the web version. There is no browser and no HTML header — so the JavaScript-based Prebid.js approach used on web cannot run directly on a TV app. Instead, CTV header bidding happens either server-side (the publisher's server sends a bid request to multiple SSPs before calling the ad server) or via a client-side SDK embedded in the CTV app. Both approaches serve the same goal as web header bidding: letting multiple demand sources compete simultaneously rather than in a sequential waterfall.
Why traditional header bidding doesn't work on CTV
Web header bidding relies on JavaScript running in a browser before the page loads — the "header" in header bidding is literally the HTML <head> tag. CTV apps are native applications running on Android TV, Tizen, webOS, or Roku. They have no browser execution environment, so JavaScript-based bidding wrappers cannot run.
Additionally, CTV ad breaks use SSAI (server-side ad insertion) to stitch ads into the video stream server-side, which means ad decisioning happens before the viewer's device ever makes a request. This architecture requires any auction to happen at the server level, not the client level.
Server-side header bidding on CTV
Server-side header bidding (also called server-to-server or S2S bidding) is the most common CTV implementation. When an ad break is triggered:
- The publisher's ad server (or SSAI provider) sends simultaneous bid requests to multiple SSPs
- All SSPs respond within a defined timeout (typically 150–300ms)
- The ad server runs a unified auction across all SSP bids plus its own direct line items
- The winning bid's creative URL is stitched into the video stream
The key benefit: every demand source competes in a unified auction, eliminating the waterfall advantage that SSPs positioned first in a sequential stack used to enjoy. Publishers using server-side header bidding typically see CPM uplifts of 15–30% over sequential waterfall setups.
Client-side SDK bidding on CTV
An alternative approach is embedding an SSP's SDK directly into the CTV app. The SDK handles bid requests from within the app, running on the device itself. This allows richer signals (device identifiers, app-level data) to accompany the bid request than server-side approaches, which may anonymise or strip device signals for privacy reasons.
The downside: each SSP integration requires a separate SDK, and CTV app updates are slower to deploy than web changes. Multi-SSP SDK integration on CTV is operationally complex and most India publishers have not pursued it at scale.
Header bidding adoption in India CTV
India CTV header bidding adoption is early-stage compared to the US or Europe. The market reality in 2026:
- Large platforms (JioHotstar, SonyLIV): Have internal ad tech infrastructure capable of unified auctions, but most premium inventory is sold direct or via managed PMPs — not exposed to open header bidding
- Mid-tier publishers: Most still use sequential waterfall setups through GAM + one or two SSP integrations. Server-side header bidding adoption is growing but not yet standard
- FAST channel operators: Typically rely on their FAST platform's (Zee5 FAST, Tata Play Binge) ad infrastructure, which may or may not implement header bidding
For buyers, this means that the efficiency gains from header bidding (reduced CPM gaps, more competitive auctions) are more available on Western CTV platforms than Indian ones currently. As India CTV matures toward 2027–28, expect broader server-side header bidding rollout among mid-tier publishers.
What this means for buyers
From a buyer's perspective, you cannot directly participate in or trigger header bidding — it's a publisher-side architecture. What you can do:
- Ask publishers whether they use unified auction or sequential waterfall — it affects whether your DSP bids compete fairly against other demand sources
- Prefer SSPs (Magnite, PubMatic) that have invested in CTV server-side header bidding infrastructure, as they're more likely to carry publisher integrations that use it
- For open auction buys, use a DSP with low latency bid response times — this matters more in waterfall setups, where faster responses win higher waterfall positions