归因与回传的坑：MMP、SKAN、last-click 与增量——为什么你的渠道报表总是骗你

归因与回传的坑：MMP、SKAN、last-click 与增量——为什么你的渠道报表总是骗你

这是海外现金贷获客渠道与 Affiliate 风控系列的第六篇。

前面五篇讲的是：渠道生态全景、联盟与 CPS 分润、代理渠道商管理、渠道反欺诈（上）的机器造假、渠道反欺诈（下）的人造假。

这两篇反欺诈讲的是”有人在骗你”。这一篇讲另一类问题：没人骗你，但你的报表还是错的。

这是很多出海团队最容易忽略的一层。他们花了大力气建反作弊，把假量拦在门外，然后看着报表分配预算——但报表本身的口径就是歪的。归因不是测量，归因是分配。它把一个本来归因不清的结果，强行判给某一个渠道，而这个判法，往往和真实贡献无关。

一个平台花了三个月优化渠道结构，把预算从”看起来差”的 A 渠道挪到”看起来好”的 B 渠道，结果整体回收率反而降了。查下来 A 没做错什么，B 也没做什么特别的事——是归因模型在替另一个渠道领功。

这一篇讲四类坑：归因口径的坑、回传链路的坑、last-click 与增量的坑、数据被篡改的坑。四类都会让报表和真相分家。

一、先分清三件事：归因、回传、增量

讲坑之前，先把三个经常被混着说的词分开。

归因（Attribution）回答的是：”这个用户装机，算谁的功劳？”它有规则——通常是 last-click，即最后一次点击的那个渠道拿全部功劳。

回传（Postback / Callback）回答的是：”这个用户后来干了什么，怎么告诉渠道？”这是技术链路，中间有 MMP、有 SDK、有 SKAN，任何一环断了或错了，数据就失真。

增量（Incrementality）回答的是一个更根本的问题：“如果没有这个渠道的投放，这个用户会不会照样装？”

这三件事的关系是：归因告诉你”用户从哪来”，增量告诉你”用户是不是你带来的”。 前者好测，后者难测，而绝大多数团队只测前者，把前者当成后者用。这就是这一篇所有坑的总根因。

二、第一类坑：last-click 的天生偏差

last-click（最后一次点击归因）是行业默认规则，也是最容易理解、最好实现的一种。但它的偏差是结构性的，不是配置能修的。

问题出在一个简单的事实上：越靠近转化、越容易被看到的触点，越容易拿到功劳。

一个用户可能在两周里经历了这样一条路径：刷短视频看到某个素材（吸引了他）→ 在应用商店搜索（形成意图）→ 点了品牌关键词广告（完成安装）。按 last-click，功劳全归品牌关键词广告。但这三个触点里，真正创造需求的是第一个。

结果就是两类系统性误判：

• 上游的、影响面广的渠道被严重低估。 品牌广告、内容营销、社媒种草——它们的贡献被下游的搜索、直接流量截走了。
• 下游的、临门一脚的渠道被严重高估。 品牌词投放尤其典型：它收割了大量本来就会自然安装的用户，报表上 CAC 极低、转化率极高，看起来是”最好的渠道”，实际增量接近零。

这就是所谓的”抢功”（cannibalization）——不是作弊，是规则本身让下游渠道把上游渠道和自然流量的功劳都算到自己头上。

在实际操作里，最典型的识别信号是：一个渠道的品牌词投放把自然流量的量吃掉了。 你把品牌词预算翻倍，这个渠道的安装量跟着翻倍，但整个 App 的安装总量几乎没变——多出来的部分全是原本的自然安装。这种情况下，你花的钱什么都没买到。

结论一：last-click 只能用来做”渠道之间的相对排序”，不能用来判断”某笔预算值不值得花”。 判断后者，必须做增量测试（第五节详述）。

三、第二类坑：SKAN 时代，iOS 上是”大致估算”

如果你主投 iOS，归因在 2021 年之后就已经不是”精确测量”了，而是”隐私框架下的建模估算”。

苹果的 ATT（App Tracking Transparency）让用户可以选择不被跨 App 追踪，之后大部分 iOS 用户拒绝了授权。原来靠设备级标识符（IDFA）做的确定性归因基本失效，取而代之的是 SKAdNetwork（SKAN）——一套聚合的、有延迟的、粒度受限的归因框架。

SKAN 的几个特点，直接决定了你报表的性质：

• 它是聚合的，不是用户级的。 你拿到的是活动级的转化信号，不是”这个用户从哪来”。
• 它是有延迟的。 回传不是实时的，窗口有先后，数据到齐要等。
• 它的转化值是有上限的。 早期 SKAN 的转换值只有 6 位（64 个可能取值），你必须在区区几十个槽位里，编码进你想知道的全部信息。你想同时知道”有没有注册””有没有首借””借了多少””有没有复借”——塞不下。编码方案一设计错，后面拿到的是系统性失真的数据。

更麻烦的是双重计数。对于少数同意了 ATT 的 iOS 用户，确定性归因和 SKAN 会同时触发。如果你的 MMP（移动测量合作伙伴）默认以 SKAN 为主口径、而去重逻辑没配好，同一个装机可能被算两次——一次算给 SKAN 路径，一次算给确定性路径。

结论二：在 iOS 上，你要分清你看到的是”确定性数据”还是”建模数据”。 建模数据可以看趋势、可以看方向，但不能当精确账本用。把建模数据当精确数据去算单个渠道的 CAC 和 LTV，误差可以大到推翻结论。

四、第三类坑：回传链路本身会断、会错

即使归因规则没偏，回传链路本身也会制造失真。这是最技术、也最容易被忽略的一层坑。

回传链路的典型结构是：你的 App 里装了一个 MMP 的 SDK，用户完成某个事件（注册、首借、还款）时，SDK 把这个事件报给 MMP，MMP 再回传给渠道，渠道据此优化投放。这条链上任何一环出问题，数据都会骗你。

常见的断点和错点：

• SDK 事件没接全或接重。 你以为在上报”首借成功”，实际可能把”提交申请”和”实际放款”混在一起报，或者同一个事件报两次。渠道按错误的事件去优化，优化的是错的目标。
• 回传延迟差导致归因偏差。 渠道 A 的回传链路快、渠道 B 的回传链路慢，那么在统计时点前，A 的数据看起来比 B “好”——不是 A 真的好，是 B 的数据还没到齐。团队如果按”当下数据”分配预算，就会持续地、系统性地高估回传快的渠道。
• 去重没做导致重复计数。 用户可能先看到 A 的广告、后看到 B 的广告，两家都记了功劳。没有 MMP 统一去重，你看到的总安装数会大于真实装机数。
• 跨时区、跨币种、跨账期的口径不一致。 海外市场尤其如此：你的报表按某个时区切、渠道的报表按另一个时区切，”同一天”的数据对不上；回收周期按美元算、实际收入是本币，汇率一变，LTV 的绝对值跟着变。

结论三：在动预算之前，先确认你的回传链路是”完整的、口径一致的、去重过的”。 一个常见的务实动作是：在调整预算前，先看一段时间里”各渠道回传数据之和”和”你系统里的真实事件数”是否对得上。 对不上，说明链路有漏，这时候任何基于渠道报表的决策都不可靠。

五、第四类坑：last-click 与增量之间，缺一个”对照”

这是整篇最重要的一条：归因回答”谁点了最后一次”，增量回答”没有它会不会装”。这两个问题之间，隔着一个实验。

增量测试的核心逻辑很简单：把一部分市场/时间/人群作为对照组，不给它投放，看这一组和投放组的差别。 差别就是真实的增量；如果没有差别，那这个渠道的贡献接近零——它只是把本来就会发生的安装算成了自己的功劳。

主流的几种做法：

• 地域留出（GEO holdout）：选一部分市场做投放、另一部分市场不投，比较两组的差异。它最接近因果判断，因为两组之间唯一的系统性差别就是投放与否。缺点是慢——多数需要数周才能跑出显著性。
• 时间留出（Time-based）：把投放按”开—关—开”的节奏脉冲，看安装量是不是跟着投放起伏。它最轻量，适合没法做地域切分的小市场，但最容易被季节性干扰，必须配一个可靠的基准线。
• 平台自带的提升研究（Conversion Lift）：Meta、Google、TikTok 都提供这个功能，平台随机留出一部分对照人群测提升。优点是统计功效强，缺点是平台在给自己判分，只能当参考、不能当独立证据。

做增量测试最容易踩的坑有两条：

• 对照组被污染。 你以为 A 组没投，但 A 组用户还是可能看到你在 B 组的投放（比如线上广告跨地域溢出），差别就被稀释了。
• 周期太短。 增量效果需要时间显现，跑几天就下结论，得到的是噪声。

结论四：增量是唯一能回答”这笔预算该不该花”的方法，但它是慢方法。 实务上的取舍是：用 last-click 做日常的渠道排序（快但偏），用增量测试（可能一季度一次）去校准那套排序里的系统性偏差。 两个一起用，才是完整的测量体系。

六、第五类坑：数据被篡改，但看起来一切正常

最后一类最阴——不是链路出错，是有人主动改数据。

这一类介于”作弊”和”归因偏差”之间：它不像假安装那样伪造整个用户，而是在归因环节动手脚，让功劳转移到自己头上，或者让损失看起来不存在。

常见的手法：

• 点击注入（Click Injection）：恶意程序监控真实设备，在用户真正开始安装的瞬间触发一次点击，从而拿走 last-click 资格。识别信号的标志是点击到安装时间（CTIT）异常短——真实用户的点击和安装之间通常隔着几分钟到几小时，秒级的 CTIT 基本可以定性为注水。
• 归因参数被改：渠道侧篡改回传里的来源标识，把自己包装成别家的来源。
• SKAN 层面的伪造：即便是 SKAN，也存在”假网络注册假安装、拿到苹果签名回传”的路径——苹果的签名只证明这个安装事件在系统看来是有效的，不能证明它背后有真人。

这一类的识别，最终要回到交叉验证：把渠道回传的数据，和你自己系统里的真实行为数据（首开、注册、首借、还款）做比对。任何显著偏差都是信号——SKAN 回传的安装数和 App 商店首开数对不上，渠道报的安装数和你的 SDK 记录对不上，都要立刻查。

结论五：不要只信渠道自己报的数，也不要只信 MMP 一家之言，要用你自己的第一方行为数据做”第三只眼”。

七、落到操作：一张”渠道数据可信度”自检清单

把上面五类坑收成一张清单，每次动预算前过一遍：

1. 口径核对：我在看的数，是确定性数据还是建模数据？是 last-click 还是增量？各渠道口径一致吗？
2. 链路核对：各渠道回传的事件定义一致吗？有没有重复计数？回传延迟差异会怎样影响当下的排序？
3. 自然流量核对：自然流量（organic）还正常吗？有没有被品牌词投放吃掉？——自然流量是所有付费渠道的基准线，它一旦被污染，所有对比都失真。
4. 异常核对：有没有哪个渠道的 CTIT 分布异常（过短）？
5. 交叉核对：渠道回传数 vs 自己系统的真实行为数，偏差在容忍范围内吗？
6. 增量核对：上一次增量测试是什么时候？现有渠道排序有没有被增量结果证伪过？

六条里,第 3 条和第 5 条是最容易被跳过、又最关键的。自然流量是基准，第一方数据是裁判。

八、小结

三句话收尾。

归因不是测量，是分配。 它把一个归因不清的结果判给某个渠道，而这个判法本身有结构性偏差。看懂报表怎么算出来的，比看懂报表上的数字更重要。

last-click 回答不了”该不该花”，只有增量能。 前者快而偏，后者慢而准。两个一起用，才是完整的测量体系。

最好的防篡改手段，是你自己的第一方数据。 渠道报的数、MMP 给的数，都是别人算的；只有你系统里的首开、注册、首借、还款是你自己的。任何来自外部的数据，都要用第一方数据去校验。

到这里，渠道风控已经从”渠道从哪来”讲到了”数据可不可信”。下一篇进入合规层——裂变与老客运营的合规边界：WhatsApp、Telegram 社群、KOL、转介绍，这些看起来最”自传播”的玩法，恰恰是各国监管最容易踩线的地方。

下篇预告：《裂变与老客运营的合规边界》