FAST Channel Launch Checklist (Platform-Ready)
At a glance
A FAST channel launch is an operational deployment. Content may be ready while monetization, metadata, signaling, and compliance are not. This checklist is designed to prevent approval delays and “launched but earning $0” outcomes.
Who this is for
- Channel operations leads
- Engineering / playout / streaming teams
- Ad ops and monetization
- Platform partnership / distribution teams
Before you start: define your launch target
- Distribution footprint: which platforms (Roku, Samsung TV Plus, LG Channels, Fire TV, others)
- Monetization mode: platform monetization, your ad stack (GAM/FreeWheel), or hybrid
- Measurement requirements: what reporting you must provide (internal + partner + buyer)
Responsibility boundaries
| Area | You control | Platform/partner controls |
|---|---|---|
| Stream quality & stability | Yes | No |
| EPG accuracy (metadata) | Yes (you supply) | Platform ingestion rules |
| Ad break signaling (SCTE-35) | Yes (you insert) | Platform acceptance varies |
| Demand & yield | SSP mix, floors, rules | DSP budgets, buyer policy |
Launch checklist (do in order)
1) Content readiness
- Master files QC (audio loudness, captions where required, codec compatibility)
- Clear rights for streaming + ad-supported distribution
- Emergency fallback playlist (“always-on” content)
2) Stream & encoding readiness
- HLS/DASH manifests validate and play on reference players
- Stable ladder (bitrate/resolution steps) and consistent codec profile
- Segment duration consistent; low error rates; origin and CDN configured
3) Ad readiness (SSAI + ad policy)
- SCTE-35 markers present and validated
- Pod duration policy documented and enforced
- Fallback behavior defined (no-fill → slate/house ads)
- VAST validation rules set (duration limits, codec limits, tracking requirements)
4) Supply-chain transparency
- ads.txt published (web)
- app-ads.txt published (CTV app distribution where applicable)
- sellers.json alignment confirmed for each SSP
- schain behavior confirmed (where programmatic path applies)
5) Metadata & EPG (Electronic Program Guide)
- Channel name, description, genres consistent across platforms
- Program schedule start times/time zones correct
- Artwork meets platform specs (aspect ratios, safe areas)
- Episode and series IDs stable (avoid re-keying after launch)
6) Measurement & reporting
- Define your truth source for impressions (SSAI logs vs ad server vs platform report)
- Set a daily reconciliation process (expect discrepancies; measure and explain them)
- Confirm viewability/measurability expectations for buyers (where relevant)
QA plan (minimum)
Device QA
- Cold start playback
- Seek / channel change behavior
- Ad break entry/exit without glitches
- No-fill behavior (does it stay watchable?)
Ad QA
- Ads play to completion
- Tracking beacons fire (at least impression + quartiles if supported)
- Creative spec compliance (audio loudness, codec, resolution)
Real-world launch scenarios (examples)
Example 1: “Platform monetizes for us” launch
- You deliver: stable stream + accurate EPG + cueing policy that matches platform rules.
- Platform delivers: demand, pacing, and many measurement/reporting decisions.
- Common risk: you still own stream stability and metadata; monetization does not compensate for broken cueing.
Example 2: “We monetize via our SSAI + GAM/FreeWheel” launch
- You deliver: SSAI decisions, demand wiring, floors, ad policy, and reconciliation.
- Common risk: approval delays if platforms require specific ad behavior rules (pod limits, restricted ad types, etc.).
Examples you can paste into tickets
Example: Go-live ticket
Channel name:
Platforms launching:
Playout provider:
Origin + CDN:
Playback URL(s):
SSAI vendor:
Ad policy (pod lengths / cadence):
ads.txt / app-ads.txt URLs:
Seller IDs (SSP list):
EPG feed URL:
QA sign-off date/time:
Rollback plan (what happens if SSAI fails):
Example: “Go-live” readiness gate
| Gate | Pass criteria | Owner |
|---|---|---|
| Playback stability | 24 hours continuous playback with < 0.1% fatal errors | Engineering |
| Ad insertion | At least 3 successful pods across device types; clean transitions | Engineering + Ad ops |
| Supply chain | ads.txt/app-ads.txt live; seller IDs verified | Ad ops |
Common launch blockers
- Missing or invalid ad break signaling
- Metadata inconsistencies (titles, artwork, schedule)
- No fallback plan for no-fill (dead air)
- Unclear ownership of measurement discrepancies
Sources
- IAB Tech Lab – VAST 4.2 (PDF)
- IAB Tech Lab – OpenRTB 2.6 (PDF)
- IAB Tech Lab – OpenRTB SupplyChain Object (schain) (GitHub)
- IAB Tech Lab – ads.txt overview
- IAB Tech Lab – ads.txt 1.1 (PDF)
- IAB Tech Lab – app-ads.txt 1.0 (PDF)
- IAB Tech Lab – sellers.json overview
- IAB Tech Lab – sellers.json (PDF)
- IAB – Digital Video Ad Measurement Guidelines
- MRC – SSAI & OTT Guidance (PDF)
- MRC – Viewable Ad Impression Measurement Guidelines v2.0 (PDF)
- Google Ad Manager – Connected TV ads
- Google Ad Manager – Dynamic Ad Insertion (DAI) for Developers
- Google Ad Manager – Full-service DAI
- AWS Elemental MediaTailor Documentation
- AWS MediaTailor – SSAI CDN architecture overview
- Apple Developer – HTTP Live Streaming (HLS)
- Apple Developer – HLS Authoring Specification
- ISO – ISO/IEC 23009-1:2022 (MPEG-DASH) page
- MPEG – Standards overview (includes MPEG-DASH)
- Roku Developer – Integrating Roku Ad Framework (RAF)
- Roku Developer – Implementing SSAI using Roku adapters
- SCTE – SCTE-35 catalog page
- ANSI preview – ANSI/SCTE 35 2017 (preview PDF)
- Comscore – CTV Measurement
- Nielsen – Connected TV insights (May 2025)
- FreeWheel – Publisher Suite overview
- FreeWheel Enterprise API docs
- IAB Tech Lab – VPAID (deprecated) page
- Google Ad Manager – Run video ads overview
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article