菜单

Session 分析

视频版讲解

Session 分析概述

Session 分析是基于会话的分析,它将用户在客户端产品中分散的操作行为串联成“一次完整的使用过程”,从而帮助企业分析和统计用户在单次访问产品过程中的使用深度,某些特殊节点的访问情况等,帮助企业针对性的对产品功能进行优化和提升。无论是网站、APP 还是小程序,Session 分析都是优化产品功能、提升运营效率的关键工具。例如,需要分析一个 APP 中:

  • 用户平均会来几次?
  • 每次平均逛了几个页面?
  • 每次来平均呆了多久?
  • 某个具体页面的平均停留时长是多少?

则可以使用 Session 分析的功能,基于 SDK 采集的用户行为序列进行分析。

创建 Session

进行 Session 分析之前,需要先根据本次的业务分析需求和业务埋点情况创建 Session。

创建 Session 入口

分析 > Session 分析 ,然后点击右上角的 Session 管理 ,在弹出的 Session 管理窗口中点击 创建 Session

  1. 填写 Session 显示名
  2. 填写 Session 名
  3. 填写 备注 ,可选。
  4. 选择  Session 包含的事件 (注:此处应根据业务分析需求选择对应事件,例如:需要分析 APP 端用户每次打开 APP 的平均使用时长,那就选择 APP 端的所有用户可能触发的事件)。
  5. 设置切割规则
    1. 时间切割
    2. 事件切割

关于切割规则,下文进行详细介绍。

Session 的切割方法

时间切割

时间切割 ,是指当 相邻事件 间的时间间隔超出此时长,则进行一次切割。

注:此处的切割时长需要区别于网页开发中对会话时长的理解。此处设置的切割时间通常代表”用户无操作的超时时间“,即用户在设定时间内无任何交互,则代表本次会话结束,开启下次会话的匹配。而网页开发中的会话时长通常是指用户在设定时长内触发的所有事件为一次会话,超时则开启下一次会话。

事件切割

在时间切割的基础上,支持使用指定的 开始事件 结束事件 进行会话切割。其中, 开始事件  可选, 结束事件 必选。

事件切割使用场景

当我们对会话有明确的 开始事件 结束事件 的定义时,可以使用 开始事件 结束事件 让我们切割出来的会话更加符合预期。

例如:

  • 在视频行业中有明确的 开始播放 结束播放
  • 在移动端有明确的 App 启动 App 退出
  • 一次转化路径中,会认为 访问首页 是开始, 支付订单 是结束。
事件切割是如何实现的
  1. 将用户的行为序列按照发生时间由远到近进行排序。
  2. 以第一个行为作为起点,向后进行匹配。
    1. 若匹配到的是一个 开始事件 :会自动切断会话,并以这个 开始事件 作为起点,进行第二个 Session 的匹配。
    2. 若匹配到的是一个 结束事件 :会将这个 结束事件 划入到当前会话中,并以 结束事件 的下一个事件作为起点,进行第二个 Session 的匹配。
    3. 若在切割时间内没有匹配到 任何事件 :会根据设置的 Session 切割时间自动切断会话,并以下个事件作为起点,进行第二个 Session 的匹配。

Session 分析

选择 分析 > Session 即可使用 Session 分析。

  1. 在 A 处选择已经创建的 Session
  2. 在 B 处选择此 Session 中的 事件
    1. Session 总体 :可以对 Session 整体情况进行分析。
    2. Session 中具体某个事件 :可以对事件本身进行分析。
  3. 选择 指标 :在 B 处选择不同类型的事件,则 C 中对应的指标也会发生变化,除一些通用指标外,还包含 B 处所选事件的属性的指标。
  4. 设置 全局筛选
  5. 选择 分组
  6. 点击 查询 按钮。

Session 相关指标计算规则

下面对几个主要的指标的计算规则进行说明:

  • Session 中具体某个事件
    • 退出率: Session 的退出率包括 Session 中某个事件的退出率和 Session 中任意事件的退出率。某个事件的退出率指该事件作为 Session 的结束事件的次数除以该事件发生次数,任意事件退出率指 Session 数除以 Session 中所有事件发生次数。比如有三个 Session,第一个 Session 事件序列为 A,B;第二个 Session 事件序列为 A;第三个 Session 事件序列为 A,C,A;则 Session 中 A 事件的退出率为 2/4,任意事件的退出率为 3/6。
    • Session 内事件时长: 假如某 Session 内事件触发顺序为 a > b > c > d,则事件 a 的时长为 b 减去 a,事件 d 的时长未知。
    • Session 内事件发生次数: 分析 Session 内具体事件时,可以计算 Session 内事件发生次数。
  • Session 总体:
    • 跳出率: Session 中只发生一个事件的 Session 个数除以总 Session 数。比如有三个 Session,第一个 Session 事件序列为 A,B;第二个 Session 事件序列为 A;第三个 Session 事件序列为 A,C,B;则 Session 总体的跳出率为 1/3。
    • Session 时长: Session 内最后一个事件触发的时间减去 Session 内第一个事件触发的时间。
    • Session 深度: Session 内触发事件的次数。
    • 同时并发人数: 分析 Session 总体时,可以使用 Session 同时并发人数来计算该时间点同时存在的会话数。我们认为一个会话是一个持续的时段,在计算同时并发人数的时候,就判断该时间点有多少个会话同时在线即可。

如上图所示:

  • 时间点 1 的同时在线人数为 3。
  • 时间点 2 的同时在线人数为 2。
  • 时间点 3 的同时在线人数为 1。

在事件是存在持续行为的场景中,同时并发人数相对事件的发生次数更加有代表意义。

比如:

  • 一个视频类的 App,每个时段都有用户不断地进入和退出。
  • 当我们做一些线上的活动时,希望在用户 在线时间最密集 的那一刻进行活动的推送。
  • 那么我们如何判断出哪个时段是在线的用户最多的时段呢?

我们来看一下模拟数据的结论:

用户 启动时间 退出时间 启动时间查看指标 同时在线查看指标
A 19:01 20:14

19:00 - 19:30 —— 3 人

19:30 - 20:00 —— 1 人

20:00 - 20:30 —— 2 人

20:30 - 21:00 —— 0 人

结论得出 :在 19:00 - 19:30 期间进行投放效果最好。

19:00 - 19:30 —— 3 人

19:30 - 20:00 —— 4 人

20:00 - 20:30 —— 6 人

20:30 - 21:00 —— 2 人

结论得出 :在 20:00 - 20:30 期间进行投放效果最好。

B 19:14 20:14
C 19:29 20:14
D 19:59 20:14
E 20:14 21:01
F 20:29 22:01

实际上,我们的用户在 20:00 至 20:30 之间是在线人数最多的,在这个时间段进行运营活动效果最好。

如果想了解更多关于 Session 的内容,可阅读神策博客文章 《如何应用 Sensors Analytics 进行 Session 分析》

上一个
LTV 分析
下一个
用户路径分析
最近修改: 2025-10-13