把用户的生命周期显性化为可量化的"状态"，追踪用户在状态之间的迁移，是分层运营的数据基础。
大多数业务都知道要"分层运营"，但"分层"背后的核心动作是：定义用户在某个时刻属于哪个状态，以及他们在不同时间点之间如何移动。
状态：用户在某个时间截面上的身份标识。例如：
流转：用户从一个状态移动到另一个状态的过程。例如：
状态流转分析的输出，是一张矩阵：上个月每种状态的用户，这个月变成了什么状态？
以下是电商场景最常用的 6 状态框架，可以和理想汽车的链路一一对应：
| 状态 | 定义 | 理想汽车对应 | |---|---|---| | 新用户 | 近 N 天内首次下单 | 新线索（首次留资） | | 活跃用户 | 近 30 天有下单，且非新用户 | 活跃意向（多次跟进中） | | 沉默用户 | 近 31-90 天无下单 | 冷却线索（30 天无回应） | | 流失用户 | 近 90 天以上无下单 | 流失线索（掉单 / 竞品成交） | | 召回用户 | 曾沉默 / 流失，但近 30 天重新下单 | 重新激活线索 | | 高忠诚用户 | 连续 3 个月均有下单 | 转介绍客户（极高忠诚） |
设计状态体系时需要考虑的问题：
核心 SQL 思路：计算每个用户在两个相邻月份的状态，然后统计状态对。
-- Step 1: 计算每个用户每个月的状态
WITH monthly_state AS (
SELECT
customer_id,
stat_month,
CASE
WHEN days_since_first_order <= 30 THEN '新用户'
WHEN days_since_last_order <= 30 THEN '活跃用户'
WHEN days_since_last_order BETWEEN 31 AND 90 THEN '沉默用户'
WHEN days_since_last_order > 90 THEN '流失用户'
ELSE '未购用户'
END AS user_state
FROM user_monthly_metrics
),
-- Step 2: 把当月和上月状态放在同一行
state_transition AS (
SELECT
curr.customer_id,
prev.stat_month AS prev_month,
prev.user_state AS prev_state,
curr.stat_month AS curr_month,
curr.user_state AS curr_state
FROM monthly_state curr
JOIN monthly_state prev
ON curr.customer_id = prev.customer_id
AND PERIOD_DIFF(
REPLACE(curr.stat_month, '-', ''),
REPLACE(prev.stat_month, '-', '')
) = 1
)
-- Step 3: 汇总流转矩阵
SELECT
prev_state,
curr_state,
COUNT(DISTINCT customer_id) AS user_count,
ROUND(COUNT(DISTINCT customer_id) / SUM(COUNT(DISTINCT customer_id)) OVER (PARTITION BY prev_state), 4) AS transition_rate
FROM state_transition
GROUP BY prev_state, curr_state
ORDER BY prev_state, user_count DESC;
输出示例：
| 上月状态 | 本月状态 | 用户数 | 流转率 | |---|---|---|---| | 活跃用户 | 活跃用户 | 2,841 | 72.3% | | 活跃用户 | 沉默用户 | 748 | 19.0% | | 活跃用户 | 高忠诚用户 | 341 | 8.7% | | 沉默用户 | 流失用户 | 1,203 | 58.4% | | 沉默用户 | 活跃用户 | 287 | 13.9% | | 沉默用户 | 沉默用户 | 571 | 27.7% |
从这张表可以直接看出：
状态流转矩阵用 Sankey（桑基图）可视化，视觉效果最直观：
在 Recharts 中实现需要自定义（Recharts 原生不支持 Sankey，需要用 d3-sankey 或 @visx/sankey）。但可以用堆叠面积图或树图做简化版可视化。
从流转矩阵里可以直接提炼出几个重要的运营监控指标：
1. 活跃留存率：活跃用户中，下月仍然活跃的比例
活跃留存率 = 活跃→活跃 / (活跃用户总数)
2. 活跃流失率：活跃用户中，下月变为沉默或流失的比例
活跃流失率 = (活跃→沉默 + 活跃→流失) / 活跃用户总数
3. 召回率：沉默用户中，下月重新变为活跃的比例
召回率 = 沉默→活跃 / 沉默用户总数
4. 流失加速率：沉默用户中，进一步流失的比例
流失加速率 = 沉默→流失 / 沉默用户总数
这 4 个指标每月追踪，就能构成完整的生命周期健康度监控体系。
汇总的流转率常常遮盖细节。真正有价值的洞察往往在下一层：
按渠道拆解：不同获客渠道来的用户，活跃留存率有差异吗？
按获客时间拆解（Cohort）：不同月份的用户，90 天留存率有变化趋势吗？（见 learn/04-funnel-cohort-retention.md）
按 RFM 分层拆解：高价值用户和低价值用户的流失率有多大差异？
在理想汽车，我们在省区层面做过类似分析：哪些城市的线索流失率高于平均，进而定位是跟进速度慢、还是到店邀约转化率低，还是竞品更强。
一旦识别出"关键流转节点"，就能精准定义运营干预时机。
| 流转节点 | 含义 | 运营动作 | |---|---|---| | 活跃 → 沉默（刚发生） | 最近 1 个月首次停购 | 发送"我们想念你"类 Push，附带个性化推荐 | | 沉默 30 天以上 | 沉默加深 | 发送限时优惠券，提高召回紧迫感 | | 沉默 → 流失临界（第 80 天） | 即将流失 | 高价值用户：人工电话触达；一般用户：自动化末次提醒 | | 新用户 → 无二购（首购后 14 天无复购） | 留存危险 | 推送首购相关品类的配套商品 / 教程内容 | | 活跃 → 高忠诚（连续 3 月下单） | 提升为忠诚用户 | 邀请加入 VIP 项目 / 专属权益 |
这些时机触发的运营干预，通常比定期批量发 Push 有更高的点击率和转化率，原因是精准匹配了用户当前的意向状态。
错误 1：状态粒度过细
定义了 12 个状态，导致运营人员无法快速判断对一个用户该做什么。规则是：每个状态要对应一套差异化的运营动作，如果两个状态的运营动作一样，就合并为一个。
错误 2：状态边界不清晰
"活跃用户"定义为"有行为的用户"，但没说是什么行为、多少天内。导致每次算出来的数字不一样，运营失去信任。
错误 3：状态变化不追踪历史
只维护用户当前状态，不记录历史状态变化。导致无法做流转分析，也无法定义"召回用户"（因为不知道这个用户上月是什么状态）。
解决方案：维护状态快照表，每月/每周存一次用户状态，保留至少 12 个月的历史。
在理想，用户状态流转对应的是线索状态：
这是一个单向线性流转（从新到成交），而电商场景是循环的（用户可以反复在活跃/沉默/召回之间流转）。
核心差异：
但底层逻辑相同：找到最容易流失的节点，在那里部署最强的运营干预。
| 能力 | 流转分析如何体现 | |------|----------------| | 构建完整的数据分析体系 | 流转分析是生命周期监控的骨架——4 个指标（留存率/流失率/召回率/加速率）构成完整的健康度面板 | | 定期业务复盘，输出洞察与策略建议 | 每个月看流转矩阵，找到"哪些用户在往坏的方向走"，精确计算沉默→流失的加速速度 | | 推动数据在业务中的实际落地 | 一旦识别出关键流转节点（如"活跃 28 天后开始沉默"），就能精准部署运营干预 |
在理想汽车，用户状态流转对应的是线索状态：新线索→已联系→邀约中→已到店→已下定→已成交。这是一个单向线性流转。
我发现了一个关键的流失节点：从"已到店"到"已下定"之间的转化，不同城市的差异高达 20 个百分点。进一步拆解发现，不是销售能力差异，而是试驾体验的满意度差异——试驾评分高的门店，到店→下定转化率是评分低的 2.3 倍。
这个发现推动了试驾体验的标准化改造。核心认知：流转分析的终点不是数字，是指向一个可被团队执行的改进动作。
learn/04-funnel-cohort-retention.md：Cohort 分析是状态流转的时间维度延伸learn/01-tag-system.md：生命周期标签如何支撑状态流转计算workflow/attribution-sql-cookbook.md：SQL 7 辛普森悖论检测（流转分析的常见陷阱）