SQL 用户行为分析 SQL 查询案例

13次阅读

mysql 用户留存率计算需统一日期粒度,避免 datetime 时分秒干扰;group_concat 须调大 max_len 防截断;会话切分应结合 lag 与时间差而非仅 row_number;漏斗分析宜用 exists 或独立聚合替代 left join 以防数据膨胀。

SQL 用户行为分析 SQL 查询案例

查用户留存率时,DATE_SUBDATE_ADD 别混用

MySQL 里算次日 / 7 日留存,核心是拿「首日行为日期」和「后续行为日期」做差值。很多人直接写 WHERE event_date = DATE_ADD(first_date, INTERVAL 1 DAY),但实际 first_date 如果是 DATETIME 类型(比如 '2024-03-01 14:22:05'),DATE_ADD 会保留时分秒,导致等值匹配失败。

正确做法是统一转成日期粒度再比:

  • DATE() 提取日期部分:DATE(event_date) = DATE(DATE_ADD(first_date, INTERVAL 1 DAY))
  • 或更稳妥:先用 MIN(event_date) 算出每个用户的首次行为时间,再用 DATE() 转成 DATE 类型存为 first_active_day,后续所有比较都基于这个字段
  • 注意 DATE_SUB(NOW(), INTERVAL 7 DAY) 返回的是带时分秒的 DATETIME,如果表里 event_dateDATE 类型,隐式转换可能走全表扫描

用户路径分析卡在 GROUP_CONCAT 长度截断

GROUP_CONCAT 拼用户点击序列(比如 'home>search>product>cart')很常见,但默认长度上限是 1024 字符,超长就 silently 截断——你根本看不出哪条路径被砍了。

必须显式调大:

  • 查当前设置:SELECT @@group_concat_max_len
  • 临时改(当前 session):SET SESSION group_concat_max_len = 1000000
  • 永久改需在 MySQL 配置文件加 group_concat_max_len = 1000000,重启生效
  • 如果路径节点太多(比如 >50 步),拼字符串本身性能差,建议改用窗口函数 + 递归 CTE 或导出后用 Python 处理

ROW_NUMBER() 在用户会话切分时漏掉并发行为

按用户 ID + 时间排序打序号来识别会话(比如 30 分钟无操作算新会话),常用 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time)。但它只保证顺序,不处理时间间隔逻辑。

真正要切会话,得结合 LAG() 计算上一次行为的时间差:

  • 先用 LAG(event_time) OVER (PARTITION BY user_id ORDER BY event_time) 取前一行时间
  • 再用 CASE WHEN TIMESTAMPDIFF(MINUTE, prev_time, event_time) > 30 THEN 1 ELSE 0 END 标记新会话起点
  • 最后用累计求和(SUM(is_new_session) OVER (PARTITION BY user_id ORDER BY event_time))生成会话 ID
  • 别直接用 ROW_NUMBER() 当会话 ID——它对同一秒内多个事件无法区分先后,且不感知业务定义的“空闲阈值”

漏斗分析中 LEFT JOIN 导致用户数虚高

写四步漏斗(曝光→点击→加购→下单)时,习惯性用 LEFT JOIN 连四张子查询,结果发现第二步用户数比第一步还多。问题出在:没去重,也没限制关联条件唯一性。

典型错误是这样:

SELECT COUNT(DISTINCT a.user_id) AS step1,        COUNT(DISTINCT b.user_id) AS step2 FROM exposure a LEFT JOIN click b ON a.user_id = b.user_id

如果一个用户在 a 表出现 1 次、在 b 表出现 5 次,LEFT JOIN 会生成 5 行,COUNT(DISTINCT b.user_id) 虽然仍是 1,但中间膨胀的数据量会让执行变慢,且一旦加了其他过滤条件(比如时间范围不一致),就容易误算。

更稳的做法:

  • 每步单独聚合:SELECT user_id FROM click WHERE event_time >= '2024-03-01' GROUP BY user_id
  • EXISTSIN 做包含判断,而不是 JOIN
  • 如果真要用 JOIN,确保关联字段在子查询里已 DISTINCT 或加 GROUP BY,避免笛卡尔积

漏斗数字失真的地方,往往不在逻辑,而在 JOIN 时没意识到数据已经重复了。

text=ZqhQzanResources