从工程视角理解电商增长数据的本质

最近转进一个新的组，主要是做东南亚 TikTok Shop 营销/用户增长的，由于自己之前没有接触过增长工程师这个专业，所以借着团队内现有项目和 GPT 学了一轮，我了解到了数据在增长工程里几乎是最重要的东西，以下是我的学习增长数据心得，本文纯手写，请放心食用。

做工程和画页面是两件完全不同的事，最后产生的效果也不同。

很多工程师会 follow 产品的想法，在首页加几个模块、在某个交易节点加一个弹窗，但不知道为什么要这么做，最后往往效果不好，也无法验证收益。而一个工程化的解决思路，就像 Debugging 一样，是要弄清楚用户在哪一步流失了，卡住了，导致最后没有转化成成交额，并针对这一步进行优化，同时用实验验证优化是否达到预期。

工程师在增长业务里最重要的价值，是把业务想法变成可验证的因果链路。

拿电商举例子，电商看的核心指标是 GMV（商品交易总额），那么今天老板跟你说，GMV 低于行业平均水平，要提升 xx%。于是你开始忙活起来，拍一拍脑袋，觉得首页没有展示足够的大促信息，你加上了大促信息模块，结果呢？GMV 并没有明显上涨。就算上涨了，同一时间，程序员子涵、李明也在开发新功能，你也很难跟老板解释这个 GMV 的上涨就是你贡献的。

出现这个问题，本质上是因为 GMV 是一个高度抽象的指标，它的上升或下降是很多不同因素共同作用的总和。你不知道是因为商品质量、价格、还是系统性能等各种原因造成的。所以单纯基于这个指标，你做的改动和决策很可能没办法抓到根因。就像 debug 一样，一条很长的链路，你没有打 log，看结果猜根因，效率也很低。

更科学的做法，是把整个增长流程变成一个可验证的系统：用数据驱动决策、验证决策、衡量收益。

Growth engineering validation loop

Figure: Growth engineering validation loop. A business idea becomes a metric hypothesis, tracking design, experiment, decision, and impact measurement. generated by gpt-image-2.

电商增长数据工程化

下面拿电商增长工程（我负责的项目）举例子，跟大家讲一讲怎么做数据驱动增长工程。

节点拆分

电商交易最终指标是 GMV（商品交易总额），它代表了在该平台上产生交易的规模有多大，它是一个高度抽象的指标。其他的指标都是间接作用于该指标上的。

工程视角拆分

为了方便我们分析，我们可以把指标按流程进行拆解：

要提升 GMV，就要让尽可能多的用户以高客单价到达成交。我们可以把这个流程转化成一系列指标，追踪到达每个关键流程的用户数量，形成一个漏斗图：

Ecommerce conversion funnel

Figure: Ecommerce conversion funnel from entry traffic to order success and GMV. generated by gpt-image-2.

我们可以下游用户量除以上游用户量，形成该节点的转化率，UV（最开始的用户量）乘所有转化率就是 GMV：

\begin{aligned} \mathrm{GMV} &= \mathrm{UV} \\ &\quad \times \text{PDP 到达率} \\ &\quad \times \text{加购/立即买率} \\ &\quad \times \text{Checkout 发起率} \\ &\quad \times \text{支付成功率} \\ &\quad \times \text{人均订单数} \\ &\quad \times \mathrm{AOV} \end{aligned}

每一层都有不同含义：

阶段	指标	下降通常说明
入口曝光 -> 商品点击	CTR	模块位置、视觉、利益点、商品相关性不够
商品点击 -> PDP	到达率	跳转失败、性能差、商品不可用、埋点缺失
PDP -> 加购/立即买	商品转化意图	价格、库存、运费、券、评价、信任问题
Checkout -> Payment	交易摩擦	登录、地址、支付方式、费用突增、风控
Payment -> Order	系统链路	支付回调、库存锁定、订单服务、幂等问题

经营视角拆分

我们也可以按用户经营视角拆分，了解是哪类用户成交额在上涨/下滑，应该拉哪个杠杆。

\mathrm{GMV}_{\text{总}} = \sum_{s \in \text{用户类型}} \mathrm{GMV}_{s}

\begin{aligned} \mathrm{GMV}_{s} &= \text{该类活跃用户数} \\ &\quad \times \text{购买转化率} \\ &\quad \times \text{人均订单数} \\ &\quad \times \mathrm{AOV} \end{aligned}

按新老客分（也可以按地区、年龄等）：

\begin{aligned} \mathrm{GMV}_{\text{总}} &= \mathrm{GMV}_{\text{新客}} + \mathrm{GMV}_{\text{老客}} + \mathrm{GMV}_{\text{回流用户}} \\ &\quad + \mathrm{GMV}_{\text{高价值用户}} + \mathrm{GMV}_{\text{低频用户}} \end{aligned}

判断 GMV 变化到底是谁导致的：

Text

老用户活跃下降 -> 留存/召回问题
新客变多但不买 -> 新客承接问题
买家数没变但订单频次下降 -> 复购/活动问题
订单数没变但 AOV 下降 -> 货盘/价格/凑单问题

节点串联

拆分节点可以帮助我们看清哪个环节用户流失量最大，帮助我们排查根因。但只有根因还不够，我们还要确保修复最终能作用到我们的终极目标，也就是 GMV 上，这时候，我们需要从数据上串联整个链路。比方说，一个用户打开了首页，我们要知道他这次打开页面是否点进 PDP，是否下单，最后贡献给 GMV。

没有这个关联性保证，最容易得出错误的决策和结论。比如我们只关注用户从打开首页到商品详情的转化率，那我们最极端可以做一个重定向，用户一进首页，我们就自动跳转到某个商品详情。这样做转化率是 100%，但是最后肯定会严重伤害 GMV。

同样的，某些诱导用户下载 App 的手段，表面上下载量上升了，但是最后对用户下单、成为留存用户没有帮助，ROI 也是非常低。

所以，功能改动一定要以能否传导到 GMV 为准，而不是只看某个环节指标。

几种分析方法

漏斗分析

漏斗回答的是：“用户在哪一步掉了？”

Web and app growth path

Figure: Web and app growth path. A promo click can continue through web checkout or branch into app activation, order, and retention. generated by gpt-image-2.

漏斗分析主要是为了定位责任：

CTR 低：前端展示、活动利益点、商品排序、推荐策略。
PDP 到达低：跳转、性能、商品状态、deeplink、埋点。
PDP 加购低：价格、库存、优惠、评价、信任。
Checkout 支付低：登录、地址、支付、运费、风控。
App 打开后首单低：landing 不一致、权益落差、登录摩擦、商品丢失。

Cohort / 留存分析

Cohort 回答的是：“这批用户后面怎么样？” 你不能只看当天打开 App，因为很多点击只是误触或低质量流量。

Text

按进入 App 的日期分 cohort：
D0 打开 App
D0 登录
D0 首单
D1 回访
D7 回访
D30 回访
D7/D30 GMV

如果 A/B 方案让 App 打开提升 20%，但 D7 留存和首单没有提升，这不是好增长，是流量搬运。

归因分析

归因回答的是：“这个 GMV 应该算谁的贡献？”

常见模型：

模型	解释	风险
Last Click	最后一次点击拿贡献	容易高估临门一脚
First Click	第一次触点拿贡献	容易高估入口
Linear	多触点平分	简单但粗糙
Time Decay	越接近下单权重越高	仍是相关，不是因果

A/B Test

A/B 回答的是：“这个改动是不是导致了结果变化？”

一个合格实验必须有：

Primary Metric：只能有 1 个，决定胜负。例如 Web-assisted App GMV per UV、订单转化率、buyer rate。
Secondary Metrics：解释为什么赢或输。例如 CTR、PDP 到达率、加购率。
Guardrail Metrics：不能伤害的指标。例如 LCP、CLS、bounce、退款率、投诉、其他频道 GMV。
Stable Randomization：按用户/device 稳定分桶，不要每次刷新变组。
Enough Sample Size：样本不足不下结论。
Run Full Cycle：至少覆盖完整业务周期，电商通常不能只跑半天。
No Peeking：中途看到涨了就停，很容易出错。
SRM Check：实验组/对照组流量比例异常，结果直接不可信。

一个例子：

Text

实验：MWeb 点击购买时展示 App 承接页

Control：现有链路
Treatment：点击 Buy Now 后进入 App landing，引导打开 App 并保留商品/权益

Primary：
  7 天内 Web-assisted App paid GMV per exposed UV

Secondary：
  App open rate
  App landing success rate
  App login rate
  App first order rate

Guardrail：
  Web direct GMV
  total paid GMV
  bounce rate
  page performance
  complaint/refund

完整案例：MWeb 点击购买后用 App Landing 承接

前面讲了 GMV 拆解、漏斗、归因、留存和 A/B。如果这些概念分开看，还是有点散。下面用一个真实项目场景把它们串起来，看看数据驱动怎么做决策。

想法：Toko Mobile Web 用户点击购买后，是否应该通过一个 App Landing Page 引导用户进 App 完成购买？

1. 业务问题

通过观察数据，现在 Toko 有一个很典型的结构性问题：

Toko Web：DAU 高且稳定，但 GMV 很低
Toko App：GMV 高，但 DAU 在下降

这说明 Web 可能承载了大量商品浏览、SEO、搜索、活动入口流量，但没有很好地把这些流量转化成交易。尤其是 Mobile Web，用户在手机上浏览商品时，天然更适合被引导到 App 内完成交易，因为 App 里通常有更完整的登录态、支付体验、权益承接和复购能力。

但现在的问题是：Web 上虽然有引导进 App 的 banner，但它缺少明确的场景和用户动机。用户只是看到“打开 App”并不会觉得自己应该点。相比之下，更合理的场景是：当用户已经点击 Buy Now 或表现出购买意图时，再用一个 landing page 承接，告诉用户“进 App 可以保留当前商品、领取当前权益、继续完成购买”。

所以这个项目要验证：

高意图 MWeb 用户能否通过更好的 App 承接转化成 App 内首单、留存和长期 GMV

业务假设

这个需求背后的假设可以拆成三层：

假设 1：MWeb 上有一批高购买意图用户

证据：他们点击了 Buy Now / Add to Cart / 领取券 / 查看 Flash Sale 商品

假设 2：当前 Web -> App 引导效率低

原因：banner 泛化、动机弱、deeplink 承接不完整、商品/券/价格可能丢失

假设 3：如果在购买意图发生后，用 App Landing 承接

结果：App 打开率、登录率、首单率、后续留存和 GMV 会提升

指标链路

这个项目的完整指标链路应该是：

下面这张图把 MWeb eligible UV 到 D30 GMV / LTV 拆成 Web intent 和 App value 两段。

漏斗图：

MWeb-to-App measurement funnel

Figure: MWeb-to-App measurement funnel for the app landing experiment. Value is measured per eligible MWeb UV rather than total GMV alone. generated by gpt-image-2.

每一层回答的问题不同：

环节	指标	说明
MWeb Eligible UV	符合实验条件的 MWeb 用户	分母，不能用全站 UV 混算
CTA Click	点击购买/打开 App	是否有购买意图
Landing Page View	承接页到达	Web 侧跳转是否正常
Deep Link Success	Deeplink 成功率	技术链路是否通
App Landing Success	App 指定页面到达	是否保留商品、活动、券
Login / Activate	登录/激活率	身份承接是否完成
First Order	首单率	是否真正带来交易
D7/D30 Retention	留存	用户是否有长期价值
Repeat Order	复购	留存是否继续转成购买
D30 GMV / LTV	长期价值	最终是否值得做

实验设计

可以设计一个 A/B 实验：

Text

实验对象：
Mobile Web 上点击 Buy Now / Add to Cart / 高意图 CTA 的用户

Control：
维持现有链路，例如继续走 Web 购买链路或现有 App banner 逻辑

Treatment：
点击 Buy Now 后进入 App Landing Page
Landing Page 展示当前商品、价格、活动权益、App 打开按钮
点击后通过 deeplink 打开 App，并保留商品、券、活动和 attribution_id

实验结构：

App landing experiment split

Figure: A/B experiment split for the app landing page. Stable buckets keep control and treatment comparable while metrics and guardrails decide rollout. generated by gpt-image-2.

指标设计

Primary Metric 建议用：

\mathrm{Primary\ Metric} = \frac{\text{7 天内 Web-assisted App paid GMV}}{\text{eligible MWeb UV}}

为什么是这个？

因为它同时约束了三个东西：

约束	含义
Web-assisted	必须能归因到 Web 触点
App paid GMV	必须真的在 App 内成交
per eligible MWeb UV	不能只看总 GMV，要看单位流量价值

Secondary Metrics：

Text

Landing Page View Rate
Deep Link Click Rate
Deep Link Success Rate
App Landing Success Rate
Login Rate
First Order Rate
D7 Retention
D7 Repeat Order Rate

Guardrail Metrics：

Text

Web Direct GMV
Total（Web+App) Paid GMV
Bounce Rate
Page Performance
Refund / Cancel / Complaint
SEO Traffic

埋点和归因要求

这个实验能不能判断清楚，关键不在页面，而在归因链路。

必须有一个稳定的 web_attribution_id，从 MWeb 一直传到 App 订单：

Cross-channel attribution handoff

Figure: Cross-channel attribution handoff. The web touchpoint carries an attribution_id through landing, deeplink, app landing, and app order. generated by gpt-image-2.

关键事件包括：

Text

mweb_buy_now_click
app_landing_page_view
deeplink_click
deeplink_success
app_target_page_view
app_login_success
app_order_success

关键参数包括：

Text

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

如果没有 web_attribution_id 或类似归因字段，即使 App 订单涨了，我们也没法证明是 Web 改造带来的。

决策方式

实验结束后，不是看某一个指标涨了就上线，而是分情况判断。

结果	判断
App open 涨，First Order 不涨	承接弱，只是搬运流量
First Order 涨，Web Direct GMV 跌更多	可能蚕食 Web，不一定放量
App GMV 涨，D7/D30 留存差	低质量转化，长期价值不足
Web-assisted App GMV 涨，总 GMV 涨，护栏正常	可以放量
Deep Link Success 低	先修技术链路，不要急着优化 UI
App Landing Success 低	商品/券/页面承接丢失，需要修承接

最终比较理想的结果是：

Text

Treatment 组
Web-assisted App GMV / eligible UV 提升
Total Paid GMV 提升
Web Direct GMV 没有明显受伤
D7/D30 留存正常
退款、投诉、性能、跳出率无明显恶化