用窗口函数标记用户生命周期阶段需先用MIN(order_date) OVER (PARTITION BY user_id)计算首单日，再通过CASE WHEN结合当前订单时间判断阶段，避免静态标签失真；阶段值须在CTE或子查询中固化，不可在GROUP BY中动态计算，且需注意PostgreSQL与MySQL日期函数差异。
用窗口函数标记用户生命周期阶段
直接用 MIN(order_date) 算首次下单时间，再结合当前行为时间判断所处阶段，比硬编码“新客/老客”标签更可靠。窗口函数能避免重复扫描表，也规避了按用户聚合后再 join 带来的数据膨胀。
常见错误是把生命周期当成静态标签——比如只按注册时间分“新客”，但实际用户可能注册半年后才第一次下单，此时仍算“新客活跃”就失真了。
- 对每个
user_id，用MIN(order_date) OVER (PARTITION BY user_id)计算首单日 - 用
CASE WHEN order_date = first_order THEN 'acquisition' WHEN order_date 划分阶段 - 注意时区一致性：确保
order_date和系统当前时间使用同一时区（如全部转为UTC）
按渠道+生命周期交叉统计活跃用户数
活跃度本质是“在某生命周期内、某渠道获取的用户中，有多少人在指定时间段内有行为”。不能只 count distinct user_id，必须限定行为时间窗口和归属渠道来源。
容易踩的坑是渠道归属逻辑混乱：比如用户 A 首次访问来自微信，但首单来自 App，该算哪个渠道？通常以首单渠道为准，而非首次曝光渠道。
- 先关联订单与用户首次渠道（需提前建好
user_first_channel表，字段含user_id、first_channel、first_order_date） - 主表用订单事实表，LEFT JOIN 上述表，确保每个订单带所属用户的生命周期阶段和首获渠道
- 聚合时用
COUNT(DISTINCT user_id)，但 WHERE 条件要限制行为时间（如order_date >= '2024-01-01'），否则会混入历史冷用户
避免 GROUP BY 错误导致的活跃度失真
如果直接 GROUP BY channel, lifecycle_stage 算活跃用户数，却没控制时间粒度或去重逻辑，结果会偏高——同一个用户在不同月份多次下单，会被重复计入各月活跃。
真正的“某月某渠道某阶段活跃用户数”，是指该用户在当月至少有一次行为，且其生命周期阶段由首单时间决定（阶段不随月份变化）。
- 生命周期阶段必须在子查询或 CTE 中预先算好，不能在最外层 GROUP BY 里动态计算
- 若要按月看趋势，GROUP BY 应包含
DATE_TRUNC('month', order_date)，但lifecycle_stage仍来自用户维度固定值 - 警惕 NULL 渠道：未归因到具体渠道的订单（如 direct）要显式处理，否则
GROUP BY会丢弃整行
PostgreSQL vs MySQL 在日期计算上的关键差异
生命周期阶段判断依赖日期运算，而不同数据库对 INTERVAL 和时长加减的支持差异明显，写错会导致阶段全乱。
例如 MySQL 不支持 date + INTERVAL '30 days' 这种标准写法，必须用 DATE_ADD(date, INTERVAL 30 DAY)；PostgreSQL 支持前者，但对 INTERVAL '1 month' 是按日历月算（非30天），可能跨月偏差。
- PostgreSQL 推荐用
order_date - MySQL 必须写成
order_date - 统一建议：生命周期阶段划分尽量用天数（如 7/30/90），不用“月”，避免月末边界问题
first_channel 的取数链路做审计。 
