归因分析v1.0：渠道归因口径、模型对比与SQL落地

某公司的市场部和增长部为了预算的事吵了三轮，两边报表上的数字差了将近一倍。市场部说搜索渠道贡献了四成转化，增长部回了一句：你那是末次点击，用户先看了三轮信息流、又被内容社区种草、最后才搜了个品牌词进来，你把功劳全算在收尾那一下了。这种争吵我在不同团队里见过太多次，表面上是渠道功劳之争，本质上是归因分析的口径没有对齐。归因分析这四个字听起来像算法问题，实际上八成的坑都在数据和定义上：触点怎么记、窗口怎么定、身份怎么打通、结果怎么归一。模型反而是最简单的一环，几行 SQL 就能算完。

这篇东西定位是 v1.0，意思很明确：先做一版对得上账、能支撑决策、能被业务方看懂的归因体系，而不是去追求所谓"精准"。我在几个不同类型的业务里从零搭过这套东西，也接手过别人搭了一半的烂摊子，最深的体会是——第一版做得越"全"，死得越快。下面这些内容适合数据分析师、增长运营、投放负责人，以及任何需要拿渠道数据去说服别人的角色。哪怕你现在只有一张埋点表和一份订单表，也能照着把第一版跑出来。

1. v1.0 的边界：先锁死一个问题，而不是先挑一个模型

1.1 追求"精确归因"在第一版就是给自己挖坑

用户从第一次听说你到最终下单，中间可能跨了三台设备、看过两次线下物料、被朋友口头推荐过一次、在某个平台刷到过短视频但没点。这条真实路径里，你能观测到的部分可能连一半都不到。未登录状态下的设备漂移、应用之间的跳转断裂、隐私策略收紧之后的标识符缺失，每一样都在告诉你：完整路径不可得。

我见过有团队为了解决这个问题，先花两个月做 ID-Mapping，再花一个月接第三方归因工具，最后发现打通率只提升了十来个点，而业务方等了三个月还没看到一张能用的渠道报表。这就是典型的把工程复杂度排在了业务价值前面。

体温计不需要精确到 0.001 度，能判断有没有发烧就够了。归因分析 v1.0 的目标不是还原真相，而是建立一套口径统一、可复现、能支撑相对排序的度量方式。只要全公司用的是同一把尺子，哪怕这把尺子本身有点误差，也比三个部门各拿一把尺子互相指责要好得多。

1.2 把"哪个渠道效果好"翻译成一句可验证的话

"哪个渠道效果好"这句话没法验证，因为它同时混了三个维度：效果指什么（转化数、GMV、还是新客数）、在什么范围内算（哪个时间窗、哪些渠道）、好坏怎么比（绝对值还是边际效率）。不把这三点拆开，任何归因结果出来都会被质疑。

我习惯让提需求的人把问题写成一句带参数的话，比如："在 7 天点击窗口内，五个付费渠道对已支付订单的末次点击贡献占比分别是多少，换成线性归因后排序会不会变。"这句话里包含了范围（五个付费渠道）、口径（末次点击、7 天窗口）、产出（占比 + 排序对比）。写不出这句话，说明需求还没想清楚，先别动 SQL。

这个动作看着像形式主义，实际能省掉后面 80% 的返工。因为一旦口径写死了，后面所有的争论都会聚焦在"这个窗口合不合理""要不要加新客口径"这种可讨论的问题上，而不会变成"你的数不对"这种无解的扯皮。

1.3 第一版必须交付的五样东西

这五样里，最容易被忽略的是口径说明卡。它其实就是一页纸，写清楚"这次统计包含哪些渠道、窗口多长、同渠道重复曝光怎么处理、退款订单算不算"。听起来很土，但它是唯一能在三个月后解释"为什么这次的数和上次不一样"的东西。我现在的习惯是把它直接贴在报表页顶部，谁看数谁先看它。

2. 触点数据的形状，直接决定了归因结果的天花板

2.1 一条合格的触点记录该长什么样

归因的上限由数据决定，模型只能在给定的数据上做分配。一条能被用于归因的触点记录，至少要包含下面这些字段，缺任何一个都会在某个环节卡住。

最后一行经常被跳过，很多团队的 cost 数据躺在投放系统的后台导出表里，从来没进过数仓。结果就是归因结果只有"功劳占比"，没有"投入产出"，业务方看完只会问一句"所以呢"。我在第二个项目里吃过这个亏，后来强制要求成本数据按天、按 campaign 落到同一张表里，归因结果才能直接算出每个渠道的产出投入比。

2.2 埋点里最常见的三个缺口

第一个是曝光数据只有部分渠道有。信息流、内容社区这类渠道能回传曝光，搜索渠道基本只有点击。这会导致多触点模型天然对能回传曝光的渠道更友好——它们的路径更长、触点更多，在线性模型下分到的权重自然更高。处理办法要么统一只用点击做归因，要么在模型里对曝光降权。

第二个是点击回调的参数没落到用户维度。有些渠道回传的点击事件里只有广告ID，没有能关联到站内用户的标识，需要靠落地页参数透传或者唤起时的参数携带来找回。这块做不好，等于这个渠道的触点全是"孤儿"。

第三个是时间字段用了客户端时间。用户手机时间不准是常态，差几分钟到几小时都有。一旦路径排序依赖客户端时间，就会出现"转化发生在点击之前"这种荒谬的结果。统一用服务端接收时间，是唯一稳妥的选择。

2.3 身份打通程度决定了归因粒度

这个问题在移动端尤其突出。用户 A 在手机上看到广告、在平板上完成下单，如果两个设备没有绑定到同一个账号，这条路径就是断的，归因结果里手机端的渠道什么都拿不到。

实操上我一般会先测一下登录态覆盖率：把当月有转化的用户按"转化前是否有登录行为"分组，看看未登录转化的占比。这个数字在不同业务里差别很大，工具类可能只有两成，内容类能到五成以上。占比越高，说明你的归因结果越依赖设备ID兜底，而设备ID在换机、清缓存、隐私限制下会失效。

提示：在口径说明卡里必须写清楚"未登录转化如何处理"。是直接剔除、归入"未知渠道"，还是用设备ID尽力关联，三种做法算出来的渠道占比能差十几个百分点。

2.4 归因窗口与去重规则，得先定死

窗口长度不是拍脑袋定的，它应该匹配业务的决策周期。快消类、工具订阅类，用户从看到广告到下单可能就一两天，7 天窗口足够；大家电、教育课程这种长决策品类，7 天窗口会把大量路径拦腰截断，需要放到 30 天。我一般的做法是拉一张"转化距最后一次触点的时间分布"图，看累积曲线在哪个点走平，窗口就取那个位置。

去重规则同样影响巨大。同一个用户在同一天被同一个渠道触达了 8 次，是算 8 个触点还是 1 个？如果不去重，高频曝光的渠道在路径里会占满位置，线性模型下几乎通吃。我在第一版里用的是"同渠道同自然日合并为一次，取最早时间"，简单、可解释，业务方也不会觉得你在偏袒谁。

3. 六种模型的功劳分配逻辑与各自的偏见

3.1 单触点模型：简单，但偏见极其明显

末次点击把 100% 的功劳给路径上最后一个触点。它的优点是极其好对账——归因结果里的转化数可以和订单表一一对应，业务方挑不出毛病。缺点是它系统性地偏向"收割型"渠道：品牌词搜索、召回短信、联盟返利站、购物车挽回推送，这些渠道做的事情是在用户已经决定买的时候推一把，拿走全部功劳显然不合理。

首次点击则反过来，把功劳全给第一个触点，偏向"拉新型"渠道，比如内容种草、开屏曝光、新客信息流。它的问题是忽略了中间所有的培育动作，而且对于老用户复购场景几乎失效——老用户的"首次触点"可能是两年前。

首次非直接访问是首次点击的一个改良版，把直接访问、自然流量这类"没有明确来源"的触点跳过，取第一个有渠道标记的触点。这个变体在实操中挺有用，因为它避免了"用户直接打开 App 就下单"这种路径把功劳白白送掉。

3.2 多触点模型：把功劳摊开，但也把解释成本抬高了

线性模型把功劳均分给路径上的 n 个触点，每个拿 1/n。它最公平，也最没有观点——一个只出现过一次的渠道和一个出现五次的渠道，在单条路径里的相对权重是一样的，但在汇总层面，出现频次高的渠道总功劳更大。线性模型适合回答"哪些渠道接触面最广"这类问题。

时间衰减模型给每个触点按0.5^(t / 半衰期)算权重，再归一化。半衰期的意思是"距离转化 t 天前的触点，权重衰减到一半需要多少天"。电商场景我一般取 7 天，长决策品类取 14 到 30 天。这个模型的直觉是"越靠近转化的触点影响越大"，比较符合实际，但半衰期这个参数需要业务方认可，否则每次复盘都要重新吵一遍。

位置归因（U 型）给首尾各 40%，中间所有触点平分剩下的 20%。它承认"开篇种草"和"临门一脚"都重要，是很多团队第一版的默认选择。需要注意的是当路径只有 1 到 2 个触点时，40/40 加起来只有 0.8，必须做归一化，否则功劳总量对不上。

3.3 数据驱动模型：理论漂亮，落地成本高

马尔可夫链的做法是把所有用户路径建成一个状态转移图，算出各渠道的"移除效应"——把这个渠道从图里拿掉之后，整体转化率下降多少，下降幅度就是它的功劳。它回答的是"谁缺席影响最大"，比单纯的路径位置更有说服力。

Shapley 值来自合作博弈论，把每个渠道在所有可能的渠道组合中的边际贡献取平均。理论上它是唯一满足对称性、有效性、可加性的一致性分配方案，听起来无可挑剔。但它的计算量随渠道数指数增长，5 个渠道是 32 种组合，10 个渠道就是 1024 种，实际落地一般用采样近似。

这两个模型的共同门槛是数据量。每个渠道至少要有几百次转化，路径组合才有统计意义。如果某个渠道一个月只有几十单，算出来的移除效应全是噪声。另外还有一个更现实的问题：业务方听不懂。你跟他解释"边际贡献的期望值"，他只会问"所以搜索到底该拿多少钱"。我的经验是，这两个模型放在 v2.0 作为交叉验证手段，v1.0 阶段不要碰。

3.4 模型选择对照表与我的推荐路径

v1.0 阶段我建议同时跑末次点击、线性、位置归因三个模型，然后在报表里并排展示。理由很实在：如果一个渠道在三种模型下排序都靠前，那它一定值得投；如果它在末次里第一、在线性里掉到第五，那说明它是个纯收割渠道，讨论的时候就有了具体抓手。这比只用一个模型然后被人质疑"你这是不是偏心"要高效得多。

4. 用一段 SQL 把归因链路真正跑通

4.1 路径归集：把散点事件拼成会话路径

归因的本质是一次区间关联：对每个转化，找出它发生之前窗口内的所有触点。用 SQL 实现就是一个带时间条件的 join，关键在于先做去重，再做排序。

-- 触点去重：同渠道同自然日合并为一次，保留最早时间 WITH touch_dedup AS ( SELECT user_id, channel, campaign_id, DATE(event_ts) AS touch_date, MIN(event_ts) AS event_ts FROM dwd.touch_log WHERE event_type = 'click' AND dt BETWEEN '2024-12-01' AND '2025-01-31' GROUP BY user_id, channel, campaign_id, DATE(event_ts) ), -- 锁定转化：只算已支付且金额为正的订单 conv AS ( SELECT user_id, order_id AS conv_id, pay_time AS conv_ts, pay_amount AS amount FROM dwd.order_pay WHERE dt BETWEEN '2025-01-01' AND '2025-01-31' AND order_status = 'paid' AND pay_amount > 0 ), -- 区间关联：把 7 天窗口内的触点挂到转化上 path AS ( SELECT c.conv_id, c.user_id, c.conv_ts, c.amount, t.channel, t.campaign_id, t.event_ts, ROW_NUMBER() OVER (PARTITION BY c.conv_id ORDER BY t.event_ts, t.channel) AS rn, COUNT(*) OVER (PARTITION BY c.conv_id) AS n, TIMESTAMPDIFF(HOUR, t.event_ts, c.conv_ts) / 24.0 AS days_before FROM conv c JOIN touch_dedup t ON t.user_id = c.user_id AND t.event_ts <= c.conv_ts AND t.event_ts >= c.conv_ts - INTERVAL 7 DAY )

这里有两个细节值得说一下。ORDER BY t.event_ts, t.channel里加了 channel 作为第二排序键，是为了在同一秒有多个触点时保证结果稳定，否则每次跑出来的 rn 可能不一样，报表数字会莫名抖动。另外TIMESTAMPDIFF算的是小时再除以 24，用小数而不是整数天，是为了让时间衰减模型在一天内也有区分度。

4.2 功劳分配：用一张权重表让模型可切换

把所有模型的计算逻辑写在一个 CASE 里，用参数控制，这样切换模型不用改代码，也方便三种模型同时产出做对比。

scored AS ( SELECT *, CASE '${model}' WHEN 'last' THEN IF(rn = n, 1.0, 0.0) WHEN 'first' THEN IF(rn = 1, 1.0, 0.0) WHEN 'linear' THEN 1.0 / n WHEN 'position' THEN CASE WHEN n = 1 THEN 1.0 WHEN rn = 1 OR rn = n THEN 0.4 ELSE 0.2 / (n - 2) END WHEN 'decay' THEN POWER(0.5, days_before / 7.0) ELSE 1.0 / n END AS raw_weight FROM path ), normalized AS ( SELECT *, raw_weight / SUM(raw_weight) OVER (PARTITION BY conv_id) AS weight FROM scored )

归一化这一步是整段代码里最重要的设计。有了它，position模型在 n=2 时算出来的 0.4 + 0.4 = 0.8 会被自动修正成 0.5 + 0.5，n=1 时的边界情况也不用单独处理。所有模型共享同一套归一化逻辑，就不会出现"某个模型下功劳总量不等于转化总量"这种尴尬。

4.3 结果表结构与自检查询

最终的产出表我一般按渠道和计划两个粒度各存一份，字段包括触点转化数、功劳转化数、功劳金额、金额占比。这里要注意touch_conv_cnt和credit_conv是两个不同的概念，前者是"这个渠道参与过的转化有多少"，后者是"这个渠道分到多少转化"。

SELECT channel, COUNT(DISTINCT conv_id) AS touch_conv_cnt, SUM(weight) AS credit_conv, SUM(weight * amount) AS credit_gmv, SUM(weight * amount) / SUM(SUM(weight * amount)) OVER () AS gmv_share FROM normalized GROUP BY channel ORDER BY credit_gmv DESC;

自检同样重要，我通常把这几条查询固化成一个校验脚本，每次跑完自动执行：

-- 校验一：每个转化的功劳是否守恒 SELECT conv_id, SUM(weight) AS w FROM normalized GROUP BY conv_id HAVING ABS(SUM(weight) - 1) > 1e-6; -- 校验二：有多少转化完全没有触点（会拉低整体归因覆盖率） SELECT COUNT(*) AS orphan_conv FROM conv c LEFT JOIN touch_dedup t ON t.user_id = c.user_id WHERE t.user_id IS NULL; -- 校验三：归因总金额是否等于订单总金额 SELECT (SELECT SUM(credit_gmv) FROM normalized) AS attr_gmv, (SELECT SUM(amount) FROM conv) AS order_gmv;

校验一返回空才算通过。校验二的结果直接决定这份报表能不能用，如果孤儿转化占比超过四成，说明身份打通有问题，报表只能当趋势看，不能做绝对值对比。校验三在窗口和去重都正确的前提下应该完全相等，差一分钱都说明 join 出了问题。

5. 上线前必须过的四道校验关卡

5.1 守恒校验：功劳不能凭空产生，也不能凭空消失

这条是归因体系的底线。每个转化的功劳加总必须严格等于 1，汇总后的归因 GMV 必须等于订单 GMV。听着像废话，但实际项目里翻车的方式千奇百怪：位置归因忘了归一化、时间衰减在某些极端路径下权重全是 0、去重后的路径里出现了空 channel 导致 CASE 落到了 ELSE 分支。

我还遇到过一次更隐蔽的：某个渠道的 campaign_id 里有特殊字符，导出到 CSV 再导入的时候被截断，导致两条本该合并的触点变成了两条独立记录，路径长度凭空多了一个。守恒校验没查出来，因为权重还是加总为 1，只是分配的基数错了。后来靠对账才发现。

所以守恒校验是必要条件不是充分条件，还得配合下面几道。

5.2 对账校验：和谁对，差在哪，要能说清楚

归因结果一定要和至少两个外部数据源对一遍：一是媒体后台报的转化数，二是 BI 系统里订单表的转化数。

和订单表对不上，说明你的过滤条件有问题——可能是没排除测试订单、没扣除退款、或者状态判断用了paid但业务上还有settled状态。这类差异必须清零。

和媒体后台对不上，那就太正常了，而且永远对不上。原因有几种：媒体的归因窗口通常是"曝光后 24 小时 + 点击后 7 天"这类复合口径，和你自己定的窗口不同；媒体统计的是它自己能观测到的转化，跨设备、跨应用的情况它抓不到；媒体的去重逻辑是按它的广告ID，和你的用户维度不是一回事。我一般的处理是：在报表里单独列一栏"媒体后台口径转化数"，并注明"仅供参考，不与归因结果直接比较"。把它摆出来，比藏起来让业务方自己发现要好。

5.3 回放校验：用历史数据验证口径稳定性

新口径上线前，我会拿过去三个月的数据重跑一遍，然后看两件事：一是月度之间的渠道排序是否稳定，二是重大活动期间的口径是否失真。

如果某个渠道在三个月的排序里从第一掉到第四又跳回第一，说明它的路径特征对时间高度敏感，可能是个强活动驱动的渠道，报表里要单独标注。如果大促期间的归因覆盖率和日常差了十几个点，说明大促期间有大量新用户涌入、登录态缺失，这时的归因结果要打折扣看。

回放还有一个作用是给业务方建立预期。把回放结果和旧口径并排放在一起，提前告诉他们"换成新口径后，A 渠道会从 30% 掉到 18%，原因是……"，总比上线当天被质问要好。

5.4 边界校验：窗口两端和延迟回传

窗口的边界条件最容易出问题。一个转化发生在 1 月 1 日凌晨 2 点，它的 7 天窗口要回溯到 12 月 25 日，如果你的触点表只取了 1 月的数据，这个转化的路径就是空的。所以触点表的取数区间必须比转化表提前一个窗口长度，这个细节我踩过不止一次。

延迟回传是另一个日常困扰。渠道的点击回传可能延迟几小时到一天，订单支付状态也可能是异步更新的。结果就是最近两三天的归因数据永远偏低，然后每天都有运营跑来问"昨天数据怎么掉了"。解决办法是在报表里加一个"数据完整度"标记，最近三天标灰，并在口径说明里写清楚"T+2 之后数据才稳定"。这个小改动能省掉大量解释成本。

时区也别忘了。如果业务跨时区，触点时间和转化时间必须统一到同一个时区再算差值，否则会算出一堆负数的 days_before。

6. 归因结果落到决策上的三种用法

6.1 预算再分配：看的是边际效率，不是平均产出

拿到归因结果之后最常见的错误用法是：把每个渠道的功劳 GMV 除以花费，算出产出投入比，然后砍掉比值低的、加投比值高的。这个做法的问题在于它假设效率是线性的——实际上所有渠道都存在边际递减，一个渠道现在比值高，是因为它还没吃饱，加投三倍之后比值可能腰斩。

正确的做法是把归因结果和分档花费数据结合起来看。具体操作是：把每个渠道过去几个月按日花费分成低、中、高三档，分别算各档的归因产出投入比。如果某渠道在高档位的比值明显下滑，说明已经接近饱和；如果在三档之间都很平稳，那还有加投空间。这个分析比单纯的排序有用得多，因为它回答的是"再多给一块钱该给谁"。

6.2 归因数据不能直接推导增量性结论

这是我在复盘中反复强调的一点：归因是分配，不是因果。末次点击告诉你搜索渠道在转化前最后出现了，但它没告诉你如果没有这个搜索广告，用户是不是照样会搜品牌词进来。这两个问题的答案可能完全相反。

举个具体的场景。某业务停了某信息流渠道两周做测试，归因报表上这个渠道的功劳占比一直稳定在两成，看起来很重要。但停投之后整体订单量只掉了 3%。原因很简单：这个渠道触达的大部分是本来就会转化的老用户，它的作用是被归因模型高估的。反过来也有情况：某个内容渠道在归因里只占 5%，但停掉之后新客获取成本整体上升了两成，因为它在做的是长周期的认知铺垫，功劳被下游渠道截走了。

所以归因结果的正确用法是发现值得验证的假设，而不是直接下结论。看到某个渠道功劳很高，下一步动作应该是设计一个增量实验去验证，而不是立刻加预算。

6.3 三角验证：归因、实验、组合模型各管一段

成熟一点的做法是让三种方法互为参照。

归因负责日常监控和快速定位，实验负责验证因果，组合模型负责长期预算规划。三者结论一致的时候，决策可以放心做；结论打架的时候，优先信实验，其次信组合模型，最后才信归因。这个优先级我是吃过亏才定下来的——曾经因为归因报表上某渠道占比高，推动加投了三个月，最后实验证明增量几乎为零，钱基本打了水漂。

7. 跑完第一版才明白的几个坑

渠道命名不统一，是归因体系最常见的慢性病。投放的同学今天写 "InfoFlow"、明天写 "信息流"、后天为了区分素材又加了后缀 "信息流-测试"，结果同一个渠道在报表里裂成了七八行。解决办法是建一张渠道映射维表，在数据入口处做强制映射，任何不在枚举里的值直接落进"未分类"并报警。这件事必须在 v1.0 就做，越晚改代价越大。

自然流量容易变成垃圾桶。所有关联不上渠道的转化，最后都会落到"直接访问"或"未知"里。如果这个桶越来越大，说明你的身份关联或者参数透传出了问题，而不是用户真的都直接访问。我一般会盯着这个桶的占比，超过 35% 就开始查链路。

一个用户多次转化，路径会被反复复用。用户一周内下了三单，前两单的路径可能完全一样，那么同一条路径的功劳会被计算三次。这在业务上是合理的（路径确实贡献了三次转化），但在解读时要注意，高频复购用户的路径权重会被人为放大。解决办法是分新客、老客两套报表，别混在一起看。

退款和撤单没扣，会让某些渠道虚高。有些渠道带来的订单退款率明显高于平均，如果只看支付不管退款，这个渠道的功劳就是虚的。v1.0 至少要做到月度维度扣减退款，日维度可以先用支付口径并在说明里注明。

归因覆盖率的下降往往比占比变化更重要。如果某个月覆盖率从 70% 掉到 55%，那这个月所有的渠道占比都不可信，因为丢失的那 15% 可能集中在某个特定渠道。我现在的习惯是把覆盖率作为报表的第一行指标，它掉下去的时候，后面的数字都不看。

最后分享一个实操上的小技巧。第一版上线之后，别急着推广给全公司，先找两三个最挑剔的业务方单独过一遍口径，让他们挑刺。他们挑出来的问题，往往就是全公司后面会问的问题。等这几个人认可了，再去开大会宣讲，阻力会小非常多。归因这件事，技术上有多少难点其实有限，真正难的是让一群人愿意用同一把尺子量东西。