---
title: "每观众成本：流媒体行业藏了十年的指标，以及它的算法"
url: https://ireplay.tv/blog/mei-guanzhong-chengben-liumeiti/
markdown_url: https://ireplay.tv/blog/mei-guanzhong-chengben-liumeiti.md
description: "把范围限定在流媒体运营的每观众成本：公式、藏起它的四张账单（按台的CAPEX、按年的OPEX、按设备的许可、按GB的CDN）、一个算到每观众小时0.050美元的完整例子，以及当观众翻倍或减半时这个数字会怎么走。文中还回顾了2014年到2018年我们做VOD2Live的那几年，如何徒劳地想让电视机构接受这个指标。"
type: article
site: iReplay.tv
author: "Sylvain Corvaisier"
date_published: 2026-08-26T09:00:00+02:00
date_modified: 2026-08-26T09:00:00+02:00
language: zh
image: https://ireplay.tv/blog/thumbnails/cost-per-viewer-streaming-operations.jpg
keywords:
  - "每观众成本"
  - "每观众小时成本"
  - "流媒体成本"
  - "CDN成本 每GB"
  - "流媒体单位经济"
  - "每活跃观众成本"
  - "DRM许可 按设备"
  - "降低CDN成本"
  - "视频分发成本"
translations:
  ar: https://ireplay.tv/blog/taklifat-almushahid-fi-tashghil-albath.md
  da: https://ireplay.tv/blog/omkostning-per-seer-streamingdrift.md
  de: https://ireplay.tv/blog/kosten-pro-zuschauer-streaming-betrieb.md
  en: https://ireplay.tv/blog/cost-per-viewer-streaming-operations.md
  es: https://ireplay.tv/blog/coste-por-espectador-operaciones-streaming.md
  fr: https://ireplay.tv/blog/cout-par-spectateur-exploitation-streaming.md
  is: https://ireplay.tv/blog/kostnadur-a-ahorfanda-i-streymisrekstri.md
  it: https://ireplay.tv/blog/costo-per-spettatore-operazioni-streaming.md
  ja: https://ireplay.tv/blog/shichosha-atari-kosuto-haishin.md
  ko: https://ireplay.tv/blog/sicheongja-dang-biyong-streaming.md
  nl: https://ireplay.tv/blog/kosten-per-kijker-streamingoperaties.md
  no: https://ireplay.tv/blog/kostnad-per-seer-streamingdrift.md
  pt: https://ireplay.tv/blog/custo-por-espectador-operacoes-streaming.md
  ru: https://ireplay.tv/blog/stoimost-na-zritelya-streaming.md
  sv: https://ireplay.tv/blog/kostnad-per-tittare-streamingdrift.md
---

# 每观众成本：流媒体行业藏了十年的指标，以及它的算法

![以四种不同单位开出的流媒体账单：按台计的CAPEX、按年计的OPEX、按设备计的许可费、按GB计的CDN，没有一项能被观众小时整除](https://ireplay.tv/blog/img/cost-per-viewer-streaming-operations.jpg)

问一家流媒体运营商，一个观众看一小时要花多少钱。你会得到四个答案，来自四个人，用四种无法相加的单位。

工程部门知道转码器多少钱，因为采购单是他们签的。运维部门知道机柜、电力和维保合同多少钱，因为每年都是他们续签。产品部门知道DRM和智能电视应用多少钱，因为那些许可费列在他们的预算里。采购部门知道CDN每GB的单价，因为那是他们谈下来的。四个数字，四个负责人，四个分母，而其中没有一个是观众。

这道缝隙有个名字。每观众成本是流媒体运营中唯一能告诉你，当观众规模变动时，你建起来的这套东西是变便宜还是变贵的数字。而在过去十年的大部分时间里，它是唯一一个没有任何一张账单愿意给你的数字。

## 把范围限定在流媒体运营时，每观众成本是什么意思

在流媒体运营的范围内，每观众成本就是把视频送上屏幕的总成本，除以实际分发出去的观众小时。

**每观众成本 =（摊销后的CAPEX + OPEX + 软件许可 + 分发）÷ 已分发的观众小时**

范围的划法比公式更重要。这个定义有意把内容版权、市场营销和用户获取排除在外。它们是真实的成本，在多数平台上还是最大的成本，而这恰恰是要把它们排除的理由。版权账单是编排上的决定。获客成本是营销上的决定。工程师改了一层码率阶梯，运维负责人重谈了一份边缘合同，这两者都不会因此变动。把它们拿掉之后剩下的，才是技术组织在本季度真正能改变的部分。一个谁都无法据以行动的指标，是报表上的一行，不是指标。

有两个分母值得并排放着看：

- **每观众小时成本。**相对于真实消费量的分发效率与运营效率。它告诉你，被看得更多究竟是好消息还是坏消息。
- **每月每活跃观众成本。**无论对方看什么，把一个人持续服务好所需的花费。这是要拿去和ARPU、或和该观众带来的广告收入对照的数字。

两者出自同一批输入。能诚实地算出其中一个，就能算出另一个。

## 四张账单，以及藏起观众的四种单位

整个问题装得进一张表。每一行都是运营一项流媒体服务的真实成本。而每一行的计费单位，都与有多少人在看毫无关系。

| 科目 | 你买的是什么 | 供应商怎么计费 |
| --- | --- | --- |
| **CAPEX** | 转码器、封装器、流媒体服务器与源站服务器 | 按台、按频道、按输出路数，一次性 |
| **OPEX** | 上述一切的维护：维保合同、机房托管、电力，以及让它持续运转的人 | 按年，或按CAPEX的一个百分比 |
| **许可** | DRM、播放器SDK、机顶盒软件、智能电视软件 | 按设备、按许可请求、按活跃用户、按平台 |
| **分发** | CDN与缓存 | 按GB、按区域，承诺量加超量 |

这些单位里没有一个是「一个人看一小时」。转码器按并发输出路数定价。维保合同按年定价。DRM许可按密钥请求、或按设备、或按月活跃用户定价，取决于你签的是哪份合同。带宽按GB定价。要得到每观众成本，你必须把这四项全部折算到一个在它们身上都不存在的单位上，这意味着必须有人刻意坐下来，摊开四份合同和一张电子表格，而没有任何一张账单会逼他这么做。

这不是阴谋。供应商按反映自身成本结构的单位定价，而没有哪家供应商的成本结构长得像一个观众。但这个效应是有方向的，而这个方向并不中立。上述每一种单位，恰好也是让该供应商那一行看起来最小的单位。每个DRM许可请求半美分，听起来像四舍五入的误差。每GB八毫美分，听起来什么都不是。转码器是你早就做完的一次性采购。用各自的尺子量，每一行都便宜。折算到同一个分母上再叠起来，它们就不便宜了。

## 2014年到2018年，我们试过什么

iReplay.TV把那四年作为一家VOD2Live公司度过。这个[早在2012年底就被演示过](https://ireplay.tv/blog/hls-streaming-apple-http-live-streaming-protocol-standard-when-how-to-use-it-hls-ingest-akamai-msl4/)的想法很直白：如果内容已经编码好了，一条7×24小时的线性频道并不需要直播编码器。你拿已经为点播转码并封装好的素材，写一份滚动的直播索引文件，按排播顺序指向那些既有的分片。不需要每条频道一套直播编码链。不需要每条频道一台播出服务器。不需要磁盘上的第二份副本。

把编码链拿掉，一条线性频道的固定成本就会朝零塌下去。剩下的是分发，而分发随观众规模伸缩。这就是我们的说法：频道数量不再驱动你的成本，改由你的观众规模来驱动。

麻烦在于，这个说法在上面四种单位里通通看不见。面对按频道计的播出报价，它读起来就是「我们的播出比他们便宜」，于是你被拖进和播出厂商的功能对比里，在人家的场子上，用人家的单位，争论图文包装和SCTE-35支持。真正的论点，也就是成本曲线的形状已经变了，只有在买方手里握着一个按观众计的数字时才存在。于是我们做了那张幻灯片。每观众成本对频道数量。每观众成本对观众规模。那些交叉点，在观众不多的频道上，传统链路永远回不了本。

2014年到2018年间，我们把它带去展会、写进标书、带进许多会议室。没有落地。不是因为有人质疑算术，那样至少还能成为一场对话，而是因为它回答的是一个在场没有任何人被要求去解决的问题。

## 我们为什么失败

六个原因，大致按分量排序。

- **这个数字没有主人。**CAPEX在工程，OPEX在运维，许可在产品或法务，GB在采购。每观众成本是公司里唯一一个哪怕只算一次，也得让这四方先就一个共同分母达成一致的指标。凡是要四个部门先合作才能产出第一个数值的指标，产出次数是零。
- **分母根本不存在。**观众小时住在数据分析里，而分析通常向编辑部或市场部汇报，数的是播放次数、独立用户和完播率，而不是同时分发的小时数。当我们索要观众小时，常常拿到一个在场没人愿意为之背书的数字，而且和CDN日志差得很远。你没法把一个正经的成本指标建在组织并不信任的分母上。
- **单独优化任何一张账单，都会把每观众成本推向错误的方向。**典型案例：砍掉ABR阶梯的最高一档来压CDN账单。按GB那一行降了，采购负责人报了一个战果，而画质下降让观众更早离开，于是观众小时掉得比账单还快。每观众成本上升。每个人都只按自己那一行被考核，所以每个人都继续做局部正确的事。
- **我们在一个增长市场里卖利润率工具。**2014到2018年的任务是圈地：把应用发出去，挤进各个平台，数订阅用户。每观众成本是当任务变成「从你已经拥有的观众身上赚钱」时才会拿起的东西。那时候几乎没人因为做这件事而拿薪水。
- **这个单位本身不受欢迎。**电视机构来自一种边际观众免费的分发模式。发射机一开，转发器一亮，第一百万个观众根本不花一分钱。告诉一家电视机构，在IP上每多一个观众都要标价，等于告诉它，新的分发渠道在经济上不如它原本就有的那条。这是事实，也不是谁会想放进董事会材料里的一页。
- **我们要的是两个决定，而不是一个。**要认真评估VOD2Live，买方得先采用一个自己并不生产的指标。这是连着做两笔生意，而我们很少能越过第一笔。多年以后我们得到的教训是：你说服不了一个行业去采用一种单位。你要卖给它一件用这种单位标价的东西。

## 行业现在终于把它说出口了

这个术语在过去两年重新浮现，原因很简单：任务变了。迪士尼和派拉蒙在2024年各自交出了流媒体业务的首个盈利季度，奈飞的营业利润同年突破一百亿美元。一旦问题从「有多少订阅用户」变成「利润率是多少」，每观众成本就对那些原本用不上它的人变得有意思起来。

最显眼的倡导者是Viaccess-Orca，它有一篇关于每观众成本的博客文章，以及2026年7月发表在Streaming Media上的一篇署名文章[《The efficiency imperative》](https://www.streamingmediaglobal.com/Articles/Post/Blog/The-efficiency-imperative-why-streaming-platforms-must-optimise-cost-per-viewer-175879.aspx)。值得一读，也值得留意它如何处理这个定义：它把内容许可和获客支出拉进了总额里。这样得出的数字，CFO可以放进汇报材料，却几乎没有人推得动，因为最大的两项属于内容编排和市场营销。把范围守在流媒体运营之内，同一个指标就属于那些真正能改变它的人。

这就是指标和标题之间的差别。我们在2015年只把范围划对了，其余全都做错。眼下这一波拿到了注意力，而到目前为止，它的定义宽得无法据以行动。

## 怎么算，附一个算完的例子

设想一家区域电视机构，运营6条线性频道和一个点播片库，月活跃观众40,000人，人均每月观看12小时。这就是**每月480,000观众小时**，也是下面一切的分母。金额仅作示意，但比例是典型的。

| 科目 | 明细 | 每月 | 占比 |
| --- | --- | --- | --- |
| **CAPEX（摊销后）** | 3台单价24,000美元的转码节点，2台单价12,000美元的封装兼源站服务器，按5年直线摊销 | 1,600美元 | 7 % |
| **OPEX** | 每年按CAPEX的18 %计的维保与软件支持（1,440美元），两个机柜的托管、电力与交叉连接（1,400美元），含人力成本120,000美元的工程师0.5人（5,000美元） | 7,840美元 | 32 % |
| **许可** | 多DRM平台费800美元，加上900,000次单价0.004美元的许可请求（3,600美元），播放器SDK与播放分析（1,500美元），Tizen、webOS、Android TV、Fire TV、Roku和tvOS上智能电视与机顶盒应用的维护与认证（4,000美元） | 9,900美元 | 41 % |
| **分发** | 平均分发码率2.8 Mbps，即每观众小时1.26 GB，每月605 TB，按承诺量合同0.008美元/GB计 | 4,838美元 | 20 % |
| **合计** |   | **24,178美元** | 100 % |

**每观众小时成本：0.050美元。每月每活跃观众成本：0.60美元。**

先看占比。分发是四项里唯一按一个会随观看量逐月变动的单位计费的科目，却只占总额的五分之一。按设备和按请求计费的许可，是它的两倍。这个行业花了十年，把降本项目对准四行里最小的那一行，因为那是唯一会出现在月度账单上、能画成曲线的一行。

## 观众规模变动时会发生什么

每观众成本在长期里之所以重要，是因为这四个科目对观众变化的反应速度完全不同。保持同样的6条频道和同样的应用，只改变被观看的量。

| 情形 | 观众小时 | 每月总成本 | 每观众小时成本 |
| --- | --- | --- | --- |
| 观众减半 | 240,000 | 19,959美元 | **0.083美元** |
| 基准 | 480,000 | 24,178美元 | **0.050美元** |
| 观众翻倍 | 960,000 | 32,617美元 | **0.034美元** |

请再读一遍第一行，整个论点都在那里。观众减半。每一张账单无一例外地下降或持平。CDN账单跌掉一半以上。DRM许可那一行跟着下降。财务部门看到成本全线回落。而服务一个观众一小时的成本上升了65 %，因为这套系统里有三分之二根本不在乎有多少人在看。

这就是悄无声息地杀死一家电视机构流媒体业务的故障模式。它从不以一张糟糕的账单的形式到来。它以一连串漂亮账单的形式到来，而底下的经济性正在反转。反过来它同样为你卖力：把观看量翻一倍，每观众小时成本就降三分之一，不需要谈判，不需要迁移，不需要新合同。如果你不去算每观众成本，这两种变动对公司里的任何人都是不可见的。

## 真正能撬动这个数字的事

按对每观众成本的撬动幅度排序，而不是按放进幻灯片有多容易。

- **在内容用不着的地方，砍掉按频道计的固定成本。**用你已经转好码的素材拼出来的频道，几乎不背负编码链。对任何运营多于几条线性频道的人来说，这是可用的最大单项杠杆，而且在除这个单位之外的所有单位里都看不见。
- **按正确的分母重谈许可。**按许可请求、按设备、按月活跃用户，对同一项服务会算出天差地别的账单。在续约之前而不是之后，弄清楚哪一种对你的观看模式有利。在会话很短的服务上，按请求计费非常伤人。
- **让ABR阶梯匹配设备真正请求的东西。**阶梯同时放大存储、编码时长和GB数，所以它出现在四个科目中的三个里。检查每一档的每像素比特数，以及真实的请求分布而不是理论分布，同时留意上面那个陷阱：为了压账单而压画质，可能反而抬高每观众成本。
- **把分发放到一个你能预测的单位上。**按GB计费是一个事后才知道的数字。对任何有峰值的业务来说，这个顺序是反的。
- **先修分母。**如果数据分析和CDN日志在观众小时上差了20 %，你的每观众成本就是虚构，据此做的每一个决定都是猜测。这件事不体面，但它排在上面所有事情之前。
- **在可管理的网络上，考虑组播。**[组播ABR](https://ireplay.tv/blog/multicast-abr-mabr-jiexi/)恢复了广播那种边际观众不花钱的性质，是现存对这个指标最直接的一击。只有当网络由你掌控时才适用。

## 同一个分母也给你碳排数字

一旦观众小时可靠了，环境数字几乎白送，因为它用的是同一个分母。Carbon Trust与DIMPACT联盟合作，[把2020年欧洲一小时视频流媒体定在约55克二氧化碳当量](https://www.carbontrust.com/news-and-insights/news/updated-calculation-released-on-the-carbon-impact-of-online-video-streaming)，其中大部分来自观看设备而非网络。国际能源署的估算更接近36克。无论你用哪一个，每观众小时的二氧化碳当量克数，行为方式和每观众小时成本一模一样：随规模下降，随观众萎缩而上升，并对同样的阶梯与分发决策作出反应。已经在算其中一个的运营商，只要再乘一次就能得到另一个。

## 我们最后落在哪里：卖这个单位，而不是替它辩护

大约2018年，我们不再试图说服行业采用每观众成本。多年之后我们改做的事，是造一件用这个单位标价的工具。

[CDN Cost Optimizer](https://ireplay.tv/tools/cdn-optimizer)复制你现有的边缘节点，并通过HLS冗余流故障切换，从我们的边缘并行地服务观众；万一我们的边缘出问题，播放器会退回你自己的边缘。计费是**每观众分钟0.001美元**，也就是每观众小时0.06美元，最大套餐为0.05美元。不是按GB。计量表只在边缘上确实有观众的时候走：没人观看时预热缓存不花钱，在播但没有观众的频道也不花钱。仪表盘会在流处于直播状态时显示正在累计的每观众成本，这句话我们在2016年卖的任何产品上都写不出来。

两点老实话，毕竟这篇文章讲的就是不藏数字。第一，这个价格只覆盖四个科目中的一个。它对你的转码器、维保合同或DRM许可毫无作用。第二，每观众小时0.06美元并不是绝对便宜。它明显低于超大规模云厂商的标价：CloudFront和Azure CDN每GB约0.085到0.087美元，在2.8 Mbps下折合每观众小时接近0.11美元。而它与Cloudflare Stream每1,000分钟分发1美元的费率恰好持平。它高于大型运营商谈下来的按GB承诺量价格。重点从来不是这个费率永远最低。重点是它用的是你需要的单位，因此你在活动开始之前就知道这个数字，而不是事后再去还原它。

当两个产品各自独立地走到按分发分钟计费上，就有理由认为这个单位从一开始就是对的。只不过行业花了大约十年才走到这里。

## 常见问题

**流媒体里的每观众成本是什么？**
流媒体运营的总成本，即摊销后的CAPEX、OPEX、软件许可和分发，除以同期分发出去的观众小时。通常按每观众小时，或按每月每活跃观众来表述。

**这和广告里的CPV是一回事吗？**
不是，而且这个撞名造成了真实的混淆。在广告里，CPV指每次观看成本，衡量广告主为一次视频观看付多少钱。在流媒体运营里，每观众成本衡量运营方把视频送到一个人面前要花多少钱。相同的缩写，交易的相反两端。

**怎么计算每观众成本？**
把每一项运营成本折算成月度金额，硬件按使用年限摊销，然后除以当月分发的观众小时。难的不是除法，而是让四个部门就输入值达成一致，并拿到一个计费和数据分析双方都认可的观众小时数字。

**每观众小时多少算好？**
没有通用基准，因为频道数量、设备覆盖面和DRM策略会让它相差一个数量级。对一家自建编码链的中型运营商来说，每观众小时三到八美分是常见区间。比绝对值更重要的，是当你的观众规模变化时它移动的方向。

**版权和市场费用该算进来吗？**
不算进这个指标。它们主导总额，而且属于依据完全不同的逻辑做决定的团队。请把它们单独按每订阅用户成本来跟踪。正是把每观众成本守在运营范围内，才让这个指标可以据以行动。

**供应商为什么不报每观众成本？**
因为他们自己的成本没有一项长得像观众。转码器厂商的成本按并发输出路数计，DRM厂商的按密钥请求计，CDN的按搬运的GB计。各自按契合自身经济性的单位定价，而那也恰好是让自家那一行看起来最小的单位。

## 从哪里开始

就一项服务、一个月，把这个数字算一次。一个下午加四份合同就够了。几乎每个真去算的人，都会对四个科目里哪一项最大感到意外，而那极少是他们一直在开降本会议的那一项。

想在真实的流上看到一块按观众计的计量表在走，[CDN Cost Optimizer](https://ireplay.tv/tools/cdn-optimizer)不注册可用60观众分钟，登录后600分钟，都免费。想在把边缘节点放到前面之前先检查流本身，[Streaming Analyzer](https://ireplay.tv/tools/stream-analyzer)会对照最佳实践给它打分。至于每观众成本直接决定票价的按次付费场景，见[付费直播中的每观众成本](https://ireplay.tv/blog/maximum-cost-per-viewer-for-pay-per-view-live-streaming-optimize-roi-return-on-investment-for-better-margins/)；至于观众在地理上铺开时按GB计费的模型会怎么表现，见[视频流媒体的CloudFront定价](https://ireplay.tv/blog/cloudfront-costs-aws-reduce-cloudfront-costs-affects-amazon-cloudfront-costs-aws-cdn/)。

iReplay.tv由一群流媒体与广播工程师共同运营。如果你更希望有人陪你把这四个科目走一遍，也可以直接[聘请流媒体与广播专家](https://ireplay.tv/media-streaming-broadcast-talents)。

---

Source: [每观众成本：流媒体行业藏了十年的指标，以及它的算法](https://ireplay.tv/blog/mei-guanzhong-chengben-liumeiti/) on iReplay.tv. Free to quote and cite with attribution and a link to the source URL.
Full index of iReplay.tv content in Markdown: https://ireplay.tv/blog/llms.txt