用户生命周期怎么定义？从新客到流失的状态机设计

-- 用户生命周期标签计算
SELECT
  user_id,
  register_date,
  last_active_date,
  DATEDIFF('${bizdate}', register_date) AS register_days,
  DATEDIFF('${bizdate}', last_active_date) AS inactive_days,
  login_cnt_30d,
  is_paid,          -- 是否有过付费
 
  CASE
    -- 新客期：注册不超过7天
    WHEN DATEDIFF('${bizdate}', register_date) <= 7
      THEN 'new_user'
 
    -- 流失期：近30天无登录（优先判断，避免被后面覆盖）
    WHEN DATEDIFF('${bizdate}', last_active_date) > 30
      THEN 'churned'
 
    -- 沉默期：近7天无登录但近30天内有登录
    WHEN DATEDIFF('${bizdate}', last_active_date) > 7
      AND DATEDIFF('${bizdate}', last_active_date) <= 30
      THEN 'silent'
 
    -- 成熟期：近30天活跃>=15天且有付费
    WHEN login_cnt_30d >= 15 AND is_paid = 1
      THEN 'mature'
 
    -- 活跃期：其他有登录的用户
    ELSE 'active'
  END AS lifecycle_stage
 
FROM ads_user_profile
WHERE dt = '${bizdate}';

-- 用户生命周期状态流转拉链表
CREATE TABLE dwd_user_lifecycle_history (
  user_id          STRING COMMENT '用户ID',
  lifecycle_stage   STRING COMMENT '生命周期阶段',
  start_date       DATE   COMMENT '进入该阶段的日期',
  end_date         DATE   COMMENT '离开该阶段的日期（9999-12-31表示当前）',
  is_current       INT    COMMENT '是否当前状态：1是0否',
  duration_days    INT    COMMENT '在该阶段停留天数'
) STORED AS PARQUET;
 
-- 每天更新拉链表：检测状态变化
-- 今天的状态和昨天不一样 -> 昨天的记录关闭，今天新开一条
INSERT OVERWRITE TABLE dwd_user_lifecycle_history
SELECT user_id, lifecycle_stage, start_date,
  CASE
    WHEN is_current = 1 AND lifecycle_stage != today_stage
      THEN '${bizdate}'       -- 状态变了，关闭旧记录
    ELSE end_date
  END AS end_date,
  CASE
    WHEN is_current = 1 AND lifecycle_stage = today_stage THEN 1
    ELSE 0
  END AS is_current,
  DATEDIFF(end_date, start_date) AS duration_days
FROM dwd_user_lifecycle_history h
LEFT JOIN today_lifecycle t ON h.user_id = t.user_id;

状态流转分析——运营最关心的问题

拉链表建好后，可以回答运营最关心的几个问题：

-- Q1: 每天各阶段的用户数（生命周期漏斗）
SELECT lifecycle_stage, COUNT(DISTINCT user_id) AS user_cnt
FROM ads_user_profile WHERE dt = '${bizdate}'
GROUP BY lifecycle_stage;
 
-- Q2: 用户从活跃到沉默平均需要多少天？
SELECT AVG(duration_days) AS avg_active_days
FROM dwd_user_lifecycle_history
WHERE lifecycle_stage = 'active'
  AND end_date != '9999-12-31';  -- 已经离开活跃期的用户
 
-- Q3: 沉默用户有多少被成功召回？
SELECT
  COUNT(DISTINCT CASE WHEN next_stage IN ('active','mature')
    THEN user_id END) AS recalled_users,
  COUNT(DISTINCT CASE WHEN next_stage = 'churned'
    THEN user_id END) AS lost_users,
  ROUND(COUNT(DISTINCT CASE WHEN next_stage IN ('active','mature')
    THEN user_id END) * 100.0 / COUNT(DISTINCT user_id), 2) AS recall_rate
FROM dwd_user_lifecycle_history
WHERE lifecycle_stage = 'silent' AND end_date != '9999-12-31';

面试高频追问

追问一：不同业务的生命周期阶段划分标准差异很大，怎么确定？

没有通用标准，必须结合业务数据来定。我的做法是：先拉用户活跃间隔的分布图——看用户两次活跃之间的平均间隔天数。如果大部分用户的活跃间隔<3天，那7天不活跃就可以算沉默了。如果活跃间隔的P75是10天（75%的用户10天内会再次活跃），那沉默的阈值可以设在15天。流失阈值一般设在活跃间隔P95以上——超过这个天数不活跃的用户，95%不会回来了。

追问二：用户能从流失状态回到活跃吗？状态机允许逆向流转吗？

允许的。流失用户收到召回推送后重新登录，就会从churned回到active。这就是为什么用拉链表——可以记录用户的完整状态流转历史，包括多次流失和回流。实际数据显示，流失后回流的用户中，约40%会在一周内再次流失——说明召回策略需要持续跟进，不是发一次推送就够了。

追问三：生命周期标签和RFM标签有什么区别？能替代吗？

不能替代，两者互补。RFM是从消费维度给用户打分（你花了多少钱、买了多少次），生命周期是从活跃维度做阶段划分（你现在还活不活跃）。一个高RFM得分的用户可能处于沉默期（之前花了很多钱但最近不活跃了）——对运营来说这个用户既是高价值又是流失风险，需要优先召回。两个标签组合使用，运营策略更精准。

实战踩坑

我在某出海硬件品牌做生命周期标签时犯过一个错误：一开始把「近30天无登录」作为流失的定义。后来发现智能硬件用户的行为模式和App用户完全不同——很多用户只在周末使用设备，工作日完全不打开App。按30天的标准，有些周末用户也被标记为流失了。

排查后发现，硬件用户的活跃间隔P75是12天（因为有些用户两三周才打开App看一次数据），P95是45天。最终我把沉默阈值从7天调到15天，流失阈值从30天调到45天，分层后的准确率从70%提升到了88%。

教训：生命周期的阈值不能拍脑袋定，必须看数据分布。不同业务类型（高频App vs 低频硬件）的活跃间隔差异很大。先分析活跃间隔的P50/P75/P95分布，再基于分布定阈值。

总结

用户生命周期是一个五阶段状态机：新客→活跃→成熟→沉默→流失。每个阶段的定义必须基于数据分布而非拍脑袋。用拉链表追踪状态流转历史，支撑召回率分析和运营策略优化。面试时能讲清楚状态定义的依据（活跃间隔分布）和状态流转的追踪方案（拉链表），说明你做的画像是有业务深度的，不是照搬教科书。

下一篇聊一个数仓架构话题：画像项目的数仓分层怎么设计？ODS→DWD→DWS→ADS每层放什么？

你们的用户流失标准设在多少天？有没有做过生命周期状态流转分析？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长