GMV 不是一个适合直接 debug 的指标。它适合作为业务结果，但如果问题从“GMV 低”开始，方案直接跳到“加一个活动模块”，中间全靠猜。

增长工程真正有价值的地方，是把业务想法拆成一条可验证的因果链：假设、埋点、实验、判断、放量和收益衡量。没有这条链，功能上线了，GMV 动了，也没人能说清楚是不是这个功能带来的。

图：增长工程的验证闭环。业务想法要先变成指标假设，再经过埋点、实验、判断和收益衡量。generated by gpt-image-2.

GMV 是结果，不是根因

电商里最常看的指标通常是 GMV。它代表平台成交规模，这没问题。

问题是，它不告诉你哪里坏了。

GMV 下降可能是流量少了，用户看到的商品不相关，商品详情页慢，库存没了，checkout 摩擦太大，支付失败，订单服务回调异常，也可能只是客单价下降。

这些是完全不同的问题，责任方和修法都不一样。

这和排查线上问题很像。一条很长的调用链失败了，你只看最终错误，不看中间日志，基本就是拍脑袋。增长也一样。顶层指标动了，但因果路径不可见。

先把交易路径拆成漏斗

第一步，是把 GMV 按用户流程拆开。

要提升 GMV，本质上要让足够多的用户到达成功下单，同时让订单有足够的价值。这个过程可以拆成一个从流量、商品曝光、购买意图、checkout、支付到订单成功的漏斗。

图：电商转化漏斗，从入口流量到订单成功和 GMV。generated by gpt-image-2.

一个简化拆法是：

1
2
3
4
5
6
7
8

GMV
= UV
× PDP 到达率
× 加购 / 立即买率
× Checkout 发起率
× 支付成功率
× 人均订单数
× AOV

每一层对应的问题不一样：

这比讨论“增长”有用得多。问题终于有了位置。

如果 PDP 到达率下降，先别急着重写活动模块。跳转、性能、商品状态、埋点都应该先查。如果支付成功了但订单创建掉了，增长同学也别继续改文案，应该看交易后端链路。

再按用户类型拆 GMV

漏斗视角回答的是用户掉在哪里。经营视角回答的是哪类用户变了。

同一个 GMV，还可以按新客、老客、回流用户、高价值用户、低频用户、地区、渠道来拆。

1
2
3
4
5

某类用户 GMV
= 该类活跃用户数
× 购买转化率
× 人均订单数
× AOV

这个拆分会直接影响方案：

数据结构才是关键。如果所有讨论都从一个巨大的 GMV 数字开始，每个方案都听起来像那么回事。把 GMV 按流程和人群拆开，很多方案会立刻露出问题。

不要孤立优化局部指标

漏斗本身也会骗人，前提是各节点没有串起来。

假设你只优化首页到 PDP 的转化率。最极端的方案是用户一进首页就自动跳商品详情页。PDP 到达率会变成 100%，业务会被搞坏。

App 下载引导也一样。你可以用更强的弹窗把 App open 做上去。如果这些用户不下单，不在 D7 回访，也没有长期价值，这只是搬运流量。

有用的增长指标必须能向下游传导。一个功能应该改善局部环节，并把价值传到最终业务结果。

图：Web 和 App 的增长链路。活动点击可以继续走 Web checkout，也可以分叉到 App 激活、下单和留存。generated by gpt-image-2.

我更愿意把漏斗当成责任图来看：

很多时候四个都要有。漏斗找漏点，留存判断流量质量，归因避免乱领功，A/B 把因果从时间波动里分出来。

一个具体场景：Mobile Web 购买意图到 App 下单

电商里经常会遇到这种结构。

Mobile Web 有稳定流量，因为搜索、社交分享、SEO 页面、活动链接都会落到 Web。App 的人均 GMV 更高，登录态、支付体验和复购承接也更好，但 App DAU 有压力。

粗糙方案是“把 App banner 做大一点”。

更好的问题应该更窄：当 Mobile Web 用户已经表现出购买意图时，要不要用一个 App Landing Page 承接，让他进 App 完成购买？

这个问题可以拆成三个假设：

1. Mobile Web 上存在一批高意图用户，比如点击了 Buy Now、Add to Cart、领券或活动商品。
2. 当前 Web 到 App 的承接效率低，原因可能是 banner 太泛、deeplink 丢上下文、商品和券没有保住。
3. 如果在购买意图发生后承接，并保留商品、权益和归因上下文，App 首单、留存和单位 eligible 用户 GMV 会提升。

把承接链路拆成两个漏斗

这条链路不能停在 App open。

App open 很便宜。App order 难得多。D7、D30 留存更难。长期价值才是真正有用的答案。

图：MWeb 到 App 的实验指标漏斗。价值要按 eligible MWeb UV 衡量，不能只看总 GMV。generated by gpt-image-2.

链路至少要包括：

分母很重要。“App 总 GMV 提升”可能是别的 App 活动带来的。“Web-assisted app paid GMV per eligible Mobile Web UV”难造假得多。

实验要允许自己失败

一个有用的实验，必须有机会说“不值得做”。

App Landing 这个例子可以这样设计：

图：App Landing Page 的 A/B 实验分桶。稳定分桶保证 Control 和 Treatment 可比，最终由指标和护栏决定是否放量。generated by gpt-image-2.

稳定分桶不是流程形式。如果用户刷新就换组，结果就是垃圾。如果 Treatment 把 Web direct GMV 抢走了，但 total GMV 没涨，结果也是垃圾。

护栏的作用，就是防止局部胜利变成业务损失。

归因是数据契约

这个实验能不能成立，关键在归因。

如果 App 订单无法关联回 Web 触点，这个实验就证明不了什么。App 订单可能涨了，但你不知道是不是 App Landing Page 带来的。

承接链路里必须有一个稳定的 web_attribution_id 或类似标识，从 Mobile Web 一直传到 App 订单。

图：跨端归因传递。Web 触点把 attribution_id 带过 landing、deeplink、App landing 和 App order。generated by gpt-image-2.

事件链至少应该覆盖：

1
2
3
4
5
6
7

mweb_buy_now_click
app_landing_page_view
deeplink_click
deeplink_success
app_target_page_view
app_login_success
app_order_success

事件参数要足够把链路 join 起来：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

web_attribution_id
user_id
device_id
session_id
product_id
sku_id
campaign_id
entrance
source_page
target_page
btm_chain
experiment_id
variant_id
app_installed_flag
login_state

不同系统的字段名会变，但原则不能变。归因 key 要跨过 Web 到 App 的边界，实验分组也要跟着一起传。

用决策矩阵收口

实验结束后，不要挑一个最绿的指标给自己庆功。

用矩阵判断：

理想结果其实很朴素：

1
2
3
4
5
6

Treatment group
Web-assisted app GMV per eligible UV increases
Total paid GMV increases
Web direct GMV is not materially damaged
D7 / D30 retention is healthy
Refund, complaint, performance, and bounce guardrails stay clean

这里越朴素越好。增长系统要产出决策，不是产出感觉。

我会记住的模型

增长工程不是“把指标做上去”。这个说法太虚，没法指导工程。

更好的模型接近线上排障：

1. 把顶层指标拆成流程结构和人群结构。
2. 把局部动作连到下游价值。
3. 让归因贯穿整条链路。
4. 用能否定方案的实验来验证。
5. 用护栏防止局部胜利掩盖业务损失。

如果一个功能没法表达成因果链，第一件事不是开工。第一件事是把数据模型补到这个问题可以被回答。