电商 GMV 归因分析项目复盘：从人工拆维度到 AI 自动化

大家好，我是朱大喜。今天来聊聊我做过的印象最深的一个项目——电商 GMV 归因分析从手工时代走向 AI 自动化的全过程。这个案例横跨了数据仓库、指标体系、机器学习三个领域，踩过的坑比走过的路还多，总结下来希望能帮到正在做类似需求的小伙伴。

一、项目背景：为什么要做 GMV 归因

先说说场景。我们负责一个中等规模的电商平台，月度 GMV 在千万级别。老板每周一早会必问三个问题："上周 GMV 涨了还是跌了？"、"哪个因素影响最大？"、"接下来怎么调？"。

传统做法是：数据分析师跑 SQL 拉各维度数据（渠道、品类、活动、客单价……），手动拆解变化量的贡献度，写一份 Excel + PPT 的周报。整个过程大概要花6~8 小时，而且口径经常不一致——甲说流量贡献30%，乙用另一套算法算出来25%，开会变成吵架会。

核心痛点很明确：

• 效率低：手工拆维度，重复劳动多
• 口径乱：没有统一的归因方法论
• 决策慢：数据出来了，活动窗口期已经过了

二、核心方法论：Shapley 值如何应用在 GMV 归因

归因分析的本质是一个"分蛋糕"的问题。GMV 变化了100万，这100万怎么分配给流量、转化率、客单价、品类结构等各因素？

我们团队最终选用了博弈论中的 Shapley 值作为归因框架。为什么不用简单的连环替代法？

连环替代法的结果依赖于因子替换顺序。举个例子：先替换流量再替换转化率，和先替换转化率再替换流量，分配给流量的贡献值不一样！这在业务方看来就是"搞鬼"，解释不通。

Shapley 值的核心思路是：考虑所有可能的因子顺序，取边际贡献的均值。数学上表达为：

φ_i = Σ_{S⊆N{i}} [|S|! × (n - |S| - 1)! / n!] × [v(S∪{i}) - v(S)]

翻译成人话：对于因子i，我把它在每一种可能的"加入顺序"里带来的增量价值加权平均一下，就是它的公平贡献。

import numpy as np from itertools import combinations, permutations def shapley_gmv_attribution(factors, predict_fn): """ 用 Shapley 值计算各因素对 GMV 的贡献度 factors: dict, 各因素的基准值和实际值 predict_fn: 函数，输入各因素值，输出预测的 GMV """ n = len(factors) # 基准 GMV：所有因素取基准值时的 GMV base_values = {k: v['base'] for k, v in factors.items()} base_gmv = predict_fn(base_values) # 实际 GMV：所有因素取实际值时的 GMV actual_values = {k: v['actual'] for k, v in factors.items()} actual_gmv = predict_fn(actual_values) total_change = actual_gmv - base_gmv shapley_values = {} for factor in factors: marginal_sum = 0 other_factors = [f for f in factors if f != factor] # 遍历所有不包含当前因子的子集 for k in range(n): for subset in combinations(other_factors, k): subset = list(subset) # 计算权重：|S|! * (n - |S| - 1)! / n! weight = (np.math.factorial(len(subset)) * np.math.factorial(n - len(subset) - 1) / np.math.factorial(n)) # 不含当前因子的 GMV val_without = predict_fn(_make_values(factors, subset, use_actual=False)) # 加入当前因子后的 GMV val_with = predict_fn(_make_values(factors, subset + [factor], use_actual=True)) marginal_sum += weight * (val_with - val_without) shapley_values[factor] = marginal_sum # 验证归因之和是否等于总变化量（这是 Shapley 值的优良性质！） assert abs(sum(shapley_values.values()) - total_change) < 0.01 # 计算贡献百分比 total = sum(abs(v) for v in shapley_values.values()) contribution = {k: v / total * 100 for k, v in shapley_values.items()} return shapley_values, contribution, total_change def _make_values(factors, subset, use_actual): """辅助函数：构建因子值字典，指定子集中的因子用实际值，其余用基准值""" values = {} for f in factors: if f in subset and use_actual: values[f] = factors[f]['actual'] elif f in subset: values[f] = factors[f]['actual'] else: values[f] = factors[f]['base'] return values

Shapley 值的最大优点是什么？可加性——各因素的贡献加起来一定等于总变化量。业务方再也不用怀疑你"做手脚"了。

三、工程落地：从 Jupyter Notebook 到自动化 Pipeline

方法论没问题，但真正让这个项目"站住脚"的是工程化落地。我们分了三步走：

第一步：统一数据口径。之前 GMV 有 3 个口径：订单侧的、支付侧的、财务侧的，三个数对不上是常态。我们先在数据仓库里建了统一的dws_gmv_daily宽表，明确 GMV = 支付金额 - 退款金额，争议订单单独标记。

-- 统一 GMV 口径的 DWS 层宽表 CREATE TABLE dws_gmv_daily AS SELECT dt, -- 渠道维度 channel, channel_sub_type, -- 用户维度 user_type, -- 新客/老客 user_level, -- 会员等级 -- 品类维度 category_l1, category_l2, -- 价格维度 CASE WHEN unit_price < 50 THEN '0-50' WHEN unit_price < 200 THEN '50-200' WHEN unit_price < 500 THEN '200-500' ELSE '500+' END AS price_bucket, -- 核心指标：统一口径 SUM(pay_amount) AS gmv, -- 支付金额 SUM(refund_amount) AS refund_amount, -- 退款金额 SUM(pay_amount - COALESCE(refund_amount, 0)) AS net_gmv, -- 净 GMV COUNT(DISTINCT order_id) AS order_cnt, COUNT(DISTINCT user_id) AS user_cnt FROM dwd_order_detail WHERE dt = '${bizdate}' GROUP BY dt, channel, channel_sub_type, user_type, user_level, category_l1, category_l2, price_bucket;

第二步：构建归因引擎。用 Airflow 调度，每周一自动触发归因计算。核心流程是：

1. 拉取上周和上上周的各维度汇总数据
2. 对比算出差值，判断是否需要归因（阈值：GMV波动超过5%才触发）
3. 运行 Shapley 归因算法
4. 生成 Markdown 格式的分析报告
5. 通过飞书 Webhook 推送到业务群

第三步：AI 增强。这才是画龙点睛的一笔。Shapley 值告诉你"流量贡献了 42%"，但业务想知道的是"流量为什么变了？要不要投钱？"。我们接入了大模型，让它基于归因结果自动生成业务建议。

四、效果与思考

这个项目上线后，效果超出预期：

但也有一些"意外发现"：

• AI 生成的分析偶尔会"过度联想"，比如把促销活动的影响错误归因到品类结构，需要人工兜底审核
• 业务方接受度是逐步提升的，最开始运营总监觉得"机器算的不可信"，跑了一个月对照实验后才完全接受
• Shapley 值的计算复杂度是 O(2^n)，4个因子要算 2^4=16 种组合，6个因子就是 64 种，如果预测函数本身很重（比如调一个模型），性能会成问题

五、总结

GMV 归因这个项目让我深刻体会到：数据分析的价值不在"算出来"，而在"用起来"。传统手工拆维度不是做不了，而是没法持续稳定地输出；AI 自动化不只是提效，更重要的是把分析能力标准化、可复制化了。

给同行的建议：如果你的日常工作中存在大量重复性的"拆维度、写报告"劳动，不妨从 Shapley 值入手，搭建一套自动化归因系统。方法论是成熟的，需要打磨的是数据口径的规范和业务解释的适配。

归因分析不是数学游戏，是让数据说真话的能力。

如果觉得有帮助，点赞收藏走一波~ 下一篇我们来聊聊用户留存分析，用 SQL 写一个完整的 Cohort 分析。