CTV ad decisioning flow: from content break to ad delivery

When a viewer watches JioHotstar on their smart TV and a commercial break begins, a complex chain of decisions happens in under one second — involving the app, the publisher's ad server, an SSP, multiple DSPs, and a VAST delivery chain, all before a single frame of advertising reaches the screen. Understanding this decisioning flow is the foundation of understanding how CTV advertising works, what can go wrong, and why certain formats and targeting approaches are possible or impossible.

The full decisioning chain

At the highest level, the CTV ad decisioning flow has six stages:

1. Break signal detected by the player
2. Publisher ad server receives the ad request
3. SSP runs a programmatic auction
4. DSPs evaluate the bid request and submit bids
5. Winning creative's VAST tag is resolved
6. Creative is played to the viewer

This entire chain must complete within the publisher's timeout window — typically 1–4 seconds depending on whether SSAI or CSAI is used.

Step 1: Break signal detected

The video player in the OTT app detects that a commercial break is starting. How this happens depends on the delivery method:

• VMAP (Video Multiple Ad Playlist): The publisher's video manifest includes a VMAP document that pre-defines all ad break positions, durations, and ad tag URLs. The player reads this before playback begins and knows exactly when to trigger each ad break.
• SCTE-35 cue markers: For live streams, SCTE-35 markers embedded in the video stream signal break start and end. The player (or SSAI system) watches for these markers in real time.
• In-app programmatic triggers: The app itself controls when to call for an ad — triggered at defined points in the content timeline.

For SSAI (server-side ad insertion), the break signal is processed by the SSAI platform, not the client app. The player simply receives a stitched stream that already contains ads at the correct break points.

Step 2: Publisher ad server call

When the break triggers, the app (or SSAI system) makes a call to the publisher's primary ad server — typically a platform like FreeWheel, SpringServe, Google Ad Manager, or a publisher's proprietary ad server. This call includes:

• Device ID (GAID, TIFA, or equivalent)
• Content metadata (channel, programme, content category)
• Break parameters (position: pre-roll/mid-roll/post-roll; duration; number of slots)
• User context (geography, subscription status, language)
• Consent flags (whether the user has consented to personalised advertising)

The publisher's ad server first checks its direct sold inventory — guaranteed campaigns from direct advertisers that have priority over programmatic. Any unsold or remnant slots are then passed to the programmatic layer.

Step 3: SSP auction

For programmatic slots, the publisher's ad server calls one or more SSPs (in India: Magnite, PubMatic, SpringServe, Google Ad Manager) with a bid request. The SSP:

1. Receives the bid request with device and content signals
2. Checks which DSPs have active demand for this inventory (deal IDs, open exchange)
3. Simultaneously sends the bid request to multiple DSPs (typically 10–30 DSPs in parallel)
4. Waits for bids, up to the timeout threshold
5. Evaluates all received bids against the floor price
6. Selects the winning bid (highest valid bid in a first-price auction)
7. Returns the winning bid's VAST tag URL to the publisher ad server

If header bidding is in use, multiple SSPs run their auctions simultaneously, and the publisher's ad server runs a unified second auction across all SSP winning bids.

Step 4: DSP bid evaluation

The DSP receives the OpenRTB bid request and must respond within the auction timeout (typically 80–150ms from receipt of the request). The DSP:

1. Parses device ID and checks frequency caps (has this device seen this creative too recently?)
2. Evaluates targeting criteria — does this impression match active line item targeting?
3. Runs the bidding algorithm — what is this impression worth based on targeting match, campaign pacing, and bid strategy?
4. Checks brand safety signals (content category, publisher block lists)
5. Submits a bid (or a no-bid if no active campaign matches)

DSPs that respond too slowly (above the timeout) are excluded from that auction — their bid is not counted even if it would have been the highest.

Step 5: VAST tag resolution

The publisher ad server receives the winning DSP's VAST tag URL. VAST (Video Ad Serving Template) is an XML document that points to the video creative file and includes tracking pixels. The resolution process:

1. Publisher ad server fetches the VAST URL
2. VAST XML is returned, which may contain a media file URL (the actual video) or another VAST wrapper (pointing to the next VAST in the chain)
3. If a wrapper, the chain is followed until a final VAST with a media file is reached
4. Media file URL is passed to the video player for creative fetching

Each wrapper hop in the chain adds latency. A 4-hop chain adds 200–400ms to total ad load time — a significant portion of the total timeout budget.

Step 6: Creative playback

The video player fetches the creative from the CDN URL provided in the VAST media file element. For CSAI, this fetch happens during the break itself — if the creative is not yet buffered when the break starts, there may be a visible load delay. For SSAI, the creative is pre-fetched and stitched into the stream before delivery, so playback is seamless from the viewer's perspective.

As the creative plays, the player fires VAST tracking pixels at defined moments: impression (2 seconds of playback), first quartile (25%), midpoint (50%), third quartile (75%), and complete (100%). These pixels are how advertisers and their verification vendors record delivery.

Where things go wrong

Failure Point	Symptom	Common Cause
Break signal	No ad loads at break	VMAP not fetched, SCTE-35 markers missing
Ad server call	Empty ad response	Publisher ad server misconfiguration, direct sold oversell
SSP auction timeout	No fill from programmatic	DSP latency too high, floor too high for available demand
VAST wrapper chain	VAST error codes (301, 303)	Too many wrapper hops, broken URL in chain
Creative fetch	Buffering during ad break	Creative file too large, CDN not serving India with low latency
Tracking pixel fire	Impression discrepancy	Pixel blocked, network error, CSAI JavaScript restrictions

In India CTV, the most common failure points are VAST wrapper depth (causing resolution timeouts) and creative CDN performance (causing buffering on slower residential connections). Both are solvable with proper technical hygiene.