电商 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_actualFalse)) # 加入当前因子后的 GMV val_with predict_fn(_make_values(factors, subset [factor], use_actualTrue)) 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 valuesShapley 值的最大优点是什么可加性——各因素的贡献加起来一定等于总变化量。业务方再也不用怀疑你做手脚了。三、工程落地从 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 调度每周一自动触发归因计算。核心流程是拉取上周和上上周的各维度汇总数据对比算出差值判断是否需要归因阈值GMV波动超过5%才触发运行 Shapley 归因算法生成 Markdown 格式的分析报告通过飞书 Webhook 推送到业务群第三步AI 增强。这才是画龙点睛的一笔。Shapley 值告诉你流量贡献了 42%但业务想知道的是流量为什么变了要不要投钱。我们接入了大模型让它基于归因结果自动生成业务建议。四、效果与思考这个项目上线后效果超出预期指标改造前改造后归因分析耗时6~8小时5分钟自动归因口径争议经常发生归零Shapley值公理化报告覆盖率仅周报每日自动推送决策响应平均滞后2天小时级响应但也有一些意外发现AI 生成的分析偶尔会过度联想比如把促销活动的影响错误归因到品类结构需要人工兜底审核业务方接受度是逐步提升的最开始运营总监觉得机器算的不可信跑了一个月对照实验后才完全接受Shapley 值的计算复杂度是 O(2^n)4个因子要算 2^416 种组合6个因子就是 64 种如果预测函数本身很重比如调一个模型性能会成问题五、总结GMV 归因这个项目让我深刻体会到数据分析的价值不在算出来而在用起来。传统手工拆维度不是做不了而是没法持续稳定地输出AI 自动化不只是提效更重要的是把分析能力标准化、可复制化了。给同行的建议如果你的日常工作中存在大量重复性的拆维度、写报告劳动不妨从 Shapley 值入手搭建一套自动化归因系统。方法论是成熟的需要打磨的是数据口径的规范和业务解释的适配。归因分析不是数学游戏是让数据说真话的能力。如果觉得有帮助点赞收藏走一波~ 下一篇我们来聊聊用户留存分析用 SQL 写一个完整的 Cohort 分析。
)
