CTV ad serving operates under strict time constraints. The RTB auction must complete and a creative must be ready to play before the content stream's ad break arrives — typically within 200–500ms of the ad slot becoming available. Every component of the ad stack — SSP, DSP, ad server, verification vendor, CDN — consumes part of this budget. In India, where home broadband latency is higher than in the US or UK and CDN coverage for ad infrastructure is less complete, latency is the single most common cause of unexplained delivery failures.
The 200ms auction window and what it means
The RTB auction itself — the time between the SSP sending a bid request and the DSP returning a bid response — is constrained to approximately 100–200ms. This is the tmax (timeout) field in the OpenRTB bid request. Most India CTV publishers set tmax at 150–200ms for the auction phase. DSPs that cannot respond within tmax are treated as no-bid — their response is discarded even if a valid bid arrives a few milliseconds late.
The total ad serving window — from ad slot trigger to first frame of creative playing — is larger: typically 500ms to 1,500ms depending on publisher and whether SSAI or CSAI is being used. But this window is consumed by multiple steps: auction (100–200ms), VAST resolution (100–400ms if CSAI), creative fetch from CDN (50–200ms), and video player buffer initialization. Each of these steps can fail independently.
How the latency budget is consumed across the stack
| Step | Time consumed (good network) | Time consumed (India avg broadband) | Failure mode if exceeded |
|---|---|---|---|
| RTB auction (tmax) | 50–150ms | 80–180ms | DSP bid discarded — no fill |
| VAST wrapper resolution (CSAI, 2 hops) | 80–150ms | 120–250ms | VAST error 301 — timeout |
| Creative MP4 fetch from CDN | 50–150ms | 100–400ms | Buffering at ad break start |
| Video player buffer init | 20–50ms | 20–80ms | Frame drop or black screen |
| Total (CSAI 2-hop) | 200–500ms | 320–910ms | Publisher timeout → null fill |
SSAI collapses most of this latency because the creative is stitched into the manifest before delivery. The device never makes a separate ad fetch — it simply plays the next segment in the stream. SSAI's effective ad serving latency from the viewer's perspective is near zero.
India network conditions and their latency impact
India's broadband infrastructure has improved dramatically, but several factors still add latency to ad serving in ways that do not affect US or European CTV:
ISP DNS resolver latency: Many Indian residential users are on ISP-provided DNS resolvers (BSNL, Jio, Airtel resolver addresses). These resolvers have higher lookup times than Google DNS (8.8.8.8) or Cloudflare (1.1.1.1). DNS resolution for each ad server domain in a VAST chain can add 30–80ms per lookup in India vs 5–15ms in major US metros.
Ad infrastructure PoP coverage: Major DSP and ad server infrastructure (Google, The Trade Desk, PubMatic) has India PoPs in Mumbai, Delhi, and Bengaluru. Ad requests originating from Tier 2 cities may route to the nearest PoP rather than an optimal one. Requests from Tier 3 cities on slower or satellite-backhaul connections can see total RTB latency of 150–250ms — close to tmax — before any creative delivery begins.
CDN coverage for creative delivery: Akamai, Cloudfront, and Fastly have good India coverage. Ad creative CDNs hosted on smaller providers or using only US-based origins add 200–400ms for creative fetch in India. This is the latency component buyers most often overlook — the creative file download latency, not just the auction latency.
Creative prefetch and caching: how SSAI solves the problem
SSAI publishers (JioHotstar, SonyLIV via SpringServe) address creative delivery latency by prefetching and caching creatives at the SSAI server before the ad break arrives. When a JioHotstar SSAI system identifies an upcoming ad break in a stream, it pre-calls the programmatic stack and fetches the winning creative 5–30 seconds before the break is due. The creative is already cached and ready to stitch into the manifest when the break arrives.
This pre-fetch model has important implications for buyers: creatives that fail validation or exceed file size limits (JioHotstar's SSAI typically enforces under 5MB) are rejected during the pre-fetch phase — before the break — not at the moment of delivery. The slot fills with a house ad instead. Buyers may see a winning bid in their DSP report but zero actual plays — the pre-fetch rejection is not always surfaced in DSP reporting.
How to diagnose latency-related delivery problems
Signs that latency is causing delivery failures rather than targeting or pricing issues:
- High win rate in DSP reporting (impressions won) but materially lower impression delivery in publisher reporting — the gap is latency-related timeouts after the auction.
- VAST error 301 or error code 900 (undefined error, often timeout) representing more than 3–5% of errors in publisher VAST error reports.
- Delivery performing well on JioHotstar (SSAI) but poorly on smaller CSAI publishers at the same budget — SSAI removes device-side latency; CSAI exposes it.
- Creative delivery improving after switching from a VAST wrapper tag to an inline VAST with a direct CDN URL — wrapper resolution latency was the bottleneck.
The diagnostic sequence: (1) Check publisher VAST error codes for 301/302. (2) Test VAST chain resolution time with an IAB VAST Inspector. (3) Check creative CDN origin — is it India-routed or US-origin? (4) Confirm creative file size is under 5MB for SSAI publishers. (5) Consider requesting an inline VAST from your DSP to remove wrapper hops.