Sitemap
Open in app

Sign in

Medium Logo
Write
Search

Sign in

Why FAST margins break at scale, and the five architecture decisions that decide whether you’re profitable.

10 min readJun 17, 2026

--

You launched forty FAST channels in two years. Viewing hours are up. Your delivery bill grew faster than your ad revenue, and finance wants to know why a business with no content acquisition cost is not producing a margin. The usual answer is “soft ad market.” The usual answer is wrong. In most of the FAST programs I have reviewed, the margin problem was set by five architecture decisions: made early, mostly by default, and rarely revisited.

The squeeze is structural

FAST is now mainstream demand, not a fringe bet: US FAST users reach 131.4 million in 2026, 54 percent of all connected-TV users and up 5.8 percent on 2025 (eMarketer, April 2026). The problem sits on the other side of that audience. Viewer growth keeps outpacing advertiser demand. eMarketer’s 2026 read is that inventory is plentiful, ad rates are soft, and fill rates sit below equilibrium; Wurl reports fill rates are still falling as content supply outruns advertiser investment. More inventory, lower clearing prices, and no subscription line to absorb the gap.

So revenue per delivered hour is falling, and you do not control it. Cost per delivered hour is set by your architecture, and you do. When the first line drops and the second stays flat, the margin breaks. Five decisions determine that second line. Each comes with a test you can run against your own platform this week.

Press enter or click to view image in full size

Decision 1: Are your ad pods constructed, or merely requested?

Fill rates are falling across FAST, Wurl’s 2025 data shows them sliding as content supply outruns advertiser demand, and eMarketer’s 2026 read is that inventory sits below equilibrium. That makes “soft demand” the easy explanation for any gap in your numbers. It is also, often, the wrong one. A large share of what reports as “low fill” is not unsold inventory — it is pods that were never constructable in the first place, and that share is invisible if you only watch the blended number.

The mechanics are documented in the stitcher’s own manual. AWS MediaTailor’s ad-behavior documentation states plainly: a 30-second break whose shortest transcoded ad runs 40 seconds inserts no ads at all. An ad-decision-server timeout is a named failure class with its own CloudWatch metric. A SCTE-35 CUE-OUT without a duration breaks the break. Each of these reports, downstream, as “low fill”, and gets escalated to the sales team, who cannot fix a manifest.

In an SSAI manifest-stitching engagement across several distribution platforms, most of what had been reported as weak demand decomposed, on inspection, into construction failures of exactly these classes. The test: can your reporting separate unfilled seconds caused by demand shortfall from unfilled seconds caused by pod construction? If you carry one blended fill number, you cannot — and you are likely buying demand to fix an engineering defect. This is the fastest money to recover — but only if you can see it, which is the next decision.

Press enter or click to view image in full size

Decision 2: Client-side, server-side, or server-guided ads?

You just saw pods fail in ways no sales team can fix. Whether you can even see those failures, let alone prevent them, is set by a model choice most FAST platforms inherited instead of making. There are three models. Client-side insertion (CSAI) lets each player call the ad server directly: granular targeting and player-side measurement, but every player acts alone, so at live concurrency, ad calls time out and pods desync, and yield cannot be coordinated across the audience. Server-side insertion (SSAI) stitches ads into the manifest before delivery: seamless and robust, which is why almost every FAST platform runs it, but the ad is baked into the stream, targeting is coarse, and, critically, the player cannot report what actually played. Server-guided insertion (SGAI) is the hybrid: the server marks ad opportunities with manifest interstitials and keeps decisioning and pacing, while the player resolves and beacons them — keeping server control while making each pod observable and interactive at the device.

This is a revenue decision because the model sets two numbers directly: how many of your requested impressions actually render, and what each one earns. SSAI prefetches and reserves ads for every session, including the ones that abandon or seek past the break, so a large share of impressions are requested and paid for in compute but never rendered. Your fill rate looks healthy, while delivered impressions lag and the rendered-to-requested ratio quietly declines. Worse for price: because SSAI beacons fire from the server, viewability cannot be confirmed at the player level, and advertisers discount what they cannot verify, a ceiling on CPM that no amount of demand can remove. SGAI inverts both. Just-in-time calls mean you mostly request impressions that play, and player-side beaconing (OMID) confirms the ad was seen, which is what lets a verified impression clear at a higher price. The independent-analyst framing (Ozer, 2026, on FreeWheel and IAB data) puts it directionally: moving CSAI to SSAI to SGAI, eCPM runs low to medium to high, and realized fill runs low to high to very high, while total cost of ownership runs low to very high to moderate. The exact uplift is deployment-specific — anyone quoting you a single percentage is selling something — but the direction is not in dispute.

It is also why the fill failures in Decision 1 are so often invisible: pure SSAI gives you a blended fill number and no per-pod truth; SGAI gives you player-side telemetry on what actually rendered. And it is now a choice, not a roadmap you wait on. HLS interstitials reached standards-track maturity in the May 2026 HLS draft, and the SVTA published its signaling standard. The test: can your stack tell you, per pod, what the player actually rendered? If the honest answer is “the stitcher says it inserted,” you are running blind SSAI, and the pod failures you just costed are invisible to you by construction.

Press enter or click to view image in full size

Decision 3: Is QoE a cost line or a revenue input?

FAST has no subscription cushion. Every minute not watched is impressions not served, immediately. The dose-response relationship is established in peer-reviewed work, not vendor claims. Krishnan and Sitaraman’s study of 23 million views: viewers begin abandoning at 2 seconds of startup delay, with abandonment rising by 5.8 percent for each additional second; a rebuffer delay equal to 1 percent of video duration cuts playtime by about 5 percent. Dobrian’s earlier Conviva-data study: a 1 percent increase in buffering ratio costs up to 3 minutes of a 90-minute live session — and FAST is linear, the worst-case content type. Akamai’s 2019 analysis of one US network’s 370 million plays chained it to money — and remains the most recent published dollarization of rebuffering loss: a single rebuffering event mapped to roughly 497,000 lost viewing hours, 10.7 million lost ad impressions, USD 85,000 at an 8-dollar CPM. The mechanism has not changed, but in 2026 the exposure is larger: with supply above demand and CPMs soft (eMarketer), every impression a buffer costs you clears at a lower price and is harder to resell. The figure is dated; the loss it describes is bigger today.

This is why the final decision — how you deliver — is a revenue decision, not only a cost one: the cheapest CDN per gigabyte is not cheap if it buffers, and a fraction of a percentage point of buffer ratio compounds into watch time, then impressions, then your revenue line. The test: does your platform have a stated buffer-ratio budget that the delivery architecture is required to meet, with the ad-revenue cost of missing it written down? If QoE reviews and CDN cost reviews are held in separate meetings, the answer is no.

Decision 4: Does your channel portfolio have a unit-economics floor?

Zoom out from the single stream to the whole portfolio carrying it. Channel costs are mostly fixed per channel. Cloud playout compute alone runs USD 73-256 per channel per month at AWS list pricing; commercial playout platforms quote in the low hundreds to low thousands per channel per month. Channel revenue is viewership-driven, and the distribution is heavily skewed: analyst Alan Wolk wrote in June 2025 that many FAST channels “get about two viewers a week and thus have almost no advertisers.” After a typical 50/50 platform split and the SSP, DSP, and reseller cuts ahead of you, a low-viewership channel is a permanent negative line that also dilutes the portfolio’s average and weakens your platform negotiating position.

The test: do you have a per-channel P&L — delivery, playout, ad-ops cost against net ad revenue — and a written threshold at which a channel is merged, automated, or retired? Channel count was the growth metric of 2022. In 2026, it is a cost decision. Operators who automated channel assembly and scheduling carry a structurally lower floor than operators who scaled headcount with channel count.

Decision 5: One CDN done right, or multi-CDN steering?

Save this one for last — not because delivery is cheap, but because steering is the optimization you reach for after the rest, and most platforms reach for it too early. First, run the unit economics. An HD ladder delivers roughly 2 to 3 GB per viewer-hour. At CDN list price, AWS CloudFront starts at USD 0.085 per GB, that is 17 to 25 cents per viewer-hour, against about 27 cents of gross ad revenue (roughly 18 impressions at a USD 15 CPM, before the platform split, SSAI, and the SSP and DSP cuts). At committed tiers (USD 0.02 per GB above 5 PB per month), the same delivery is 4 to 6 cents. The first move is not multi-CDN — it is getting off list pricing and tuning one CDN well: commit pricing, cache-hit ratio, an efficient encoding ladder, origin shielding. For a mid-size platform, a single well-run CDN is often entirely acceptable.

Get Maksym Mashnytskyi’s stories in your inbox

Join Medium for free to get updates from this writer.

Steering earns its complexity only when one CDN becomes the bottleneck, when a single provider cannot hold your QoE target across regions at the volume you have reached. That is largely a large-scale problem; below it, the extra moving parts can cost more than they save, and the decision itself takes longer to make than it is worth. When you are there, the question stops being “which CDN” and becomes “what decides, per session and per region.” The protocol is standardized: HLS Content Steering (Apple, 2021), DASH-IF Content Steering (2022), ETSI TS 103 998 (January 2024). The payoff is measured: Brightcove’s MHV 2025 study, three tier-1 CDNs, 21 countries, over 5,000 steered sessions — reported a buffer ratio of 0.03 percent under steering against 0.42 percent on the best single CDN. Read through Decision 3, that buffer-ratio gap is revenue, not just QoE. And the cost layer is formalized: Reznik and Cabrera (IEEE ISM 2024) showed that multi-CDN cost optimization under tiered rate cards and commits reduces to a linear program small enough to run inside the steering server. One honest caveat: no one has published a measured percentage cost savings from cost-aware steering in production. Anyone quoting you one is estimating.

I worked through this selection logic as a named inventor on US11470148B2, with a priority date of 2015 — per-region availability scoring, prediction, and selection across third-party CDNs. The patent exists because, at scale, single-CDN delivery was already failing on economics and quality a decade before the standards arrived. The test: have you exhausted single-CDN optimization (commit pricing, caching, ladder) and is one CDN now the measured ceiling on your QoE or your egress bill? If so, the steering is upside on both cost and revenue. If not, it is complexity you have not yet earned.

Where this is heading

Three shifts are visible from the standards and the published research. Steering servers become cost-aware — the ISM 2024 formulation puts the rate card inside the same control loop as QoE. Server-guided insertion goes from option to default, and with it per-pod observability becomes table stakes — the platforms still running blind SSAI in 2027 will be negotiating against competitors who can prove, pod by pod, what rendered. And AI’s real leverage in FAST is in exactly these layers — channel operations, metadata, per-channel decisioning — not in creating advertiser demand. That is the thesis our lab work keeps confirming: measure the substrate first, optimize second. You cannot fix a fill number you cannot decompose.

Five decisions, five tests. If you ran them just now and one came back red, you know your gap. If you’re scaling FAST channels and aren’t sure which of the five is costing you most, I do a short architecture review — reply here or reach me on LinkedIn: https://www.linkedin.com/in/maksym-mashnytskyi/.

Sources

Fast
Streaming Media
CTV
Adtech
Video Engineering

--

--

Maksym Mashnytskyi
Maksym Mashnytskyi

Written by Maksym Mashnytskyi

0 followers
48 following

OTT/Video-Streaming Expert | End-to-End Media Delivery Architect | Technical Product Management | Forbes Technology Council

Help

Status

About

Careers

Press

Blog

Store

Privacy

Rules

Terms

Text to speech