巴西买量从买安装升级到买付费玩家，靠的不是加预算，而是把广告的优化事件沿漏斗往深处迁移。安装成本达标、回收却始终不达标，通常不是素材问题，而是你给算法的目标停在了漏斗最浅的那一层。算法只会照着你设定的事件找人，目标设成安装，它就去找最容易点下载的人，而不是最可能付费的人。
为什么巴西买量能买到安装、却买不到付费玩家？
先看三个典型症状。第一，单次安装成本达标甚至还在下降，但七日与三十日回收持续不达标，成本曲线与收入曲线明显背离。第二，付费用户高度集中在少数几组素材或少数几个版位，说明付费是偶然撞出来的，大盘并没有付费厚度。第三，把买量用户与自然量用户放在一起对比，教程完成率、次日留存明显更低，这说明买进来的是一批意愿很浅的人。
成因不复杂。巴西是全球安卓入门机占比很高的市场之一，免费游戏用户基数极大，纯粹按安装出价，预算会飞快地被引向最便宜的那部分流量池，而这部分人群的付费转化率往往只有大盘的零头。换句话说，浅层目标在巴西被放大得尤其厉害，别的市场可能只是效率损失，这里会直接变成结构性亏损。
还有一层容易被忽略的账：安装成本低带来的报表美观，会掩盖真实的获客成本。真正该盯的是每付费用户成本与回本周期，前者常常是安装成本的几十倍，只有把它摆到台面上，团队才会有动力去动优化事件。
优化事件的阶梯应该怎么排？
把事件排成四级台阶，从浅到深依次是：安装、轻量激活、关键行为、价值事件。第一级安装数据密度最高，适合冷启动与全新素材的探路。第二级轻量激活包括完成新手教程、首次进入主玩法、账号注册完成，它的量通常是付费事件的几十倍，是最好用的中间层。第三级关键行为包括次日回访、达到指定进度、累计时长达标、首次进入商店页面，这些行为与付费的相关性明显更强。第四级是价值事件，包括首次付费、若干日累计付费金额，以及以目标回报率出价。
选定某一级作为优化目标，需要同时满足三个条件。其一是量够，单个广告组每周要能稳定产生足够数量的该事件，具体门槛以各平台官方文档为准，但经验是宁可高估不要低估。其二是相关性经过验证，不能凭感觉挑一个数字好看的事件，要用历史数据核对该事件与最终付费的关联强度。其三是回传稳定，事件的延迟在归因窗口内、口径统一、去重正确。
巴西还有一个本地特点必须写进方案：付费高度受双周发薪节奏影响，不少用户会在发薪日才完成首次付费，付费转化窗口比很多市场都长。因此任何一级事件的评估窗口，至少要覆盖两个发薪周期，否则得出的结论几乎必然偏悲观。
什么时候才可以往上升一级？
三条判据必须同时成立。第一，当前这一级的周转化量长期高于门槛的数倍，有冗余才禁得起升级后被稀释；刚刚踩线就往上跳，等于主动把自己送回学习期。第二，本级到下一级的转化率在近四周内保持稳定，如果这个比例上蹿下跳，说明产品侧的付费点还没定型，该先修产品而不是改投放。第三，回传链路验收通过，服务端事件与客户端事件已完成去重、参数一致、延迟分布可接受。
有几种情况明确不适合升级：新游戏上线的头两个星期、大版本改动期间、付费点仍在频繁调整时，以及大促或节庆前一周。最后这条常被忽略，旺季前后的数据会被季节性严重污染，此时做迁移，最终分不清成本变化到底来自哪一边。
还要提前对齐预期。升级之后单事件成本必然大幅上升，这是口径变化而不是效果变差，从安装成本变成付费用户成本，量级差出几十倍很正常。这个预期如果没有在动手前跟决策方讲清楚，迁移往往撑不过第三天就会被叫停。
迁移过程怎么做才不塌方？
第一步，并行而不是替换。新建一组以深层事件为目标的系列，与原有结构同时跑，初期预算从总量的两到三成起步，原结构继续承担基本盘，避免一次性把大盘押在一个未验证的设置上。
第二步，只改一个变量。复制原有结构，仅替换优化事件，受众、素材、版位、落地页全部保持一致，否则事后无法判断成本变化来自事件迁移还是别的改动。
第三步，预算给足。日预算至少要能支撑系统在学习期内攒够所需的转化数量，预算不足会让系列长期困在学习期，这是深层事件迁移失败最常见的死法，比事件选错还常见。
第四步，先验收数据链路再切量。用测试事件确认回传成功率、延迟分布与去重逻辑，尤其要核对商店内购事件与服务端回传两条路径的口径是否一致。同时注意，苹果端受聚合测量框架限制，可用的事件位有限，需要事先规划事件的优先级顺序；安卓端则以内购事件与服务端回传为主，两端的方案应分别设计。
第五步，把回退线写死在动手之前。例如设定两周内实验组的付费用户成本高于对照组某一比例且没有收敛趋势就回退。回退不等于失败，它的作用是给学习成本封顶。
深层事件数据太少时，有哪些替代解法？
最实用的是代理事件。挑一个与付费高度相关、但发生频率高出十倍以上的行为作为过渡目标，例如达到某个进度节点或首次打开商店页面，先用它把数据密度喂饱，等付费事件量真正起来再往上升一级。这一步能救回大量卡在数据量不足的账户。
其次是价值分层回传。把付费事件按金额分档回传，让系统能区分小额与高额用户，而不是把所有付费一视同仁。这也是后续启用价值型出价的前提，回传口径没做分层，价值出价就没有可学的信号。
第三是样本聚合。暂时合并过细的拆分维度，例如州级地域、机型档位、语言变体，把数据密度还给算法，等量级起来之后再逐步拆开。很多团队一边抱怨事件量不够，一边又把账户拆成几十个系列，这两件事是矛盾的。
此外，延长评估窗口、改用同期群方式看回收曲线，也能显著改善判断质量。看当日回报率去调深层事件出价，基本等于用噪声做决策。
效果怎么记账、有哪些常见坑？
建议记三本账。事件账记录每一级事件的周转化量、单事件成本、本级到下一级的转化率、回传成功率与延迟分位，这份表是判断能否升级的唯一依据。迁移账记录对照组与实验组的安装成本、付费用户成本、七日与三十日回收、学习期时长，用来判断迁移本身是否成立。收益账记录同预算下的新增付费用户数、回本周期与投入产出比，并用同期群做对比，避免把版本更新或节庆带来的自然增长算成迁移的功劳。
三个坑要避开。一是一步登天，直接从安装跳到目标回报率出价，事件量根本不够，系统长期学不出来，白白烧掉一轮预算。二是事件定义偷懒，把点击充值按钮当成付费事件，结果算法认真地帮你找到了一批只会点按钮的人。三是频繁改目标，一周换一次优化事件，每次都重置学习，账户全年都在学习期里打转。
迁移做对之后，账户的表现会有一个明确特征：安装成本可能上升，但付费用户成本与回本周期同时改善。看到这个组合，就说明预算终于开始流向对的人。
深层事件优化一定比安装优化更贵吗？
单事件成本一定更高，因为统计口径不同，付费事件本身就比安装稀有得多。但真正该比的是每付费用户成本与回本周期。迁移成功的典型表现是安装成本上升、付费用户成本下降，如果两个指标同时恶化并持续两周以上，才说明设置有问题。
每周需要多少个深层事件才够用？
各平台的建议门槛不同，应以官方文档的最新口径为准。实操上的稳妥做法是把门槛值乘以二到三倍作为自己的启用线，因为门槛数字通常是维持运转的下限，而不是跑得好的水平。达不到就先用代理事件过渡。
巴西市场的评估窗口应该设多长？
建议至少覆盖两个发薪周期。当地付费行为与双周发薪节奏关联明显，用七天窗口去评估付费类事件，很容易在低谷期误判为失败而提前砍掉一个其实有效的设置。
苹果端和安卓端的迁移策略需要分开做吗？
需要。苹果端受聚合测量框架约束，可用事件位有限、数据回传粒度更粗，通常要靠事件优先级排序与更长的观察窗口；安卓端可用信号更丰富，可以更快往深层事件迁移。把两端放在同一个系列里做迁移，两边都得不到干净结论。
迁移之后成本涨了，要不要马上回退？
不要。学习期内成本上升属于正常现象，关键看是否有收敛趋势。判断依据应该是动手前就写死的回退线，例如时间与成本差距双重条件同时触发才回退。凭第三天的数字做决定，等于每次都在为学习期付费却从不收获学习成果。