企业官网建设流程全解析

1. 从一次“假盈利”说起：为什么IAA业务必须自建ROAS指标体系

我刚开始做IAA（In-App Advertising，应用内广告变现）业务的时候，踩过一个特别典型的坑。

当时手里有一款休闲小游戏，买量后台的ROAS看着已经到1.35了，远超我们定的1.2回本线，我拉着投放同学说“可以放量了”。结果月底财务一拉账，告诉我项目整体还是亏的。我当时的表情大概就是那种“你逗我？”的经典表情包。

后来把数据链路拆开查了一遍，才发现问题出在哪：买量归因平台算ROAS时，只看了一部分广告变现收入（比如只算了激励视频，没算插屏和Banner），而当期买量花费又只计算了一部分渠道的消耗，两边口径根本对不上。更离谱的是，用户当天的广告收入里，有一部分是历史买量用户贡献的，却全被算到了当日新增用户的头上。也就是说，我在用“混合了老用户的流水”除以“只包含新用户的消耗”，这个ROAS当然会虚高。

那次之后，我用了大约三周时间，把整个IAA业务的数据链路从头梳理了一遍，从买量计费、归因回传、广告变现流水到LTV预测，最终形成了一套面向全链路的ROAS增长指标体系。这个体系后来被我们内部复制到了好几款产品上，每次买量预算调整、变现策略优化、甚至产品广告场景改版，都是先看这套指标再动手。

这篇文章就是把当时那套思路和落地细节完整拆开，从链路梳理、指标分层、数据埋点、计算口径到实际应用，再到我会踩到的坑，一次性说清楚。适合增长负责人、投放优化师、广告变现运营、数据产品经理和BI工程师参考，尤其是那些正在从“看单日ROI”升级到“看全链路回收”阶段的产品团队。

2. 全链路不是一句口号：先用“用户旅程”拆出关键环节

2.1 链路两大端：投放侧“进人”与变现侧“出钱”

IAA业务的本质其实很朴素，就是花钱买用户，让用户在看广告的过程中产生收入，最终让收入大于买量成本。这句话听起来跟所有生意都一样，但IAA有一点非常特殊：用户不付费，他的“价值”完全由广告平台决定，而这个价值既不稳定也不线性。

这就决定了ROAS不能只看一个数，必须把链路拆开看。我习惯把完整的IAA链路拆成两个大端、六个关键环节：

投放侧的关键环节是“计划层级买量、广告创意曝光、点击、唤起/安装、激活”。这里的每一步都有对应的漏斗损耗，从展示到激活，休闲游戏类产品通常只有个位数到十几的转化率。变现侧的关键环节是“用户进入产品、看完广告、产生收入、再次进入广告场景”。注意，这里的每一步也有漏斗损耗，广告请求成功率、填充率、展示率、人均展示次数，每一个都直接影响最终收入。

两端的连接点是什么？是用户激活。激活之后，用户归属于某个渠道、某个广告计划、某个素材，这个归属关系是所有ROAS计算的前提。现实中很多人算ROAS不准，问题往往就出在这里：归因关系错乱，或者归因窗口和变现收入的时间窗口不一致。

2.2 链路中间的“价值递进”：从单日收入到LTV预测

拆完两端的关键环节之后，还要理解一个概念：用户的价值是随时间逐渐体现的。这一点跟IAP（应用内付费）业务差异很大。IAP用户可能在第一天就付费，首日LTV占比很高；但IAA用户通常是被“看视频解锁道具”这种机制吸引进来的，他对广告的贡献是慢慢累积的。

所以ROAS的周期就非常关键。只看D0 ROAS，很多优质渠道会被误杀；只盯D30 ROAS，优化周期又太长，预算很难及时调整。实际项目里通常的做法是，把D0、D1、D3、D7、D30这几个关键时间点都纳入体系，根据产品数据的稳定度和回收速度，确定哪个时间点的ROAS可以作为“买量放量与否”的核心决策依据。休闲游戏舍得花钱测试的话，D7 ROAS与D30 ROAS的相关系数大都能到0.8以上，所以在快节奏买量中，D7 ROAS是应用最广的中期代理指标。

这整条链路，从投放出价到用户激活，再到后续的一连串广告收入，形成了一条完整的价值链条。任何一个环节的变化，都会在最终ROAS上产生涟漪效应。只有把这个链路拆到足够细，才能知道ROAS跌的时候，究竟是买量质量出了问题、变现价格掉了、还是广告场景覆盖变少了。

3. 指标架构怎么搭：三层漏斗 + 两个辅助视图

这套体系里，我最终把指标分成了三层，外加两个辅助分析视图。三层是从前到后的漏斗，辅助视图是用于排查问题的分解工具。

3.1 前端效率层：买量成本和转化漏斗

第一层解决的是“我花多少钱才能弄到一个人”。核心指标包括：

这一层是很多团队每天盯得最多的，但它本质上只回答“进人贵不贵”，不回答“人值不值”。如果不跟后端的收入指标联动，光看CPA很容易做出错误判断。比如一个渠道CPA 3元，另一个渠道CPA 6元，如果你的结论是“3元渠道更划算”，那你就默认了所有激活用户价值相同，这在IAA业务里几乎不成立。

注意，IAA的投放优化师通常还关心一个叫“首日ROAS目标”的出价方式。买量平台会根据这个目标自动找人，这时前端效率指标决定了你能否跑出量，后端LTV指标决定了买量模型能否持续优化。两套指标互相依赖，不能只盯一边。

3.2 后端收入层：LTV、ROAS与回收周期

第二层解决的是“这个人最终能贡献多少钱，回收情况如何”。核心指标有：

• 分周期LTV：D0 LTV（当日人均收入）、D7 LTV、D30 LTV。这是刨除了所有成本后，单用户产生的净广告收入累计值。
• 分周期ROAS：D0 ROAS = D0新增用户广告收入 / D0新增用户买量消耗，D7 ROAS、D30 ROAS同理。
• 回收周期：累计收入反超CPA所需的天数。比如CPA是4元，D7 LTV是3元，D10 LTV到了4.2元，那回收周期就是10天左右。
• 次留/7留：用来关联判断长期LTV的关键用户行为指标，尤其对IAA游戏，留存跟广告收入基本是强相关的。

后端收入层是整个指标体系中最核心的一层。建议按渠道、广告账户、素材类型（视频/可玩/横幅）、国家/地区几个维度分别计算LTV和ROAS，光看大盘均值会掩盖掉很多结构性问题。

3.3 变现效率层：广告收入是怎么“漏”掉的

第三层解决的是“就算有用户，广告收入是怎么产生的，哪些环节在漏钱”。核心指标包括：

补充一个计算示例。某天某广告位的eCPM是20元，这不是平台“给出的价格”，而是当晚汇总反推出来的。如果你的某个广告位一天产生了50,000次展示，广告收入1000元，那么eCPM = 1000 / 50,000 × 1000 = 20元。不同广告平台的eCPM差异可以非常悬殊，比如激励视频的综合eCPM可能是插屏的3到5倍，所以在算人均广告收入时，如果只看整体ARPU、不拆分广告位类型，很容易误判哪个场景贡献最大。

这里有一个非常容易被忽略的点：在IAA业务里，用户看广告本身也是一种“转化”，转化率取决于广告平台怎么匹配广告。理解这一点后，你就明白变现效率层不仅要看自己产品的数据，还要看广告平台侧的“水位”。GDPR、苹果ATT政策对广告平台eCPM的影响是行业级的，这部分风险无法通过“多做两个广告位”来对冲，但可以通过数据层面的实时监控来预警。

3.4 辅助视图一：成本回收热力视图

这个视图是把“成本（CPA）”和“回收（LTV/ROAS）”放到同一个表格里，按渠道×地区或者渠道×素材类型做交叉。比如下表截取的一部分：

这类视图最大的价值是快速定位“哪里该加预算、哪里该关计划”。我一般会要求投放同学每周至少跑一次这个热力表，并且关注连续7天的趋势，而不是只看某一天。因为单日报表波动太大，今天某渠道ROAS 1.5、明天0.9的情况太多了，看单日会把团队折磨死。

3.5 辅助视图二：收入结构分解视图

这个视图回答的问题是“如果今天收入掉了100万，到底是谁掉的”。将收入做三个维度的分解：

• 按用户类型分：新增用户贡献 vs 活跃老用户贡献。这个拆分非常重要，因为新老用户的收入贡献天然不同，而买量优化只能直接影响到新增用户部分。
• 按广告形式分：激励视频、插屏、Banner、开屏各自贡献多少。
• 按广告平台分：每个聚合平台或广告平台（比如AdMob、Meta Audience Network、Mintegral等）贡献了多少。

有了这个视图，排查收入波动的时候就不用瞎猜了。比如某天整体ARPU下降，先看是不是老用户收入缩水、再看是不是插屏eCPM掉了、最后落实到具体是哪个平台的水位变化。这套排查逻辑后面我会在常见问题部分再展开一次。

4. 落地实操：数据埋点、归因口径与SQL计算示例

4.1 埋点与数据上报：五个关键字段设计

再好的指标体系，底层数据不干净都是白搭。IAA业务的埋点体系，我建议至少覆盖以下五类关键事件：

• 广告请求事件（ad_request）：记录广告位ID、请求时间、用户ID、应用版本。
• 广告返回事件（ad_response）：记录广告位ID、是否返回广告、返回延迟、平台名称。
• 广告展示事件（ad_show）：记录广告位ID、用户ID、广告平台、创意ID、展示时间。
• 广告点击事件（ad_click）：记录广告位ID、用户ID、平台、时间。
• 广告收入事件（ad_revenue）：记录广告位ID、用户ID、平台、收入、货币单位、预估收入来源（如AdMob的estimated revenue）。

这几个事件都需要附带一个公共字段：用户激活时间、激活渠道、广告计划ID、素材ID。这些字段是后续做归因和分维度计算的前提。

我没有在IAA业务里见过哪家公司能省掉埋点直接靠三方后台分析出完整ROAS的，因为三方后台能看到的数据粒度太粗，根本支撑不了“按素材×地区×广告位”这种交叉维度分析。数据上报建议走实时管道，核心事件延迟控制在5分钟以内，这样可以支持快速决策。

4.2 归因口径与数据回传：必须和买量平台对齐的细节

IAA业务的归因，一般使用三方归因平台（比如AppsFlyer、Adjust），把广告点击/曝光匹配到激活。有两个细节特别容易出问题：

第一，归因窗口设置。通常IAA产品会设置点击归因窗口为7天或30天，但要注意不同渠道的实际转化周期差别很大。如果你设置的归因窗口是7天，而某个渠道实际转化周期在7天以上，那该渠道的部分激活会被漏归因，导致该渠道CPA虚低、ROAS虚高。对休闲游戏这种快节奏产品，我一般建议窗口周期设为7天，同时单独监控“点击时长超过7天的激活占比”，如果这个占比明显升高，就要考虑渠道质量是否下滑。

第二，收入数据回传。广告变现数据的回传是另一条链路，我们需要将用户产生的广告收入回传给归因平台，让归因平台能够按渠道计算ROAS。关键是回传的口径必须和内部计算口径保持一致。比如你是否只回传“新增用户在激活后7天内产生的广告收入”，还是回传“当日该用户产生的全部广告收入”？我当时踩的坑就是这个：回传了全量收入，导致归因平台的ROAS不管怎么算都是虚高的。

4.3 指标计算：一份可以直接套用的SQL计算框架

以一个简化模型为例：事件表ad_revenue记录了各用户每天产生的广告收入，user维度表记录了用户的激活日期、渠道、CPA。

计算新增用户分周期LTV和ROAS：

SELECT activation_date, channel, COUNT(DISTINCT user_id) AS new_users, SUM(CASE WHEN DATEDIFF(CURRENT_DATE, activation_date) = 0 THEN revenue END) / COUNT(DISTINCT user_id) AS ltv_d0, SUM(CASE WHEN DATEDIFF(CURRENT_DATE, activation_date) BETWEEN 0 AND 6 THEN revenue END) / COUNT(DISTINCT user_id) AS ltv_d7, SUM(CASE WHEN DATEDIFF(CURRENT_DATE, activation_date) BETWEEN 0 AND 29 THEN revenue END) / COUNT(DISTINCT user_id) AS ltv_d30, cost / COUNT(DISTINCT user_id) AS cpa, SUM(CASE WHEN DATEDIFF(CURRENT_DATE, activation_date) BETWEEN 0 AND 6 THEN revenue END) / cost AS roas_d7 FROM ( SELECT u.user_id, u.activation_date, u.channel, u.cost, COALESCE(a.revenue, 0) AS revenue, a.ad_date FROM dim_user u LEFT JOIN ( SELECT user_id, DATE(show_time) AS ad_date, SUM(revenue) AS revenue FROM ad_revenue GROUP BY user_id, DATE(show_time) ) a ON u.user_id = a.user_id ) t GROUP BY activation_date, channel;

需要注意，这是一个简化的查询，实际生产环境建议把收益明细表按“日期、用户、广告位、平台”预聚合，因为广告收入明细量非常巨大。另外，D30 LTV受“当前活跃期不足30天”的影响，实际应用中要用Cohort分析，不要简单用DATEDIFF，否则最近7天新增用户的D30 LTV会永远偏低。

计算eCPM：

SELECT DATE(show_time) AS day, ad_slot_id, platform, SUM(revenue) AS total_revenue, COUNT(*) AS total_impressions, SUM(revenue) / COUNT(*) * 1000 AS ecpm FROM ad_revenue GROUP BY DATE(show_time), ad_slot_id, platform;

这只是一个示例逻辑，真正的生产中还需要处理广告收入延迟上报的问题。比如AdMob的收入会有预估收入（先到账）和调整收入（后修正），建议使用分日数据做校准，避免因为调整收入导致同比波动较大时出现误判。

4.4 看板设计：从“数据堆积”到“决策引导”

指标算出来之后，最后一步是看板。我对看板有两个基本要求：第一，10秒内能够讲清楚当前业务是否有问题；第二，任何指标异常，都能通过看板上的下钻路径找到原因。

所以我的看板通常分三层：

• 第一层“今日核心”：当日新增用户、买量消耗、广告收入、D0/D7 ROAS，以及大盘对照。
• 第二层“按渠道×国家×素材”：用于投放团队每日预算调整，看哪些组合是绿的（ROAS达标可放量），哪些是红的（ROAS不达标需关停）。
• 第三层“归因分析”：如果某渠道ROAS突然异常，从渠道日报点进去后可以看到该渠道下的广告位收入分布、eCPM、人均展示次数、以及成本的变化趋势。

注意看板不是报表。在设计第一层的时候，不要把几十个指标都堆上去，那样每多一个指标，团队都会多一分噪音。

5. 指标体系怎么用：三个真实增长场景的落地打法

5.1 场景一：买量预算怎么分配

这套体系最先解决的是“钱往哪花”的问题。以前团队只看CPA，哪个渠道CPA低就加预算，结果就是低质量的量越买越多，收入盘子越来越大，利润却越来越薄。

用新指标体系后，我把预算分配从“看CPA”改成“看D7 ROAS + 回收周期 + 增量潜力”三个指标的组合，并定了一条基本规则：D7 ROAS ≥ 1.1且回收周期≤20天的渠道优先放量；D7 ROAS在0.85~1.1之间的渠道小步加预算观察趋势；D7 ROAS低于0.85且连续7天没有好转的渠道直接砍量。这个阈值不是拍脑袋定的，我们根据历史数据的稳定度做了校准，不同游戏类型、不同地区阈值都不同。

这里有个实操细节：不要试图把预算均匀分给所有达标渠道，而是把80%的增量预算给到“最大卖量池”中ROAS最好的前三个素材组合。因为IAA买量的核心是“跑稳一个模型”，集中资源才能让媒体平台把模型跑起来，分散投只会每个计划都半死不活。

5.2 场景二：广告变现侧的调优

变现侧的效率问题，单靠投放解决不了，必须是投放、运营、客户端开发三方联动。用变现效率层的指标，可以定位三类常见问题：

• 广告请求率低：说明广告场景入口太少，或激励视频的触发点设置不够顺畅。比如某款消除类游戏，关卡结束页面有关闭按钮，玩家点了关闭就直接回到主界面，根本没有机会看到激励视频。把关闭按钮隐藏改为“看视频获得金币继续”后，激励视频展示量提升约30%，人均展示次数从3.2提升到4.1。
• 展示率低：说明请求返回后，网络或播放器没有把广告正常展示出来。常见原因是广告加载时机太晚，用户已经离开页面或者切了后台，导致广告准备好了但无人观看。
• eCPM低：说明当前广告平台对该用户群或该国家的出价偏低。通常做法是接入聚合SDK，让多个广告平台实时竞价，然后用瀑布流或in-app bidding的方式把每次广告请求都卖给出价最高的平台。

在这个场景下，我会额外监控一个“单用户广告收入结构”指标，看激励视频、插屏、Banner分别占多少。理想情况下，激励视频占比约60%-70%，插屏20%-30%，Banner和开屏各贡献少量。如果激励视频占比过低，说明用户的“广告动机”没有被充分调动，光调eCPM解决不了深层问题。

5.3 场景三：产品功能与广告场景的联动

指标准体系不只是买量和变现团队在看，产品经理也应该用。比如，产品团队想做一个“新用户前3日双倍金币”的活跃活动，目标是提升留存和广告展示次数。能不能做？可以做，但要用指标来回答“值不值得”。

具体做法是把活动前后的新用户队列做对比：对照组不放活动，实验组放活动，看实验组的7日留存、D7 LTV、D7 ROAS是否优于对照组。如果留存提升但ARPU下降，说明活动吸引来的“只看广告没有用”的羊毛党增加，要小心。如果留存提升且ARPU同步提升，说明活动真正驱动了用户的广告参与意愿，是一个正向循环。

这类实验我把它叫做“干预型ROAS实验”，是整套指标体系最能体现增长价值的地方。它不仅能回答“这个活动带来多少收入”，还能回答“这个活动对买量侧模型产生了多大的正向辅助”。

6. 踩坑实录：IAA指标体系建设中常见的6个问题

6.1 问题速查表

6.2 几个值得展开的坑

第一个坑是“预估收入”与“结算收入”的差异。广告平台（比如AdMob）在后端提供的收入通常是预估收入，会有一定偏差，实际结算时会有调整。这个偏差一般不会超过5%，但长期趋势上会造成ROAS被系统性高估或低估。我建议每个月把广告平台结算数据导入内部数据仓库，对历史ROAS做一次校准。别等财务找到你才做这件事，主动校准在业务复盘时更有底气。

第二个坑是“国别混合”带来的误判。很多中小团队买量时量不大，为了过买量平台的模型门槛，会把好几个国家的量放同一个计划跑。结果就是一个计划里美国、巴西、印尼的量混在一起，CPA和ROAS都是一个混合值。这种情况算出来的ROAS几乎没有决策意义。正确的做法是按国家做“预算分组”，哪怕预算少也要分层看。实在没办法分离的，至少要使用“按用户country维度”的明细表去做事后透视。

第三个坑是“只盯D7，不看回收周期”。D7 ROAS达标并不代表这个业务能正常运转，如果回收周期长达40天，而你的垫资能力只能支撑30天，那这个ROAS再高也跟你没关系。指标体系建设期间，一定要把“回收周期”作为一个独立的业务健康度指标纳入周报，让老板知道“赚钱”和“回本”是两个不同概念。

第四个坑是“过分依赖三方平台的面板”。AppsFlyer、Adjust的ROAS面板只看“买量渠道归因”维度，无法覆盖“按素材×广告位×平台”的细拆，也不支持拉取历史数据进行建模。把它当作“快速核对看板”就好，真正的指标体系最好还是基于内部数仓+自助BI搭建。

7. 最后再分享一个关于“指标口径共建”的实操建议

这套体系上线后的很长一段时间，我发现不同角色对“D7 ROAS”的默认口径居然是不一致的。投放团队习惯用“归因平台实时口径”，变现团队用“广告平台后台口径”，数据分析团队用“数仓T+1口径”，财务用“结算口径”。四个口径各有各的道理，但对于同一个决策场景，必须有一个确定的主口径。

我最后定的规则是：日常优化动作（调预算、关计划）使用实时口径，用于快速响应；周度复盘和月度经营会使用T+1数仓口径，用于消除实时数据波动；月度财务结算对账只认结算口径。三个口径并存但各司其职，才真正解决了团队之间吵架的问题。

另外，指标口径一旦确定，就要形成一份对外对内的“指标字典”文档，写明每个指标的计算逻辑、数据来源、更新频率、负责人。这份文档虽然看起来不起眼，但它是新同学入职后最快上手的工具，也是防止团队人员变动后指标理解漂移的关键。

做IAA的ROAS指标体系，我个人的体会是：不要去追求指标多复杂、模型多高级，先把收入的每一分钱从哪来、成本的每一分钱花到哪去搞清楚，这套基础设施打牢了，后面什么LTV预测、预算自动分配、素材智能生成都都建立在一个可靠的地基上。

希望这篇分享能帮你少走几个弯路。有任何具体的口径、埋点或者归因问题，欢迎在评论区讨论。