如何理解session分析
假设我们是个电商企业，包含了web端,app,小程序的产品。以下是小王访问产品的行为序列：
- 启动(平台=JS)
- 浏览页面(平台=js,商品=男装)
- 浏览页面(平台=js,商品=手机)
- 浏览商品详情(平台=js,商品=手机)
- 加入收藏(平台=JS,商品=手机)
- 浏览页面(平台=js,商品=食品)
- 启动(平台=JS)
- 浏览页面(平台=js,商品=电脑)
- 浏览商品详情(平台=js,商品=电脑)
- 加入购物车(平台=js，商品=电脑)
- 提交订单(平台=安卓，商品=电脑)
- 订单详情(平台=安卓，商品=电脑）
- 确认支付、完成订单(平台=后端埋点)
- 结束(平台=安卓)
- 启动(平台=小程序)
- 我的订单(平台=小程序)
小王同学的这一系列行为，应该算成几次会话呢？
本文将试着通过1个例子，讲清楚session分析各个功能点、指标的业务口径以及使用场景。
1. 为什么要有session分析，什么是session分析，什么是session
我们知道通过事件分析我们能够准确的知道用户干了些什么，比如浏览多少次页面，浏览了那些商品、浏览多少次等等。但是这些统计都是基于”点”(单次行为)的分析，而分析人员会有一些新的需求，我们通过事件分析对于”点”的统计无法直接满足。
比如：
用户访问了多少次？
用户访问了多久？
用户每次都是从哪些渠道来源进入的？
用户每次访问，访问多少页面？
以上这些指标需要把用户的行为串成一个新的”整体”，然后基于此进行进行统计。这样的一个新的”整体”，我们就称为一次会话或者一次session访问。因此，我们可以认为，用户连续的一串行为组成了session会话，而基于session会话的分析就被称为session分析。
需要知道小王完成的一系列行为归属是几次会话，即需要明确会话的切割划分方法，也就是 连续行为如何定义。目前，市场主流会提供2种切割方法：
1 SDK自动切割：
根据行业通用切割方案，采用统一的切割标准。对采集的行为数据进行session划分，同一个会话的行为数据“$session_id” 相同。SDK预置切割规则，包括JS端 超时，直接打开新的页面。APP端的退出等等。 详细切割规则 待补充。目前渠道分析以及session分析的系统取值规则都是基于 SDK自动切割进行计算。
2 用户自定义切割：
目前uba提供了。超时、0点切割(跨天)、指定会话结束事件、是否跨平台切割 4种切割规则供用户根据实际情况自助选择
两种切割方式对比：
| 优点 | 缺点 | |
|---|---|---|
| 默认SDK切割 | 1、更通用的切割方式 2、更容易被理解、接受 3、提前切割好session,相对动态切割性能更好 | 1、强依赖sdk前端埋点，后端埋点以及外部导入的行为数据一般不适用 2、跨平台无法打通，比如WEB端提交购物车，APP端支付 无法计算到单次session会话中 3、无法适用所有场景 |
| 自定义动态切割 | 1、灵活制定切割规则，且规则功能上还有扩展空间。 2、满足所有数据下的sesssion分析。 3、更抽象 有着陆、退出、跳出的相关分析 不仅局限于对PV事件的分析 | 1、难以理解，且数据容易波动 2、抽象程度高，较难理解。且数据较难解读。 3、计算成本高，性能慢 |
虽然存在两种切割方式，但是只是session划分层面的差异，不影响后续的session的相关分析
2 有了session，哪什么是session属性，与事件属性有什么区别
描述单条行为的属性，就是事件属性
比如浏览页面(平台=js,商品=男装)——浏览页面(平台=js,商品=手机) 2个事件中，商品属性分别是男装和手机。
描述session的属性就是session属性，所有可以用来描述这次会话的信息都可以被认为是此次会话的session属性。
举例：小王的一次session会话的行为序列为： 启动(平台=JS)——浏览页面(平台=js,商品=男装)——浏览页面(平台=js,商品=手机)——浏览商品详情(平台=js,商品=手机)——加入收藏(平台=JS,商品=手机)——浏览页面(平台=js,商品=食品)。在这次会话中，所有可以用来描述这次会话的属性都可以被当做session属性，比如 着陆页、退出页、会话的浏览页面数、会话的总时长（注意不是单个页面的时长）等等
而除了这些通用的session属性外，那些用户主动上报的属性是否能够单做成session属性使用呢。当然可以，但是需要做一些处理。 比如上述例子中，我们用 商品属性 来分析这次会话，就会发现，这次会话中多个事件都包含了商品属性，而且取值可能不同。因此我们需要约定一个规则来确保每一个用来作为session属性的取值具备唯一性。规则为：我们取会话首事件的属性作为本次会话的会话属性，即session属性。又如，一个会话的某个session属性的值是唯一的，用户整个会话每个PV的referer会不同，但是我们取会话首个pv的referer来判断会话的来源。
考虑到实际业务的情况种，在默认SDK切割下。会话的第一个事件往往是自动上报的”启动”，该事件中有效的自定义属性比较少。而关键属性往往会在之后的着陆页pv事件中上报；且某些场景下(主要是app的deeplink),utm 广告跟踪相关属性，无法保证第一个pv事件能够采集的到。
因此，
在默认SDK切割下：普通session属性，优先取会话首个pv事件的属性作为会话属性，Utm相关属性优先取会话内首个utm有效值的属性。
动态session切割规则下：因为动态切割具备更多的随机性以及不确定性，功能也更加抽象。因此动态切割规则下，还是沿用取会话首事件的属性作为本次会话的会话属性的规则。
3 session分析模块中，事件属性与session属性的应用
在默认SDK切割情况下的。session分析模块中”公共过滤条件”以及”细分维度”支持选择“事件属性”、“session属性”
公共过滤场景：
session属性过滤：即只统计满足筛选条件的会话。比如，一共有5次会话，满足条件的会话有3次，那么后面的统计都是基于这3次会话完成的
事件属性过滤：即只统计会话中满足筛选条件的事件。比如，有5次会话，筛选条件为url=xxx ，即统计每个会话中事件属性url=xxx的事件的指标情况。常用与，统计单个事件、页面的时长。统计会话中，事件属性等于筛选值的情况。比如，统计浏览过商品=手机的会话次数。
说明，实际上事件属性过滤更多会和选择事件相关指标一起查看，比如 统计完成 加入购物车事件，且添加商品=手机的会话情况，但是默认SDK切割暂时没有提供这个功能。
举例说明二者的差别：小王同学行为序列：
启动(平台=JS)
浏览页面(平台=js,商品=男装)
浏览页面(平台=js,商品=手机)
浏览商品详情(平台=js,商品=手机)
加入收藏(平台=JS,商品=手机)
浏览页面(平台=js,商品=食品)
session属性商品=手机进行筛选，将没有结果。
事件属性商品=手机进行统计。会话次数=1、访问时长=4.xwhen-3.xwhen，即3.浏览页面(平台=js,商品=手机）事件的时长。特别注意，按事件属性过滤或者分组时，只能查看 事件粒度的指标。即 会话次数以及时长。 其他会话粒度的指标，因为需要重新定义成 统计包含事件属性=XX的会话的情况。与上面的定义是不一致的。
分组场景：
session属性分组：即按会话的session属性进行分组。因为会话的session属性是唯一的，因此会话只会被分到同一个分组下。
事件属性分组：即按 会话中事件的属性进行分组，这样同一个会话可能会被多个分组统计
举例说明二者的差别：
启动(平台=JS)
浏览页面(平台=js,商品=男装)
浏览页面(平台=js,商品=手机)
浏览商品详情(平台=js,商品=手机)
加入收藏(平台=JS,商品=手机)
浏览页面(平台=js,商品=食品)
按session属性商品进行分组，分组结果为 男装 会话1次。此时统计的 时长=会话的总时长
按事件属性商品进行分组，分组结果为 男装、视频、手机 会话各一次，此时，时长将会等于商品等于各个属性的事件的时长之和。
4 动态切割session场景下的session分析 与 预置切割场景下session分析的差异
- 动态切割场景下，指标更加抽象。退出率、跳出率 在日常认识中往往用来统计退出页、跳出页的相关指标。而该场景下，泛化成 可以统计所有事件的退出率、跳出率。 此时如果需要统计退出 跳出的页面情况。 因为动态切割场景下，切割更加灵活。适用场景广泛，比如可以适用于无PV的场景下。
- 指标类型上分成了2个大类。session总体：即 总体session的指标情况；事件(包括任意事件和单个事件)：选择该场景下，主要分析的是 会话中，该事件对应的指标情况，包括普通的事件指标（同事件分析，预置session场景下未开放该功能）以及依赖于session的指标(时长、次数 主要这里的时长、次数实际是事件粒度的指标，只是需要依托session功能才能计算)。说明：预置场景下，按过滤条件、分组属性中选择事件属性，业务口径上等同于动态切割场景下，”任意事件” 下查看的指标。事件场景下，同时支持查询 部分session相关的指标
- 以下表格 说明了各种选择下代表的业务指标含义