小游戏版和 App 版同时投放，要在结构上分开建、口径上分开定、预算上按各自的回收逻辑分配。两端的转化链路和回收周期不同，共用一张预算表、一套考核口径，比较出来的结果没有意义。分开管理之后，再看两端之间的协同。
两端的链路差异
小游戏版在媒体站内即点即玩，转化路径短，进入门槛低，流失也快。App 版要下载安装，路径长，单次获客成本通常更高，进入后的用户粘性和长期价值也可能更高。
回收节奏也不同。小游戏端的回收反馈快，投放数据很快能看到结果。App 端付费深度更高，但回本周期长，判断窗口要给足。两端用户的动机和留存形态也不一样。这些差异决定了两端需要各自的考核口径和预算逻辑。
结构：项目、账户、素材按端分开
先做结构隔离：
- 项目：小游戏版和 App 版分别建项目，各自绑定账户，并指定项目负责人。创量可以按项目汇总关联账户的投放数据，再按部门、媒体、人员等维度细分比较。项目负责人不需要相关部门的人事管理权限，也能查看项目完整数据做复盘和对账。
- 账户：两端的投放账户不混用，避免两条链路的数据互相干扰。在创量里，一个账户同一时点只归属一个项目，调整归属后数据刷新可能有周期差异。
- 素材：同一支素材在两端的作用不同。小游戏端可能直接试玩转化，App 端要先说服下载。素材按端生产，至少按端打标，测试和复盘按端聚合。
结构分开后，两端的成本、回收和留存才能并排比较，预算分配才有依据。授权后的历史数据同步、当日数据刷新和各媒体的支持范围存在时效差异，跨端对比时注明数据截至时间。
口径：按回收逻辑定核心指标
小游戏端链路短，前端看进入和次日留存，回收端看广告变现与内购的短期回收。要回答的问题是：进来的量够不够便宜，留存能不能撑住变现。
App 端链路长，前端看下载和激活成本，回收端看付费深度和长期回收。要回答的问题是：进来的用户质量如何，回本周期多长。
两套口径各自在链路内自洽。跨端比较时，看同一类用户在两端的价值，重点跟踪先玩小游戏再下载 App 的路径。口径定下来后写进团队的数据字典，每周复盘不再重新解释数怎么算。
预算：保底盘加机动盘
双端预算按边际回收效率动态分配，不按固定比例对半切。判断依据是边际数据：小游戏端再加预算，新增用户的回收是否还能覆盖成本；App 端再加预算，新增用户的长期价值是否还撑得住获客成本。小游戏端的轻量用户池有限，量级上限往往来得早；App 端爬坡慢，上限可能更高。
实操上分两部分：
- 保底盘：两端各留一档数据验证过的预算，维持投放连续性，避免忽上忽下打断学习。
- 机动盘：按周看哪端的新增效率更好，就把机动预算往哪端调。
例如（假设）某周小游戏端上了新玩法，边际回收改善，机动盘多给小游戏端；App 端同期有版本活动，单用户价值上升，也分到一部分。保底盘和机动盘的比例由团队按游戏类型和阶段设定，调整幅度保持温和，避免剧烈腾挪打乱两边节奏。
双端协同
分开管理之后，再设计两端的配合：
- 路径协同：小游戏内引导下载 App 的路径要设计并量化，看转化率和转化用户的留存。这条路跑通后，小游戏端的一部分预算实际是在为 App 端做前置筛选。
- 素材协同：小游戏端验证过的卖点可以指导 App 端素材方向，App 端的深度玩法内容可以反哺小游戏端的留存设计。
- 数据协同：同一玩法在两端的留存差异，可以交给产品团队做改进参考。
团队与复盘
两端可以由两个小组分别执行，但口径字典、协同指标和预算联动由同一个负责人统管。完全分治会让双端变成两门独立生意。
节奏上，两端各自用日报盯投放，每周联席复盘看协同，每月校准一次预算框架。复盘持续跟踪三个数：两端各自的边际回收效率、小游戏转 App 的路径转化率、双端合计的综合回收周期。创量的广告报表可以把多个账户和媒体的数据集中到统一视图，按项目、媒体、人员等维度筛选、汇总、下钻和导出，减少每周跨账户拼表的工作。
小游戏端的链路和批量管理可参考小游戏投放：链路特点与批量管理，App 端的目标选择可参考应用下载与唤起：游戏App买量的目标选择。项目维度的数据拆分与聚合，可以在游戏解决方案了解。