AMZ
用户中心
账号与合规

广告投放别只盯 ACOS：论文里的反馈控制课

摘要：用控制系统理解广告预算和利润 很多卖家做广告复盘，最容易陷进一个单指标思维：今天 ACOS 高了，马上降预算；今天订单多了，马上加预算。 问题是，广告系统不是一个按钮。预算、竞价、流量时段、转化延迟、归因窗口、库存和毛利会一起作用。你以为自己在“控 ACOS”，实际上可能是在制造震荡：上午降…

公众号文章库2026/7/310 分钟阅读

广告投放别只盯 ACOS：论文里的反馈控制课

摘要：用控制系统理解广告预算和利润

很多卖家做广告复盘，最容易陷进一个单指标思维：今天 ACOS 高了，马上降预算；今天订单多了，马上加预算。

问题是，广告系统不是一个按钮。预算、竞价、流量时段、转化延迟、归因窗口、库存和毛利会一起作用。你以为自己在“控 ACOS”，实际上可能是在制造震荡：上午降价、下午没量、晚上又加预算，第二天归因订单回来后判断又反过来。

第 22 篇论文《Multivariable feedback control for multi-constraint optimization in online advertising》给了一个很好的底层视角：在线广告投放本质上是一个多约束控制问题。论文不是在讲卖家后台的某个具体按钮，而是在讲一个更底层的工程问题：

广告系统既要花掉该花的钱，又不能让花费相对广告价值失控；这需要反馈控制，而不是一次性拍脑袋。

封面

1. 这篇论文到底研究什么

论文作者 Niklas Karlsson，Amazon Science 页面把它列在 IEEE CDC 2025。研究对象是 online advertising 里的 campaign control，也就是广告活动控制问题。

论文先把广告投放拆成三个模块：impression valuation、campaign control、bid shading optimization。卖家可以这样理解：

  • valuation 负责判断一次展示机会值多少钱。
  • campaign control 负责预算、成本收益比等活动级约束。
  • bid shading 负责在拍卖环境下把出价做得更经济。

这篇文章聚焦第二块：campaign control。

为什么它难？因为线上广告是实时竞价，展示机会数量巨大，流量有时段波动，反馈有延迟，转化有噪声，竞争环境还会变。论文说的“plant uncertainties, nonlinearities, delays, time-variance, and noise”，翻译成卖家语言，就是：你今天调了广告，不会立刻看到一个干净、稳定、完全可解释的结果。

2. 多约束：预算和利润护栏要同时成立

论文里的优化目标可以简化理解为：在投放广告时最大化广告价值减去成本，同时满足两个约束。

第一个是 spend constraint：总花费不能超过预算上限。

第二个是 cost-benefit ratio constraint，简称 CBR：广告花费不能相对广告价值过高。它和卖家熟悉的 ACOS/ROAS 思维很接近，但不是同一个后台指标定义，所以不能直接画等号。

论文公式里写的是 EC ≤ ξ1，以及 EC ≤ ξ2 EV。卖家不用背公式，只要抓住一句话：系统不只是问“能不能花出去”，还要问“花得值不值”。

多约束地图

3. 为什么不能直接用一个大旋钮控制

直觉上，我们可能会说：既然预算和 CBR 都要控制，那就同时调两个参数。

论文指出，这会变得非常困难。原因是两个控制量之间会强耦合，一个参数的变化会改变另一个参数对系统的影响方向。论文甚至提到，如果不小心，一个反馈系统可能从负反馈变成正反馈，结果就是不稳定。

卖家把它理解成广告操作就很直观：

  • 你一边调预算，一边大幅调竞价。
  • 同时又开关优惠、改主图、改否词。
  • 再根据当天 ACOS 波动继续反向操作。

最后你很难知道，到底是哪个动作让系统变好，哪个动作制造了抖动。

所以论文建议做 re-parametrization，把问题改写成更容易控制的结构。它不是直接同时找两个复杂参数，而是把多约束问题拆成级联控制。

4. 级联控制：外环管 CBR，内环管 spend

论文提出 cascade feedback controller。

外环是 CBR controller。它每天根据实际花费和广告价值反馈，决定一个 adjusted daily budget，也就是今天最多应该允许花多少。这个预算不会超过原计划日预算。

内环是 spend controller。它拿到外环给的预算后，负责一天之内怎么花得更稳。论文里内环用 feedforward 加 feedback，每隔几分钟修正一个 bid modifier，让日内花费贴近目标节奏。

卖家语言就是：

先让利润护栏决定今天该不该放量，再让 pacing 系统决定今天怎么把钱花出去。

这件事很像汽车巡航。你不是每秒人工踩油门，而是设定速度，系统看实际速度和目标速度的差距不断修正。广告控制也是一样：设定预算和利润护栏后，系统根据真实反馈持续调整，而不是一次性定死。

级联反馈控制

5. 广告价值为什么不能当天立刻判断

论文很重视一个事实：ad value 有延迟。

广告价值可以来自点击、购买等用户行为。展示和点击发生在今天，但订单、归因、取消、退款、长期价值可能滞后。论文仿真里假设 spend 到 ad value 的平均延迟约 48 小时。

这对卖家非常关键。

很多广告误操作，本质上是把延迟反馈当成即时反馈。上午花费上升、下午 ACOS 难看，就马上降预算；但真实订单可能晚上或第二天才回来。你以为在止损，其实可能是在切断一个还没完成反馈的流量过程。

这并不是说广告不用管，而是说控制窗口要合理。越是自动化，越不能只看几个小时的单点数据。

延迟和噪声

6. 稳定性：广告自动化最怕来回震荡

论文最硬核的部分，是稳定性证明。

作者把闭环系统表达成 Lure system，然后使用 circle criterion 给出充分稳定条件。卖家不需要理解全部控制理论细节，但要理解它背后的工程价值：

一个广告控制系统，不能只在某一天看起来指标好，而要在噪声、延迟和约束变化下仍然能收敛。

如果一个规则今天让预算猛增，明天因为 ACOS 高又猛降，后天归因订单回来又猛增，它可能短期有几次漂亮数字，但长期会让数据难以解释，也会让广告学习和库存计划都变得混乱。

稳定性就是避免这种“踩油门、急刹车、再踩油门”的循环。

稳定性解释

7. 仿真结果说明了什么

论文用人工数据做了一个 30 天广告活动仿真，用来验证理论结果。

几个设置值得卖家注意：

  • 内环 spend controller 约每 2 分钟更新一次。
  • 日预算先是 600，之后变成 500，再变成 700。
  • CBR 约束前 15 天是 0.4，后 15 天变成 0.8。
  • spend 到 ad value 的反馈平均延迟约 48 小时。

仿真结果里，spend 约束全程被保持。CBR 一开始因为初始化较差出现违反，但随后恢复。论文还指出，前 15 天主要是 CBR 约束限制广告交付，后 15 天主要是 spend 约束限制广告交付。

这背后的卖家启发是：广告没放量，不一定是“系统不想花钱”。有时是利润护栏在限制交付；有时是预算上限在限制交付。复盘时要先分清是哪一个约束在起作用。

仿真结果卡片

8. 卖家明天可以怎么用

第一，把“预算控制”和“利润控制”拆开看。

预算控制解决的是 pacing：今天的钱有没有按节奏花出去。利润控制解决的是约束：这个流量值不值得继续放大。两者要互相沟通，但不要混成一个粗暴规则。

第二，设置反馈窗口。

对高客单价、长决策周期、强归因延迟的产品，不要用几个小时的 ACOS 直接触发大幅关停。可以分层设置：小时级只控异常花费，日级看转化，3 天或 7 天滚动窗口看利润。

第三，避免多个动作同时大幅调整。

如果你同时改竞价、预算、否词、主图、优惠和价格，系统反馈会混在一起。更稳的方式是：一次调整一个主变量，记录动作时间，观察足够窗口，再判断下一个动作。

第四，给自动化规则加防震荡机制。

例如同一广告组一天最多调整一次预算；ACOS 超阈值要连续两个窗口才触发；恢复放量也要分步恢复，而不是从 50 直接拉到 200。

第五，把广告复盘写成控制面板。

至少记录日内花费、预算使用率、CTR、CVR、CPC、广告销售、ACOS/ROAS、库存、毛利、退款和关键动作时间。没有这些字段，你只能凭感觉判断系统有没有稳定。

卖家广告控制 SOP

9. 不要误读这篇论文

第一，这篇论文不是 Amazon Ads 后台排名或竞价公式公开。它讨论的是在线广告里的多约束反馈控制方法。

第二，论文仿真使用人工数据，作者也明确说真实广告活动难以建模，仿真不能覆盖真实 plant 的所有重要行为。所以它不能保证你的账户照搬后一定稳定。

第三，CBR 不是卖家后台 ACOS 的精确定义。我们用 ACOS/ROAS 类比，是为了让卖家理解“花费相对广告价值”的护栏思想。

第四，稳定控制不等于保守不放量。好的控制系统应该在约束允许时尽量放量，在反馈变差时平滑收缩，而不是永久低预算。

结论

这篇论文对卖家的最大启发，不是某个公式，而是一个广告运营观：

广告投放不是单指标优化，而是带延迟、带噪声、带多约束的反馈控制。

真正成熟的广告管理，不是看到 ACOS 高就关、看到订单多就冲，而是先判断当前限制来自预算、利润护栏、流量质量、库存还是反馈延迟，再让系统稳定地修正。

如果你准备做广告自动化，这篇论文给的底线很清楚：先证明系统不会震荡，再追求更激进的增长。

资料来源