4、用户行为数据:打开次数、访问深度、停留时长、页面路径分析,行为日志的ETL流程

用户行为数据,说白了就是用户在微信生态里「干了什么」的数字化记录。我做了这么多年数据分析,最深的感触就是:没有行为数据,用户画像就是空中楼阁。你想想看,光知道用户性别年龄有什么用?他到底喜不喜欢你的内容、在哪个页面流失了、每天打开几次小程序——这些才是运营决策的命根子。

4.1 四大核心指标:打开次数、访问深度、停留时长、页面路径

这四个指标,我习惯叫它们「行为四件套」。每个指标背后都有坑,咱们一个一个说。

4.1.1 打开次数(Launch Count)

打开次数,就是用户启动小程序或公众号的次数。听起来简单吧?但这里有个细节:微信的「打开」定义是「冷启动」。用户切到后台再切回来,不算新打开。只有进程被杀死、或者超过5分钟没操作再进来,才算一次新打开。

我曾经踩过的坑:有一次做活动复盘,发现打开次数暴涨300%,团队兴奋得不行。结果一查,是某个安卓机型把「后台切前台」也算成了打开。嗯,从那以后我每次看打开次数,都会先确认一下数据口径。

4.1.2 访问深度(Visit Depth)

访问深度,指的是用户在一次会话中浏览了多少个页面。这个指标能直接反映内容的吸引力。

  • 深度=1:用户进来就跑了,典型的「看一眼就走」
  • 深度=3~5:正常浏览,说明内容有吸引力
  • 深度>10:重度用户,可能是你的核心粉丝

我个人习惯把访问深度和用户分层结合起来看。比如,深度<2的用户,我会标记为「浅度用户」,重点做召回;深度>10的,直接打上「高价值」标签。

4.1.3 停留时长(Dwell Time)

停留时长,是用户在每个页面或整个会话中待的时间。这里有个容易忽略的点:用户把页面挂着不动,算不算停留?算,但意义不大。我一般会区分「有效停留」和「无效停留」。

我的做法:设定一个阈值,比如页面停留超过30秒且没有滚动,就判定为「挂机行为」,在计算平均停留时长时剔除。否则你的数据会被那些「打开页面就去倒水」的用户拉高。

4.1.4 页面路径(Page Path)

页面路径,就是用户在小程序里「怎么走的」。这是我最喜欢看的数据,因为它能告诉你用户真实的决策流程。

举个例子,你设计了一个「首页→商品列表→详情页→下单页」的路径。但实际数据可能显示:大量用户从首页直接跳到了下单页。这说明什么?要么是首页有直达下单的入口,要么是用户通过分享链接跳过了中间环节。

页面路径分析,我建议用桑基图来展示。一眼就能看出流量在哪分流、在哪流失。

4.2 行为日志的ETL流程

行为日志,就是用户每次操作留下的「脚印」。微信生态里,这些日志通常以JSON格式上报。原始数据长什么样?我给你看个例子:

{
  "event": "page_view",
  "user_id": "oX8Wt5...",
  "session_id": "sess_20240315_001",
  "page": "/pages/index/index",
  "referrer": "/pages/home/home",
  "timestamp": 1710489600000,
  "duration": 12000,
  "device": {
    "platform": "iOS",
    "model": "iPhone 15 Pro"
  }
}

这种原始日志,直接拿来分析?别闹。必须经过ETL(Extract, Transform, Load)处理。我总结了一套标准流程,分三步走:

4.2.1 抽取(Extract)

从微信服务器、CDN日志、或者第三方统计平台(比如微信官方数据分析、友盟、GrowingIO)拉取原始数据。这里要注意:微信的日志有延迟,通常T+1才能拿到完整数据。实时数据?嗯,微信生态里基本没有真正的实时,别被忽悠了。

4.2.2 转换(Transform)

这是最核心的一步。我一般做以下几件事:

  • 字段清洗:去掉空值、异常值。比如duration为0的记录,直接过滤掉
  • 时间格式化:把时间戳转成可读的日期格式,同时提取出小时、星期几等特征
  • 用户识别:用OpenID或UnionID做用户去重。注意,同一个用户在不同设备上可能有不同OpenID
  • 会话划分:根据session_id把行为归到不同会话中。我习惯用「30分钟无操作」作为会话超时阈值
  • 路径拼接:把同一个会话内的页面访问按时间排序,拼成路径字符串

核心思路:ETL不是简单的数据搬运,而是把「机器日志」变成「可分析的行为数据」。我见过太多团队直接拿原始日志跑SQL,结果跑出来的数据根本没法用。

4.2.3 加载(Load)

清洗好的数据,加载到数据仓库里。我推荐用列式存储(比如ClickHouse、Doris),因为行为数据通常要按用户、时间做聚合查询,行式存储性能扛不住。

表结构设计上,我习惯建两张表:

表名 用途 分区字段
fact_behavior 存储每一条行为记录 dt(日期)
agg_user_session 按用户+会话聚合后的指标 dt, user_id

4.3 实战中的ETL避坑指南

做ETL这么多年,我总结了几条血泪教训:

  • 数据去重要谨慎:微信日志偶尔会有重复上报。我建议用event_id+timestamp做唯一键去重,而不是用user_id
  • 注意时区:微信服务器用的是UTC时间,但你的业务数据可能是北京时间。转换时一定要统一,否则「凌晨3点」的数据会跑到前一天
  • 别忽略referrer字段:这个字段告诉你用户从哪来的。很多团队只关注page,忽略了referrer,结果路径分析永远做不对

一个小技巧:在ETL过程中,我会额外生成一个「用户行为序列」字段。比如用户A的路径是「首页→搜索→详情页→下单页」,我会存成字符串"index,search,detail,order"。这样后续做路径聚类分析时,直接like匹配就行,不用再跑复杂的SQL。

4.4 从数据到洞察:一个真实案例

我记得去年帮一个电商小程序做分析。他们的打开次数很高,但转化率一直上不去。我拉了一个月的页面路径数据,发现:

  • 70%的用户在「商品详情页」停留超过1分钟
  • 但只有15%的用户点击了「加入购物车」按钮
  • 大部分用户看完详情后,直接返回了首页

这说明什么?详情页的内容没有促成购买决策。后来我们优化了详情页的「用户评价」和「优惠券展示」模块,转化率提升了22%。

你看,如果没有页面路径分析,你根本不知道问题出在哪个环节。

4.5 总结一下

用户行为数据,是微信生态里最值钱的数据资产。打开次数告诉你「来了多少人」,访问深度告诉你「留不留得住」,停留时长告诉你「内容好不好」,页面路径告诉你「怎么走的」。而ETL,就是把这些原始日志变成可分析、可决策的「黄金数据」。

嗯,下一章我会讲怎么用这些数据做用户分层和生命周期管理。到时候咱们再细聊。