# 数据分析 · 第 09 篇｜行业实战：电商与 SaaS

> 系列：project / 数据分析（共 12 篇）｜AI生成｜2026-10-27｜codebuddy

**这一篇讲什么**

电商和 SaaS 是数据分析师最常进入的两个行业，也是两种几乎相反的业务：前者卖货，一次交易结束，关系才刚开始；后者卖订阅，签约只是关系的开始。这一篇不再讲通用方法，而是把第 03—06 篇的漏斗、留存、归因、实验放进这两类公司的真实问题里。你会看到一张人货场的分析地图、一个能拆到四个因子的 GMV 公式、一套 SaaS 的 MRR 桥，以及两个完整案例：北辰优选 3 月 GMV 下降 8%，某订阅产品月流失率从 3% 升到 4.5%。读完之后，拿到一个新行业的数据，你应该先画指标树，再决定看哪一层，而不是先跑一张大宽表。

## 一、电商分析地图：人、货、场

人货场是电商分析最常用的三个字，但它们不是三张检查清单，而是三组互相约束的问题。人回答「谁在买、买了几次、还值不值得继续投」；货回答「卖什么、卖什么价、有没有货」；场回答「从哪里来、在哪个页面走掉、大促怎么排」。任何一个维度的变化，都会通过另外两个维度表现出来，所以分析的第一步不是扎进某个维度，而是先确认总量变化是真的。

先看一个反例。运营说「3 月 GMV 跌了 8%」，直接去拉渠道报表，发现信息流投放减少了 15%，于是结论是「预算砍多了」。这个结论可能对，也可能完全错：如果 3 月有 2 天数据延迟、退款口径从下单金额改成支付金额、或者 2 月有春节大促的高基数，8% 里可能有一半不是业务问题。第 02 篇讲过口径，这里再强调一次顺序：**先验数，再看结构，最后解释动作**。

验数只做三件事：核对统计周期是否等长（2 月 28 天、3 月 31 天）；核对口径是否变更（GMV 是否含退款、是否含运费）；核对数据是否完整（最后几天的分区是否跑完）。三件事都过了，8% 才是一个值得拆的业务问题。

表 1 是一张可以直接贴到分析文档里的地图。它的用法不是逐格填满，而是先看哪一格的变动能解释总量的大部分。

| 维度 | 核心问题 | 关键指标 | 常用方法 | 典型动作 |
| --- | --- | --- | --- | --- |
| 人 | 谁在买，新客还是老客 | 新客占比、复购率、30 日留存、RFM 分层 | cohort、RFM、留存曲线 | 新客礼包、老客召回、会员分层 |
| 人 | 客户值不值 | 客单价、LTV、获客成本 | 分层对比、LTV/CAC | 提额、交叉销售、止损 |
| 货 | 卖什么 | 品类 GMV 占比、毛利占比、增速 | 结构分析、贡献度 | 调整货盘、主推换品 |
| 货 | 卖得动吗 | 动销率、售罄率、库存周转天数 | 分布分析、ABC 分类 | 清库存、补货、下架 |
| 货 | 卖什么价 | 价格带分布、折扣率、连带率 | 价格带迁移、购物篮 | 调价、满减、搭配套餐 |
| 场 | 从哪里来 | 渠道 UV、CAC、ROI、渠道留存 | 分渠道对比、归因 | 调预算、换素材 |
| 场 | 在哪一步走 | 曝光→访问→加购→下单→支付转化率 | 漏斗、分页面下钻 | 改详情页、改结算流程 |
| 场 | 大促有没有用 | 爆发系数、预热转化、透支率 | 同期对比、DID | 调整节奏、控节奏 |

这张表有一个隐含的顺序：人和货决定「能不能卖」，场决定「卖得快不快」。所以当总量下跌时，先拆人和货，通常能解释七成以上的变动；场的问题更多影响效率，而不是盘子大小。

北辰优选是一家虚构的综合电商，2026 年 3 月有约 98 万活跃用户、3.71 万笔支付订单、1280 万元 GMV。下面所有的数字都是围绕这家虚构公司构造的教学示例，不对应任何真实企业。

## 二、GMV 拆解：一个公式撑起一套诊断

GMV 的拆法有很多版本，最常见的是三因子：GMV = UV × 转化率 × 客单价。这个式子没有错，但它把「复购」藏进了客单价里，一旦老客下单频次变化，客单价看起来就会异常。更稳的写法是四因子：

**GMV = UV × 支付转化率 × 人均下单次数 × 客单价**

四个因子必须同时写清口径，否则乘法不成立：

- UV：统计期内访问过至少一个页面的去重用户数，来自 events 表，不是曝光数。
- 支付转化率 = 支付用户数 ÷ UV。分子是「人」不是「单」，一个用户下两单只算一次。
- 人均下单次数 = 支付订单数 ÷ 支付用户数。它衡量的是频次，不是复购率。
- 客单价 = GMV ÷ 支付订单数。GMV 只算 paid，退款单不计入。

这四个因子乘起来严格等于 GMV，是一个恒等式。恒等式的好处是可以用对数做贡献拆解：两边取自然对数，加法关系就出来了，每个因子的变动可以换算成对总变动的百分点贡献。坏处是它只是算术关系，不是因果关系——「客单价下降导致 GMV 下降」这句话，和「我们降价了所以客单价下降」是两件事，后者要另找证据。

表 2 把每个因子的诊断问题列了出来。

| 因子 | 计算口径 | 下降时先问什么 | 常用方法 | 常见伪原因 |
| --- | --- | --- | --- | --- |
| UV | 去重访问用户 | 是投放少了，还是自然流量少了 | 分渠道 UV、同期对比 | 把曝光当 UV |
| 支付转化率 | 支付用户 ÷ UV | 哪一步漏斗掉了 | 漏斗、分页面、分渠道 | 用订单数当分子 |
| 人均下单次数 | 支付订单 ÷ 支付用户 | 老客买得少了，还是新客占比高了 | 分新老客、cohort | 把退款单算进订单 |
| 客单价 | GMV ÷ 支付订单 | 是价格变了，还是结构变了 | 价格带、品类结构、折扣率 | 忽略退款与运费 |

北辰优选 2 月和 3 月的四因子对比如表 3。

| 指标 | 2 月 | 3 月 | 变化 | 对数贡献 |
| --- | --- | --- | --- | --- |
| GMV（万元） | 1391 | 1280 | -8.0% | -0.083 |
| UV（万人） | 96.0 | 97.9 | +2.0% | +0.020 |
| 支付转化率 | 3.55% | 3.24% | -8.7% | -0.091 |
| 人均下单次数 | 1.18 | 1.17 | -0.8% | -0.009 |
| 客单价（元） | 346 | 345 | -0.3% | -0.003 |

四个因子的对数贡献相加约 -0.083，与总量一致。换算成占比：转化率贡献约 110% 的跌幅，UV 的正增长抵消约 24%，频次和客单价分别贡献约 11% 和 4%。这个结果直接改变了诊断方向——不是「流量不够」，而是「来的人更多了，但转化更差」。

取数可以用一段 SQL 完成。下面的写法在 PostgreSQL 和 DuckDB 上都能跑，MySQL 只需要把日期函数换成对应的写法。

```sql
WITH uv AS (
    SELECT COUNT(DISTINCT user_id) AS uv
    FROM events
    WHERE event_time >= '2026-03-01' AND event_time < '2026-04-01'
),
paid AS (
    SELECT COUNT(DISTINCT user_id) AS payers,
           COUNT(*)               AS orders,
           SUM(amount)            AS gmv
    FROM orders
    WHERE status = 'paid'
      AND order_date >= '2026-03-01' AND order_date < '2026-04-01'
)
SELECT uv.uv,
       paid.payers,
       paid.orders,
       paid.gmv,
       paid.payers * 1.0 / uv.uv       AS pay_cvr,
       paid.orders * 1.0 / paid.payers AS orders_per_payer,
       paid.gmv * 1.0 / paid.orders     AS aov
FROM uv, paid;
```

查询结果应该和表 3 对得上：UV 97.9 万、支付用户 3.17 万、订单 3.71 万、客单价 345 元。如果对不上，先查 events 表里是否混进了测试账号，再查 orders 表里是否有金额为负的退款记录被算进了 paid。

贡献度用 Python 算更快，也更容易复用到别的指标上。

```python
import math

def log_contribution(cur, base):
    """输入两期的四因子字典，返回各因子的对数贡献与占比。"""
    keys = ["uv", "cvr", "freq", "aov"]
    total = math.log(cur["gmv"] / base["gmv"])
    rows = []
    for k in keys:
        c = math.log(cur[k] / base[k])
        rows.append((k, round(c, 4), round(c / total, 3)))
    return round(total, 4), rows

base = {"gmv": 1391, "uv": 96.0, "cvr": 0.0355, "freq": 1.18, "aov": 346}
cur  = {"gmv": 1280, "uv": 97.9, "cvr": 0.0324, "freq": 1.17, "aov": 345}

total, rows = log_contribution(cur, base)
print(f"总变动 {total:+.3f}")
for k, c, share in rows:
    print(f"{k:5s} 对数贡献 {c:+.3f}  占总变动 {share:+.1%}")
```

这段代码的输出会告诉你：cvr 和 aov 各占约一半，freq 约占三成，uv 是负贡献（即正增长）。注意占比的分母是总变动，当总变动接近 0 时占比会失真，这时候只看绝对贡献，不要看百分比。

## 三、漏斗与留存：把「来了没买」拆开

GMV 告诉你结果，漏斗告诉你过程。电商的标准漏斗是曝光→访问→加购→下单→支付，五个步骤对应四种完全不同的动作：曝光是投放和推荐，访问是素材和入口，加购是商品页和价格，下单是购物车和优惠，支付是结算流程和风控。任何一步的转化率下降，都不该用「用户不买账」这种话糊过去。

表 4 是北辰优选 3 月的一个漏斗示例，数字为示意。

| 步骤 | 人数（万） | 单步转化率 | 相对曝光累计转化 |
| --- | --- | --- | --- |
| 曝光 | 1000 | — | 100% |
| 访问 | 120 | 12.0% | 12.0% |
| 加购 | 24 | 20.0% | 2.40% |
| 下单 | 9.6 | 40.0% | 0.96% |
| 支付 | 7.68 | 80.0% | 0.77% |

这张表最容易犯的错，是拿「单步转化率」和「累计转化率」混着说。加购率 20% 是「访问的人里有 20% 加购」，不是「曝光的人里有 20% 加购」。汇报时把分母写在指标名里，比如「访问-加购率」，比任何解释都有效。

漏斗还有两个技术细节。第一，漏斗要按同一批人算，不能每一步用不同的时间窗口；一个人 3 月 1 日访问、3 月 5 日支付，应该算进同一个 cohort。第二，漏斗要区分新老客，新客的支付转化率通常只有老客的三分之一到二分之一，新客占比上升会把整体转化率拉低，但这不是「转化能力变差」。

留存看的是另一件事：来的这批人，后面还会不会回来。表 5 是一个按注册月分组的 30 日留存与复购示例。

| 注册月 | 新增用户（万） | 30 日留存 | 60 日留存 | 90 日留存 | 90 日内复购率 |
| --- | --- | --- | --- | --- | --- |
| 2025-11 | 9.8 | 26% | 19% | 15% | 21% |
| 2025-12 | 11.2 | 25% | 18% | 14% | 20% |
| 2026-01 | 12.5 | 24% | 17% | 13% | 19% |
| 2026-02 | 10.1 | 23% | 16% | — | 18% |
| 2026-03 | 13.4 | 19% | — | — | — |

3 月的新增用户比 1 月多了 7%，30 日留存却从 24% 掉到 19%。这不是留存能力突然变差，而是 3 月新增里有更大比例来自信息流的低价拉新。**留存要和新客结构一起看**，否则会把「买来的低质量用户」误判成「产品变差了」。

复购率的定义要先说清：是「90 天内下单两次及以上的用户 ÷ 同期支付用户」，还是「第二次购买距首次购买的天数中位数」？前者是一个比例，后者是一个时间，回答的问题不同。电商团队常说的「复购率」默认是前者，但做召回策略时更该看后者——中位回购周期是 45 天还是 90 天，决定了召回券该在第几天发。

SQL 里做 cohort 留存，核心是「首次行为日期」加「后续行为日期」的条件聚合。

```sql
WITH first_visit AS (
    SELECT user_id, MIN(DATE(event_time)) AS first_day
    FROM events
    GROUP BY user_id
),
active AS (
    SELECT DISTINCT user_id, DATE(event_time) AS day
    FROM events
),
cohort AS (
    SELECT f.user_id,
           DATE_TRUNC('month', f.first_day) AS cohort_month,
           DATE_DIFF('day', f.first_day, a.day) AS diff_day
    FROM first_visit f
    JOIN active a ON a.user_id = f.user_id
)
SELECT cohort_month,
       COUNT(DISTINCT user_id) AS cohort_size,
       COUNT(DISTINCT CASE WHEN diff_day BETWEEN 29 AND 31 THEN user_id END)
         * 1.0 / COUNT(DISTINCT user_id) AS retention_d30
FROM cohort
GROUP BY cohort_month
ORDER BY cohort_month;
```

DuckDB 和 BigQuery 支持 `DATE_DIFF('day', ...)`，PostgreSQL 要改成 `a.day - f.first_day`，MySQL 用 `DATEDIFF`。方言不同，逻辑一样：先锁定每个人的第一次，再数他在第 30 天前后有没有回来。

## 四、货与场：商品、价格、渠道

商品分析的第一层是结构，不是单品。品类 GMV 占比、毛利占比、增速三个数放在一起看，才能判断「这个品类该不该继续投」。一个品类 GMV 占比四成、毛利占比两成半、增速 5%，说明它是流量担当但不是利润担当；反过来，GMV 占比一成、毛利占比两成半、增速 40% 的品类，才值得加资源。

表 6 是商品侧的常用指标。

| 指标 | 定义 | 看什么 | 示例值 |
| --- | --- | --- | --- |
| 动销率 | 有销售的 SKU ÷ 在架 SKU | 货盘是否过宽、滞销是否严重 | 62% |
| 售罄率 | 已售数量 ÷ 可售数量 | 补货是否及时 | 78% |
| 库存周转天数 | 平均库存 ÷ 日均销售成本 | 资金占用 | 46 天 |
| 价格带占比 | 各价格带 GMV ÷ 总 GMV | 价格结构是否迁移 | 100—200 元占 38% |
| 连带率 | 销售件数 ÷ 订单数 | 搭配与推荐是否有效 | 1.7 件/单 |
| 折扣率 | 1 - 实付金额 ÷ 原价金额 | 促销是否过度 | 24% |
| 新品贡献 | 上架 90 天内新品 GMV ÷ 总 GMV | 货盘更新能力 | 15% |

北辰优选 3 月的折扣率从 18% 升到 24%，客单价同时下降 4%。这两个数放在一起，初步判断是「用折扣换销量，但没换到」。进一步看价格带：100 元以下商品的 GMV 占比从 22% 升到 31%，300 元以上从 28% 降到 21%。这不是「用户变穷了」，而是 3 月的满减门槛从 299 降到 199，把原本买 300 元的人拆成了两单 190 元。折扣率上升、客单价下降、订单数上升，三者是同一件事的三个侧面。

渠道分析的核心是「每个渠道买来的人，值多少钱」。CAC 是获客成本，ROI 是短期回收，LTV/CAC 是长期是否划算。三个指标必须一起看：一个渠道 ROI 很高但 LTV/CAC 只有 0.8，说明它买来的人只买一次；另一个渠道 ROI 一般但 LTV/CAC 有 3.2，说明它值得加预算。

表 7 是渠道示例。

| 渠道 | 新增用户（万） | CAC（元） | 首单 ROI | 90 日 LTV（元） | LTV/CAC | 30 日留存 |
| --- | --- | --- | --- | --- | --- | --- |
| 信息流 | 5.8 | 120 | 1.8 | 210 | 1.75 | 17% |
| 搜索 | 2.1 | 80 | 3.2 | 340 | 4.25 | 26% |
| 老客推荐 | 1.4 | 35 | 6.5 | 520 | 14.9 | 38% |
| 内容种草 | 3.2 | 95 | 1.2 | 150 | 1.58 | 14% |

这张表里最危险的不是 ROI 最低的内容种草，而是信息流：它贡献了四成六的新增，CAC 是搜索的 1.5 倍，LTV/CAC 却只有 1.75。停掉它会立刻少一半新客，不停它又会持续稀释整体留存。正确的动作不是二选一，而是分层：把信息流里 30 日留存高于 25% 的人群包单独放大，低于 12% 的素材和定向停掉。

归因窗口会直接改变这张表的排序。同一个渠道，按 1 日归因、7 日归因、30 日归因统计，归因到的支付订单可能分别是 5.2 万、6.8 万、8.1 万。窗口越长，越有利于「先种草后搜索」的渠道，也越容易把自然流量算到付费渠道头上。所以看渠道报表的第一句话应该是「这是几日归因窗口的数据」，而不是「信息流 ROI 最低」。

## 五、案例：北辰优选 3 月 GMV 下降 8%

分析从表 3 开始：UV 涨 2%，转化率、客单价、频次三项齐跌。三项齐跌通常不是单点故障，而是「新客结构变化 + 促销策略变化」的叠加。按人货场列出三个假设，每个假设都要有可验证的证据，而不是一句「可能」。表 8 是三个假设和对应的验证动作。

| 假设 | 支持证据 | 验证动作 | 若成立的处理 |
| --- | --- | --- | --- |
| 人：信息流低价拉新占比上升 | 信息流新增占比 38%→46%，该渠道 30 日留存 17%，搜索为 26% | 按渠道×新老客拆四因子，看跌幅是否集中在新客信息流 | 收紧低留存定向，预算移到搜索与推荐 |
| 货：满减门槛下调导致拆单 | 折扣率 18%→24%，100 元以下 GMV 占比 22%→31%，订单数 +6% | 对比参加与未参加满减用户的客单价，做同人群前后对比 | 恢复门槛，或改成阶梯满减 |
| 场：详情页改版压低加购 | 3 月 8 日改版后访问-加购率 20.5%→18.9%，旧版页面未降 | 按页面版本分组做前后对比，5% 流量回滚做 A/B | 回滚，或保留旧版入口 |

三个假设的贡献可以相加：转化率约 -8.7%，客单价约 -0.3%，频次约 -0.8%，UV +2.0%，合计约 -8.3%，与 -8.0% 基本吻合。这里的「相加」是对数贡献的相加，不是百分比的相加，这一点在第 04 篇已经讲过，不再展开。

案例的关键不是找到三个原因，而是给每个原因配一个「如果成立，下周就能看到的数」。比如假设一成立，下周信息流的新客 30 日留存应该回升到 20% 以上；假设二成立，恢复门槛后客单价应该回到 346 元以上；假设三成立，回滚后加购率应该在三天内回到 20% 附近。没有验证动作的归因，只是把猜测写得更长。

还有一个容易被忽略的第四层：三个原因之间可能互相放大。信息流买来的新客本来就更依赖折扣，满减门槛下调让他们买得更便宜；详情页改版又让这批人对商品的理解更浅，加购率进一步下降。这种情况下，单独修任何一个都只能收回一部分。诊断报告里应该写清「三个动作的预期回收分别是多少」，而不是承诺「修完就回到 1391 万」。

## 六、SaaS 指标框架：MRR 是主干

SaaS 的分析起点不是收入，而是 MRR（月度经常性收入）。它只算订阅的经常性部分，不含一次性实施费、硬件和咨询。MRR 的变化可以拆成一座桥：

**期末 MRR = 期初 MRR + New + Expansion - Contraction - Churn**

这四个动词对应四种完全不同的业务动作：New 是销售拿新客，Expansion 是客户加席位或升级套餐，Contraction 是降级或减席位，Churn 是彻底流失。只看 MRR 净增，会把「新签很猛但老客在跑」误读成「增长健康」。表 9 是一个 MRR 桥示例，单位为万元。

| 项目 | 金额（万元） | 说明 |
| --- | --- | --- |
| 期初 MRR | 480 | 上月经常性收入 |
| New | +42 | 新签客户首月 |
| Expansion | +18 | 升级、加席位、加模块 |
| Contraction | -9 | 降级、减席位 |
| Churn | -21 | 完全流失 |
| 期末 MRR | 510 | 净增 30，净增率 6.25% |

表 9 的桥本身不复杂，复杂的是每一段的定义。New 要不要算「签了合同但还没上线」的客户？Expansion 要不要算「用量超出套餐后补缴」？Contraction 要不要把「折扣到期后恢复原价」算进去？行业里常见的做法是只用「已生效的订阅」计算，把实施费和超量费单列，这样桥的每一段都能和合同系统对上。

表 10 是 SaaS 的核心指标表。

| 指标 | 公式 | 健康信号 | 常见误用 |
| --- | --- | --- | --- |
| MRR / ARR | 月度/年度经常性收入 | 稳定增长、结构分散 | 把一次性收入算进 MRR |
| NRR | (期初 + Expansion - Contraction - Churn) ÷ 期初 | 100% 以上 | 用客户数代替收入 |
| GRR | (期初 - Contraction - Churn) ÷ 期初 | 90% 以上 | 和 NRR 混用 |
| Logo Churn | 流失客户数 ÷ 期初客户数 | 分套餐看 | 只看总体 |
| Revenue Churn | 流失 MRR ÷ 期初 MRR | 与大客户集中度一起看 | 忽略降级 |
| CAC Payback | CAC ÷ (ARPA × 毛利率) | 12 个月以内 | 用收入不用毛利 |
| 激活率 | 完成关键行为的客户 ÷ 新签客户 | 与留存强相关 | 关键行为定义过宽 |
| 功能采用率 | 使用某功能的客户 ÷ 活跃客户 | 分模块看 | 把登录当使用 |

NRR 是 SaaS 最重要的单一指标，因为它把「留存 + 增购」压缩成一个数。上表的例子：NRR = (480 + 18 - 9 - 21) ÷ 480 = 97.5%。GRR 则是 (480 - 9 - 21) ÷ 480 = 93.75%，说明降级和流失吃掉了 6.25% 的收入。两个数一起看：NRR 低于 100%、GRR 高于 90%，问题主要在「增购不足」，而不是「客户跑光」。

CAC Payback 的坑在分母。用 ARPA（每客户平均收入）算出来的回收期，会比用「ARPA × 毛利率」算出来的短三分之一左右。SaaS 的毛利率通常在七成到八成，用收入算等于把渠道成本当成可以全额回收，实际回收的是毛利。这会直接导致过度投放。

激活率的坑在定义。如果激活被定义成「注册后登录一次」，几乎所有人都能激活，这个指标就没有区分度。好的激活定义要满足三个条件：发生在生命周期早期（首周或首月）、是一个有业务含义的动作（创建报表、导入数据、邀请同事）、和后续留存有可验证的相关性。北辰优选的 SaaS 版本把激活定义为「7 天内创建第一个报表并分享」，这个定义是拿数据验证过的：激活客户的 90 日留存是 78%，未激活客户是 31%。

## 七、案例：月流失率从 3% 升到 4.5%

某虚构订阅产品有 1200 个付费客户，月流失客户数从 36 个升到 54 个，Logo Churn 从 3.0% 升到 4.5%。总体流失率上升五成，但总体数字不能直接指导动作，必须先分层。

分层维度选四个：套餐（低/中/高）、任期（不足 90 天、90—365 天、超过 365 天）、功能使用（是否用过报表）、支持工单（0 单、1—2 单、3 单以上）。表 11 是分层后的流失率对比。

| 分层 | 客户数 | 本期流失率 | 上期流失率 | 差异 | 解读 |
| --- | --- | --- | --- | --- | --- |
| 低套餐 | 640 | 6.4% | 3.9% | +2.5pp | 价格敏感，价值感不足 |
| 中套餐 | 420 | 3.1% | 2.8% | +0.3pp | 基本稳定 |
| 高套餐 | 140 | 1.4% | 1.3% | +0.1pp | 稳定 |
| 任期不足 90 天 | 210 | 8.2% | 4.6% | +3.6pp | 激活环节出问题 |
| 未用报表功能 | 380 | 7.1% | 4.2% | +2.9pp | 核心价值未触达 |
| 工单 3 单以上 | 150 | 9.4% | 5.1% | +4.3pp | 支持体验恶化 |

结论很快就清楚了：流失上升集中在低套餐、新任期、未使用报表、工单多的客户。这四个特征高度重叠——低套餐的新客更容易在引导阶段卡住，卡住就提工单，工单多了还没解决就走。所以这不是「全量流失」，而是一段流程的泄漏。

再往下拆一层，用「任期 × 是否激活」交叉，会发现 90 天内且未激活的客户流失率 11.3%，而 90 天内已激活的只有 2.9%。这个对比比任何总体数字都有说服力，因为它给出了一个可运营的行为：把新客在 7 天内推到「创建第一个报表」这一步。表 12 是按激活状态交叉后的结果。

| 分组 | 客户数 | 流失数 | 流失率 |
| --- | --- | --- | --- |
| 90 天内且已激活 | 118 | 3 | 2.5% |
| 90 天内且未激活 | 92 | 10 | 10.9% |
| 90 天以上且活跃 | 760 | 20 | 2.6% |
| 90 天以上且沉默 | 230 | 21 | 9.1% |

对应的 SQL 如下，按套餐和任期分组算流失率，注意分母是期初客户数，不是期末。

```sql
WITH base AS (
    SELECT customer_id,
           plan,
           signup_date,
           churn_date,
           DATE '2026-03-01' AS period_start,
           DATE '2026-04-01' AS period_end
    FROM subscriptions
),
cohort AS (
    SELECT CASE WHEN plan = 'low'  THEN '低套餐'
                WHEN plan = 'mid'  THEN '中套餐'
                ELSE '高套餐' END AS plan_group,
           CASE WHEN period_start - signup_date < 90  THEN '90天内'
                WHEN period_start - signup_date < 365 THEN '90-365天'
                ELSE '365天以上' END AS tenure_group,
           CASE WHEN churn_date >= period_start
                 AND churn_date <  period_end THEN 1 ELSE 0 END AS is_churn
    FROM base
    WHERE signup_date < period_start
)
SELECT plan_group,
       tenure_group,
       COUNT(*) AS customers,
       SUM(is_churn) AS churned,
       ROUND(AVG(is_churn) * 100, 1) AS churn_rate_pct
FROM cohort
GROUP BY plan_group, tenure_group
ORDER BY churn_rate_pct DESC;
```

这段 SQL 有两个容易错的地方。第一，`WHERE signup_date < period_start` 必须加，否则把观察期内新签的客户算进分母，流失率会被稀释。第二，churn_date 要允许为空，空值在 CASE 里自然落到 0，不要用 `IS NULL` 去过滤，那会把仍在订阅的客户全部排除。

诊断完之后，动作要按层给：低套餐新客做 7 天激活任务，未激活的第 3 天人工触达；工单 3 单以上的客户进入客户成功名单；高套餐不动，避免过度打扰。不要一上来就全量打折，那会把本来不会流失的客户也变成折扣客户，直接压低 NRR。

还需要排除一个替代解释：4.5% 会不会是季节性的？如果去年同期的流失率也在 4.3%—4.6% 之间，那这次上升可能只是季节性波动。验证方法是拉过去 24 个月的月度流失率，看 3 月是不是每年都高。如果是，就不要把它当成突发事件；如果不是，再找本期特有的变化，比如 2 月的一次涨价、一次产品改版、一次客服团队缩编。

## 八、两个行业的差异：交易与订阅

电商和 SaaS 的差别，表面是卖货和卖软件，底层是「关系长度」的差别。电商的一次交易在支付那一刻结束，之后的复购是新一轮获客；SaaS 的一次签约只是开始，之后的每个月都是一次续约。这个差别会改变指标、方法和组织。

表 13 把主要差异列在一起。

| 维度 | 电商 | SaaS |
| --- | --- | --- |
| 收入形态 | 一次性交易，可退款 | 订阅，按月或按年确认 |
| 核心指标 | GMV、转化率、客单价、复购 | MRR、NRR、Churn、CAC Payback |
| 供给约束 | 库存、履约、退货 | 席位、算力、实施人力 |
| 主要分析结构 | 漏斗 + 分层 | 队列 + 留存 |
| 时间视角 | 大促脉冲、季节性 | 月度续费、年度合同 |
| 归因重点 | 渠道与内容 | 销售、引导、客户成功 |
| 成本结构 | 采购成本、履约、投放 | 研发、云资源、销售与支持 |
| 典型风险 | 库存积压、退货率、假增长 | 隐性流失、降级、收入集中 |

表格之外，还有三个更隐蔽的差异。

第一，电商看「量」，SaaS 看「质」。电商的 GMV 可以靠补贴短期冲高，退款和退货会在后面几周吐回来；SaaS 的 MRR 一旦签下，会持续几个月甚至几年，所以「签了什么客户」比「签了多少」更重要。一个 10 万元的年单来自随时会流失的小客户，和另一个 10 万元的年单来自用得很深的中型客户，MRR 一样，风险完全不同。这也是为什么 SaaS 要单独看收入集中度：前五大客户占 MRR 的比例超过三成时，就要单独盯合同到期时间。

第二，电商的漏斗是一次性的，SaaS 的漏斗是循环的。电商的曝光到支付是一条线，走完就结束；SaaS 的注册、激活、付费、续费、增购是一个环，任何一段断掉都会影响下一圈。所以 SaaS 分析里 cohort 是默认视角，电商分析里 cohort 是补充视角。

第三，电商的归因更依赖渠道，SaaS 的归因更依赖人。电商用户可以在一次会话里完成决策，渠道归因能解释大部分；SaaS 的决策链有试用、评估、采购、法务，单靠最后一次点击归因会把销售和客户成功的贡献全部抹掉。SaaS 公司常用多触点或按阶段归因，但结果只能作参考。

能力是可以迁移的。指标树、分母意识、队列思维、实验设计，这四样在两个行业都通用。真正需要重新学的是业务常识：电商要知道库存和履约的约束，SaaS 要知道席位和续费的结构。工具和 SQL 反而是最容易迁移的部分。

## 本篇要点回顾

1. 人货场是一棵指标树，不是三张清单；总量下跌时先验口径，再拆人货，最后看场。
2. GMV 四因子是恒等式，不是因果模型；北辰优选 3 月的 -8% 里，转化率和客单价各贡献约一半。
3. 漏斗看单次转化，留存看长期价值；3 月新增 +7% 但 30 日留存从 24% 掉到 19%，问题在新客结构而不是产品。
4. SaaS 的主干是 MRR 桥，NRR 97.5% 说明老客收入在缩水，增购不足比流失更值得先查。
5. 两个行业的差异在关系长度：电商卖完即结束，SaaS 签完才开始；指标、队列和归因方式都要跟着换。

## 延伸阅读

- 第 03 篇《描述性分析与指标体系》：漏斗、留存、RFM 的原始定义，本篇的人货场地图是它的行业版。
- 第 04 篇《诊断性分析与归因》：对数贡献拆解与下钻顺序，本篇案例直接沿用了它的方法。
- 第 05 篇《统计推断与 AB 实验》：详情页改版要不要回滚，最终要靠实验而不是前后对比。
- 第 10 篇《行业实战：金融、零售、制造、医疗》：另外四个行业的指标与合规边界，可以和本篇的电商、SaaS 对照。
- 第 11 篇《分析报告与沟通》：把「三个假设 + 验证动作」写成一页结论，是本篇案例的下一步。