漏斗 + Cohort + 留存基础

三个概念看似独立，实际上是从不同维度回答同一个问题：用户在哪里流失了？

三者的关系

漏斗：空间视角。在某个时间段内，从 A 步骤到 B 步骤，有多少人流失？关注的是"哪个步骤卡人最多"。

留存：时间视角。用户第一次来了以后，后续是否还会回来？关注的是"用户在多长时间后流失"。

Cohort（同期群）：时间 × 人群视角。把同一时期获得的用户归为一组，追踪这组人随时间的留存曲线。关注的是"不同批次用户的留存质量是否有改善"。

三者配合使用的场景：

漏斗发现"加购到下单"流失最严重
留存分析发现"7 天留存比行业低 10%"
Cohort 分析发现"3 月和 4 月来的用户留存曲线一致，但 5 月来的用户明显更差"
结合时间线，找到 5 月发生了什么（可能是渠道质量下降或产品问题）

一、漏斗分析

漏斗的类型

有序漏斗：用户必须按顺序完成每一步，跳步无效。典型场景：电商下单流程（加购 → 结算 → 支付）。

无序漏斗：用户在一段时间内完成所有步骤即可，顺序不限。典型场景：用户激活（注册后 7 天内完成：设置头像 + 关注第一个商品 + 完成首购）。

漏斗指标计算

SELECT
    COUNT(DISTINCT CASE WHEN event_type = 'view' THEN user_id END) AS view_uv,
    COUNT(DISTINCT CASE WHEN event_type = 'cart' THEN user_id END) AS cart_uv,
    COUNT(DISTINCT CASE WHEN event_type = 'order' THEN user_id END) AS order_uv,

    -- 各段转化率
    ROUND(
        COUNT(DISTINCT CASE WHEN event_type = 'cart' THEN user_id END) * 1.0
        / NULLIF(COUNT(DISTINCT CASE WHEN event_type = 'view' THEN user_id END), 0),
    4) AS view_to_cart_cvr,

    ROUND(
        COUNT(DISTINCT CASE WHEN event_type = 'order' THEN user_id END) * 1.0
        / NULLIF(COUNT(DISTINCT CASE WHEN event_type = 'cart' THEN user_id END), 0),
    4) AS cart_to_order_cvr
FROM dwd_behavior_events
WHERE DATE(event_time) BETWEEN '2024-07-01' AND '2024-07-31';

漏斗分析的关键操作

1. 多维下钻

漏斗整体数字掩盖细节。真正的问题往往藏在某个渠道、某个设备类型或某个用户分层里：

-- 按渠道 + 设备类型双维下钻
GROUP BY channel, device_type

下钻后，对比不同维度的各段转化率，找到"显著低于整体平均"的切片，那里就是问题所在。

2. 同环比对比

漏斗数字的绝对值意义不大，同比 / 环比才有意义：

本月加购率 18.3% vs 上月 21.2%：下降了 2.9pp，是什么导致的？
本月下单率 62.1% vs 去年同期 58.4%：提升了 3.7pp，是哪个改动起了效果？

3. 时间窗口统一

漏斗里的各步骤必须在同一时间窗口内发生，否则分母不一致。通常选一个固定的分析周期（如 7 天内从 view 到 order），把超出窗口的行为剔除。

漏斗分析的常见误区

误区：用总数而不是去重 UV

如果用事件次数而不是用户数来算漏斗，同一个用户多次浏览会把分子虚高。漏斗分析必须用 COUNT(DISTINCT user_id)。

误区：未过滤测试数据

内部账号、爬虫流量、测试订单都应该在漏斗分析中排除，否则转化率会失真。

二、留存分析

留存率的定义

N 日留存率 = 在第 0 天获得的用户中，在第 N 天仍然有行为的用户比例。

| 留存指标 | 定义 | 常见基准 | |---|---|---| | 次日留存（D1） | 第 0 天注册/激活，第 1 天有行为 | App：30-50% | | 7 日留存（D7） | 第 0 天，第 7 天有行为 | App：10-25% | | 30 日留存（D30） | 第 0 天，第 30 天有行为 | App：5-15% | | 月留存（M1） | 首购月，次月仍有购买 | 电商：20-40% |

注意：D1/D7/D30 是"在第 N 天"，而不是"在 N 天内"。这两种口径结果差异很大。有些产品会用"1-7 天内任意一天有行为"作为 7 日留存，会显著高于"仅统计第 7 天"，口径需要统一。

留存曲线形态

典型的留存曲线会经历三段：

留存率
100% |
 80% |  *
 60% |    * *
 40% |        * *
 30% |              * * * * * * * * * * (趋于平稳 = 核心用户群)
  0  +---------------------------------------> 天数
     D0  D1  D7  D14  D30  D60  D90

快速下降期（D0-D7）：大量用户在首周流失，这是最关键的干预窗口
缓慢下降期（D7-D30）：下降速度减缓
平稳期（D30+）：留下来的是核心用户，留存率趋于稳定

留存曲线最终水平值越高，说明产品核心用户群越大，长期商业价值越强。

三、Cohort 分析

什么是 Cohort

Cohort 是"按某个共同特征分组的用户群"。最常见的 Cohort 是按首次行为时间分组：1 月注册的用户是一个 Cohort，2 月注册的是另一个。

Cohort 留存矩阵

Cohort 留存矩阵是最常见的可视化形式：

| 获客月 | 群体大小 | M0 | M1 | M2 | M3 | M4 | M5 | |---|---|---|---|---|---|---|---| | 2024-01 | 1,238 | 100% | 32.1% | 25.3% | 20.8% | 18.2% | 16.9% | | 2024-02 | 987 | 100% | 35.6% | 28.1% | 22.4% | 20.1% | - | | 2024-03 | 1,105 | 100% | 38.2% | 31.0% | 26.3% | - | - | | 2024-04 | 1,420 | 100% | 40.1% | 33.2% | - | - | - | | 2024-05 | 1,680 | 100% | 28.4% | - | - | - | - |

读法：

每行从左到右看 = 这批用户随时间的留存曲线
每列从上到下看 = 不同批次用户在同一月龄的对比
M1 列从 32.1% 升到 40.1%（1月→4月）= 产品的 30 天留存在持续改善
5月 M1 骤降到 28.4% = 5月有异常，需要溯源

Cohort 分析的价值

价值 1：排除"基数增长"的干扰

如果 5 月 MAU 下跌，可能是因为 3 月获得的用户在 3 个月后开始大规模流失，而不是 5 月新来的用户质量差。Cohort 分析帮助区分"存量流失"和"新增不足"。

价值 2：评估产品改进的效果

如果 3 月上线了一个新功能，3 月 Cohort 的留存曲线比 2 月 Cohort 更好，就有初步证据表明这个功能有效（但要排除其他干扰因素）。

价值 3：预测未来留存

知道历史 Cohort 的留存曲线形态，可以对当前新用户的未来留存做预测，帮助业务预判 3-6 个月后的 MAU。

Cohort SQL 实现

WITH first_order AS (
    SELECT
        customer_id,
        DATE_FORMAT(MIN(invoice_date), '%Y-%m') AS cohort_month
    FROM dwd_order_detail
    WHERE invoice_no NOT LIKE 'C%' AND quantity > 0
    GROUP BY customer_id
),
cohort_activity AS (
    SELECT
        fo.customer_id,
        fo.cohort_month,
        DATE_FORMAT(o.invoice_date, '%Y-%m') AS activity_month,
        PERIOD_DIFF(
            REPLACE(DATE_FORMAT(o.invoice_date, '%Y-%m'), '-', ''),
            REPLACE(fo.cohort_month, '-', '')
        ) AS period_offset
    FROM dwd_order_detail o
    JOIN first_order fo ON o.customer_id = fo.customer_id
    WHERE o.invoice_no NOT LIKE 'C%' AND o.quantity > 0
),
cohort_size AS (
    SELECT cohort_month, COUNT(*) AS cohort_size
    FROM first_order GROUP BY cohort_month
)
SELECT
    ca.cohort_month,
    ca.period_offset AS months_since_first_order,
    COUNT(DISTINCT ca.customer_id) AS retained_users,
    cs.cohort_size,
    ROUND(COUNT(DISTINCT ca.customer_id) * 1.0 / cs.cohort_size, 4) AS retention_rate
FROM cohort_activity ca
JOIN cohort_size cs ON ca.cohort_month = cs.cohort_month
WHERE ca.period_offset BETWEEN 0 AND 5
GROUP BY ca.cohort_month, ca.period_offset, cs.cohort_size
ORDER BY ca.cohort_month, ca.period_offset;

三者联动的分析框架

场景：MAU 环比下滑 15%，如何溯源？

Step 1 — 漏斗分析（定位问题在哪个层）

先拆分 MAU 下滑的来源：

新用户减少（获取层问题）
老用户留存下降（留存层问题）
召回用户减少（唤回层问题）

如果主要是老用户留存下降，继续 Step 2。

Step 2 — 留存分析（确认留存曲线变化）

对比本月和上月活跃用户的 D7/D30 留存率。如果 D7 留存从 28% 降到 22%，说明首周流失加剧。

Step 3 — Cohort 分析（定位是哪批用户）

看 Cohort 矩阵，找出留存曲线突然恶化的 Cohort。如果 3 月 Cohort 的 M2 留存（即 5 月时）大幅下降，说明是 3 月来的用户在 5 月大量流失。

Step 4 — 多维下钻（找到具体原因）

对留存变差的 Cohort 做多维下钻（渠道/设备/城市），找到问题集中在哪个细分群体。

这个框架在理想汽车中的类似应用：MAU 换成"本月线索到店率"，漏斗换成"线索→邀约→到店"漏斗，Cohort 换成"按线索创建月分组"。底层逻辑完全一致。

常见的认知误区

误区 1：留存率越高越好

高留存率如果来自小基数用户群，可能只是"核心粉丝"效应。更有价值的是提高留存率的同时扩大获客规模。

误区 2：Cohort 留存改善 = 产品改进有效

Cohort 改善可能有很多原因：产品改进、渠道质量提升（优质用户比例上升）、季节性。需要排除这些干扰因素，或通过 AB 实验来验证。

误区 3：把留存率和活跃率混淆

留存率（Retention）= 第 N 天/第 N 月还在的比例，分母是历史获得的用户。活跃率（Active Rate）= 当月活跃用户 / 总注册用户，分母包含所有历史用户，会随时间越来越低。

两个指标都有用，但口径差别很大，不能混用。

求职视角：三步联动是分析能力的核心体现

| 能力维度 | 三步联动如何体现 | |---------|----------------| | 深度参与核心业务，拆解为数据指标体系 | 三步联动是一个完整的溯源框架：漏斗定位→留存确认→Cohort 溯源→下钻归因 | | 定期业务复盘，输出洞察与策略建议 | 这个框架可以直接用于月度业务复盘——不是报数字，而是讲"哪批用户在哪步出了问题" | | 异常监控与决策支持 | 当 KPI 异常时，这个框架提供了系统化的排查路径，避免凭直觉猜测 |

面试叙事

在理想汽车，我面对过一个典型的问题：全国线索到店率环比下降 8%。如果用单指标看，只能说"下降了 8%"，无法给出任何可执行的建议。

我用三步联动框架做了排查：漏斗分析定位到「邀约→到店」环节掉了最多 → 留存分析确认是老线索的邀约响应率下降而非新线索减少 → Cohort 分析发现 6 月创造的线索在 8 月的异常流失率最高 → 多维下钻锁定到 3 个低效城市的销售团队人效不足。

最终结论不是"线索到店率下降"，而是"3 个城市的销售人均跟进量下降 30% 导致 6 月线索在 8 月大量流失"。这个结论直接推动了销售团队的编制调整。

核心能力：不是会算漏斗、留存、Cohort 三个指标，而是能在 KPI 异常时自动启动这个分析框架，从现象追溯到根因。