InApp

Unity Ads 的 ROAS 广告系列现在需要收入事件：iGaming 团队必须修好什么

2026年10月19日·Marko, Head of Operations & Strategy·5 分钟阅读

10 月初，Unity 修改了 ROAS 广告系列的启动规则。在流量来源收到带收入金额的购买事件之前，新广告系列不会启动。对应用所有者来说，这只是 MMP 里勾一个选项。对把流量导向租用应用的投手来说，这意味着要和掌握数据的人沟通，再加上几天的等待。

改了什么，为什么改

以前，即使价值数据不完整甚至完全缺失，ROAS 广告系列也能上线。现在 Unity 会先检查带收入的购买事件是否在回传，然后才让广告系列进入竞价。平台的理由很简单：能看到真金白银的算法，更擅长找到会付费的人。

为什么这在博彩里比看上去更重要

在 iGaming 里，“购买”就是存款，而存款金额差异很大。一个玩家充 $10，另一个充 $150，对 ROAS 模型来说，这是两类不同的受众。没有金额，算法只能看到发生了一笔付款，却无法偏向那些付得更多的人。

由此得出两个结论：

注册不再能作为 ROAS 信号。 早期测试用它没问题，但以回本为优化目标的广告系列，没有带金额的存款就根本无法启动。
对 iGaming 来说，收入来源永远是 IAP。 赌场应用靠存款赚钱，而不是靠应用内展示的广告。Ad Revenue 和 Hybrid 模式是为游戏设计的，不是为博彩，无论平台怎么力推。

应用是租的，信号就不归你

In-App 里的大多数联盟团队没有自己的应用。开发很贵，商店随时都可能下架一个应用。所以团队租用应用，作为交易的一部分，拿到一个现成的 MMP SDK，回传也已经配好。这套配置如何融入 Unity 投放，我们在 Unity Ads 做 iGaming 指南里讲过。

租用的缺点是，投手无法访问 AppsFlyer 或 Adjust 后台。事件配置、金额、币种，以及哪些合作方能收到数据，全都在提供方手里。提供方会把这些都配好，但只在你提出要求时才做。而检查的责任仍在投手身上：“提供方说一切正常”什么也证明不了。只有出现在报表里的事件才算数。

收入信号检查：问应用提供方的五个问题

在广告系列排进启动队列之前问清楚。每个回答都应该具体，而不是“都配好了”。

哪个事件作为购买回传给 Unity？ 是首存还是每一笔存款？这决定了算法实际在优化什么，以及你应该怎么解读 ROAS。
金额有没有回传，用的是什么币种？ 如果提供方无法回传准确的存款金额，Unity 接受一个固定值。这种情况下你得知道这个数字是多少，否则你账户里的 ROAS 毫无意义。
应用内事件是否专门为 Unity 这个合作方开启了？ 有时候安装共享了，事件却没有，广告系列就会莫名其妙地卡在检查这一步。
测试存款是怎么排除的？ 一笔带金额的测试付款一旦混进数据流，就会教算法去找一个并不存在的玩家。
能不能看到证据？ 要一份从第一天起的事件导出，或者合作方设置的截图。再通过你的追踪器加上你自己的测试注册和一笔测试存款。

投放计划里要算进的三个时钟

投放失败更多是因为时间，而不是因为设置错误。从“我们要上线了”到“我们可以下结论了”，有三个时钟在并行走：

提供方的时钟。 应用端的每一次改动（一个事件、一个金额、一份导出），来回沟通都要一到两天。凡是需要提供方配合的事，都应该在截止日期前完成，而不是在上线当天。
Unity 的时钟。 平台大约每天检查一次集成。今天开启事件共享，广告系列最早明天才能启动。还有一个容易忽略的细节：广告系列至少需要一个已通过审核、处于启用状态的素材包。如果其他素材包都暂停了，只删掉被拒的那个是不够的。
回传的时钟。 存款到达流量来源最多会延迟三天。第二天就评判广告系列为时过早，因为数据还没有成熟。要快速决策，就看提供方的导出或你自己的追踪器，而不是 Unity 后台。

把三个时钟加在一起，对一个广告系列做出可靠判断，最早也要在上线后三到四天。提前把这点算进计划的团队，不会因为第一天看起来是空的，就砍掉一套能跑的配置。

结论

Unity 的新规则把控制权转移到了收入数据所在的地方。租用应用换来的是快速起步，代价是你对信号的部分控制权。你可以通过向提供方问对问题、制定现实的时间线，把这份控制权拿回来。上线前核实信号的团队，从第一天起就拥有一个在找付费玩家的算法。不核实的团队，会在一个根本没启动的广告系列上，或者在基于尚未成熟的数据得出的结论上，浪费一周时间。