Please enable JavaScript.
Coggle requires JavaScript to display documents.
神策数据分析模块 - Coggle Diagram
神策数据分析模块
事件分析
事件
概念:追踪或记录的用户行为或业务过程
示例:用户注册、浏览商品、添加购物车、支付订单
事件分析
概念:指基于事件的指标统计、属性分组、条件筛选等功能的查询分析
分析方式:事件、session
事件添加:第一个下拉框选择事件,第二个下拉框选择指标
通用分析指标:总次数、用户数、人均次数、预定义指标
添加自定义指标:通过四则运算新增一个指标,可使用预定义指标参与运算
添加筛选条件:多条件之间可以更改逻辑关系 且/或
按分组查看
按维度查看数据,支持通过多个维度分析数据
用户分组属性是数值类型,可自定义分组区间
时间类型,可选择不聚合,按照时间单位进行分组查看,也可以选择按照时间段汇总
时间组件
时间粒度:分钟、小时、天、周、月
静态时间:指定的固定时间
动态时间:随时间推移而改变
时间对比:支持上一段时间、去年同期、自定义(直接选择时间)
图表类型切换
线图:所有场景
柱状图:所有场景,支持数值和百分比两种展示形式
饼图:有分组的查询场景,不支持预定义指标
累积图:支持只有总次数、总和的指标,不支持预定义指标
图表展示筛选:分组数据
表格:
导出数据
汇总数据:分层展示格式,不含日期
明细数据:原始数据,一维数据
明细报表:横向有日期,二维数据
透视表:未开启时间对比、查询条件至少有一个分组、查询条件至少有一个可用于统计的指标;
有分组,且指标中有非去重的计数型指标的查询结果导出的文件才有
展示方式
分层展示:需要两个及以上分组,支持列占比开关,每层有子合计
平铺展示:展开 / 收起日期->按日期展开 / 按指标展开;支持环比增长率展示
FAQ
分组过多,数据显示不完整,可以通过查询 API 获取完整数据
事件分析和漏斗分析逻辑不太一致,查看的用户数可能会不一致
合计值和每天相加的用户不一致,因为用户数有去重机制
按天查看和按周查看数据不一致,因为按周查看,是自然周的数据
App端数据,今天查看昨天的数据和昨天查看当天的数据不同,因为App 端有缓存机制
事件分组
调出分组看板
自定义看板:所有内容都可修改
默认看板:默认分组只有管理员可修改
漏斗分析
时间范围:在界面上选择的时间范围,是指漏斗的第一个步骤发生的时间范围
窗口期:用户完成漏斗的时间限制,即在这个时间范围内,用户从第一个步骤,行进到最后一个步骤
创建:漏斗分析>创建漏斗>填写名称、窗口期、步骤>保存
步骤:由一个 元事件/虚拟事件 加一个或者多个筛选条件组成
漏斗属性关联:每个事件添加触发条件,关联商品某属性(如ID),以保证是同一个商品。如果不设置关联商品的属性,则用户浏览商品详细页与支付订单的商品不是同一个,也会被算作转化成功
分组
分组规则:按照每个用户该属性的首次有效值进行分组,一个用户只会出 现在一个分组中
分组含义:对完成转化/确认流失的用户的集合上进行分组
使用:
1、选择“趋势”,点击某个具体步骤,可以详细地查看两个步骤之间的流失用户数、转化用户数、转化时间中位数和转化率(“对比”状态不能查看),点击“显示设置”可以设置当前折线图的显示指标
2、修改、删除漏斗:“铅笔”图标,可以新增步骤,修改步骤及指标,也可以删除漏斗,另存为漏斗
算法举例:
1、假设一个漏斗中包含了 A、B、C、D四个步骤,选择的时间范围是1 月 1 日到 1 月 3 日,窗口期是 1 天。某用户在1月1日到1月3日触发了步骤 A,并且在步骤 A 发生的 1 天内,依次触发了 B、C、D,则该用户完成了一次成功的漏斗转化。尽管中间穿插了一些其他的事件,也算成功转化
2、某用户在这个时间限制范围内,依次触发了 A > B > D,则该用户没有完成该漏斗的转化,并且会被记作步骤 B 的流失用户
3、在该时间范围内,即使一个用户多次完成漏斗,也仅计数一次
筛选
筛选规则:以每个用户YY属性的首次有效值进行筛选
筛选含义:对完成转化/确认流失的用户,再进行二次挑选,细分每一属性的转化/流失
FAQ:
1、漏斗内的筛选条件和漏斗外的筛选条件的区别:漏斗内的筛选条件是根据
设置的条件
得到漏斗,漏斗外的筛选条件是根据得到的漏斗筛选出
满足筛选条件
的漏斗
2、漏斗强制刷新人数会变化
(1)若仅第一次刷新时,数据有变化,多次刷新后人数不再变化,则是因为神策查询的缓存机制导致,以刷新后的数据为准。
(2)若多次刷新人数都会变化,通常是因为漏斗相邻事件时间一样,导致的排序不稳定。可以让对应事件的埋点同学调整下事件上报时机,保证两个事件时间不同即可。如果非上述原因导致可联系神策值班同学。
3、漏斗内某事件的人数和事件分析的触发用户数不一致
(1)漏斗内第一步对应的人数与事件分析查询的触发用户数不一致:可能是漏斗查询时,在漏斗外添加了筛选条件,导致和事件分析中对应筛选条件下人数不一样。可以将筛选条件添加在漏斗内,再对比下查询的数据。如果筛选条件放在漏斗内之后,查询的结果和事件分析一致,则说明查询结果正常。具体原因可参考问题 1 的漏斗内和漏斗外筛选条件的区别。
(2)漏斗内非第一步事件与事件分析的触发用户数不一致:属于正常数据,因为漏斗内的某事件人数是满足漏斗规则后筛选出的人数,比如漏斗规则为 A->B->C,事件分析中 B 事件用户数为 100,漏斗分析中先触发 A 事件再触发 B 事件的用户数为 20。
4、漏斗按天转化率没有总体转化率高
举个例子,比如 11.01-11.03 这 3 天里有 3 个人,漏斗规则为 A->B->C, 11.01 三个人都触发事件 A ,但只有第一个人在窗口期内完成 B->C 转化;11.02 三个人都触发事件 A 但只有第二个人在窗口期内完成 B->C 转化 ; 11.03 三个人都触发事件 A 但只有第三个人在窗口期内完成 B->C 转化。按天分布的话,11.01 的转化率为 33%,11.02 的转化率为 33%。11.03 的转化率为 33%。按总体看,11.01-11.10 这 10 天的转化率为 100%
5、总体转化率没有漏斗按天转化率高
举个例子:,比如 11.01-11.02 这 2 天,漏斗规则为 A->B->C,第一天,a b c 三个人触发了事件 A ,b c 两个人在规定窗口期内完成 B->C 转化,转化率 66.6%。
第二天,b c d e 四个人触发了事件 A,b c 两个人在规定窗口期内完成 B->C 转化,转化率 50%。
总体,abcde五个人访问,bc下单,转化率 40%。
留存分析
定义:分析用户参与情况/活跃程度的分析模型
用途:衡量产品对用户价值高低的重要指标
配置:选择初始行为和后续行为 | 设置筛选条件 | 添加同时显示 | 用户筛选条件 | 设置关联属性
初始行为和后续行为的选择策略:
1、用于对比分析不同阶段开始使用产品的新用户的参与情况,从而评估产品迭代或运营策略调整的得失
2、二者选择相同的,期待用户重复触发的事件。这种留存用于分析忠实用户的使用模式
关联属性:初始行为和后续行为的属性进行关联。不同事件关联的属性可以是相同属性,也可以是不同属性,但是要求属性的类型必须一致
留存/流失设置:
筛选条件:用户筛选、条件筛选
算法:
FAQ:为什么要做留存分析?看活跃用户百分比不够吗?
按初始行为时间分组的留存分析可以消除用户增长对用户参与数据带来的影响。
如果产品目前处于快速增长阶段,很有可能
新用户中的活跃用户数增长掩盖了老用户活跃度的变化
。
通过留存分析,你可以将用户按照注册时间分段查看,得出类似如下结论:“三月份改版前,该月注册的用户 7 天留存只有 15%;但是四月份改版后,该月注册的用户 7 天留存提高到了 20%。”
同理,按照非时间维度的留存分析具有类似价值,比如,可以查看新功能上线之后,对不同性别用户的留存是否带来不同效果。
我们在分析用户的留存时,一定要根据实际的业务需求,找到有价值的后续行为,对用户的价值留存进行分析,才能对产品的优化和改进提供实质性指导建议。
(用户)属性分析
路径:属性分析>显示:用户数
FAQ:
1、用户属性分析的用户数和在“行为事件分析”模块中查看“任意事件”的用户数不一致
在 sdk 中仅仅 track 了事件数据,而没有为这个用户设置任何 profile 信息,则此用户不会出现在“用户属性分析”功能中
2、可否按照用户接入的时间顺序筛选用户?
用户属性中,默认情况下不会有时间属性,如果需要按接入时间查看,需要在埋点时,记录下时间类属性,然后依据该属性进行分析。
界面操作
按分组(维度)查看:数值型可自定义区间
添加筛选条件
显示设置:选择分组、选择线图/柱图/饼图、选择不同维度
点击数字可查看用户画像、用户列表、添加分群
用户列表
路径:分析模型按「用户数」的分析结果,和用户分群的列表详情页均可查看
对于「加密显示」的「用户属性」将会以脱敏显示
列目显示:自定义用户列表中常用的用户信息,可增删、拖动固定
保存分群:快速将当前的用户群体保存为一个分群,以便在分析中直接使用
下载:按照当前所选取的用户属性将此批用户的信息下载下来。
用户行为序列
路径:点击列表中任意单个用户可获取用户的历史行为记录
行为序列的锚点
通过“事件分析”进入,锚点是满足筛选和分组条件下,分析目标的那个事件
通过“漏斗分析”进入,转化用户锚点是完成转化的那一系列关键事件;流失用户锚点是上一步转化的那一系列关键事件
通过“留存分析”进入,锚点是留存分析中满足筛选和分组的后续行为
通过“分布分析”进入,锚点是选定的时间区间内,满足筛选和分组的事件
行为概览:支持对事件和时间区间的设置
行为列表
按明细加载、按小时加载
其他操作
1、单击事件可查看详细信息,
2、可设置最多3个外显属性,
3、过滤相同属性,可隐藏该类事件的展示
典型应用场景
https://manual.sensorsdata.cn/sa/latest/guide_analytics_users_sequence-17567156.html#id-.用户行为序列v1.17-典型应用场景
session分析
配置:元数据>session管理>创建session>设置名称、事件、时间>保存,事件分析>分析规则:session
用途:常用于分析访问次数、交互深度、使用时长、停留时长、跳出率、页面退出率
Session分析方法:
https://www.sensorsdata.cn/blog/ru-he-ying-yong-sensors-analytics-jin-xing-session-fen-xi/
同时并发人数
用途:计算某时间点同时会在的会话数
算法:某个时间点有多少个会话同时在线
应用场景:通过并发人数最多的时间点分析出在线人数最多的时间段,推送活动,达到最佳效果
session切割
算法:以第一个I行为作为起点,向后匹配
1、若匹配到的是一个「开始事件」:那么会自动切断会话;以这个「开始事件」作为起点;
2、若匹配到的是一个「结束事件」:那么会将这个「结束事件」划入到当前会话中;以「结束事件」的下一个事件作为起点;
3、若在切割时间内没有匹配到任何事件:那么就会自动切断会话;以下个事件作为起点
应用场景:开始和结束事件;频行业「开始播放」和「结束播放」;移动端「APP 启动」和「APP 退出」;一次转化路径「首页」到「支付」
分布分析
概述:前身是回访分析
用途:可用于分析用户依赖产品的程度,以及某个事件指标的用户分布情况(每个区间的分布)
配置:用户行为>指标 | 筛选条件(事件细分|用户细分)| 时间单位 | 自定义分组区间(齿轮标识)
算法
按时间段统计:统计用户在一天/周/月中,有多少个自然时间段(小时/天)进行了某项操作
(如某用户在 15:00 到 16:00 『点击广告』3 次,17:00 到 18:00 『点击广告』1 次,则统计为『一天至少在 2 个时段进行点击广告』, 用户在某小时内进行『点击广告』一次或多次,都记 1 次)
按次数统计:统计用户在一天/周/月中,进行某项操作的次数,发生一次就记录一次
按事件属性的统计指标:统计用户在一天/周/月中,发生事件的某属性的统计指标值。
属性的统计指标与事件分析一致,有总和、均值、最大值、最小值、去重数
FAQ:分布分析比单看日活(DAU)优越在哪里?
日活只能告诉你用户数的变化,分布分析却能揭示单个用户对产品依赖程度的变化。
比如某产品虽然三月和四月期间活跃用户量没有明显增长,但是用户关键行为(比如下单,或发布内容)的频率却显著增加,说明产品对于用户的价值增加了。反之,如果虽然日活增长很快,但是行为发生频率却在相比之前较低的水平,很有可能新增加的活跃用户并未真正感受到产品价值。
APP点击分析
功能:主要用来分析用户在 APP 上的点击情况
连接APP
iOS集成SDK配置
https://cf.sensorsdata.cn/pages/viewpage.action?pageId=1573998
Android集成SDK配置
https://cf.sensorsdata.cn/pages/viewpage.action?pageId=7538650
操作界面说明
APP 点击热力图
分组:最多4个分组
事件筛选
其他:点击断开连接后手机 APP 不再上报信息;点击同步按钮切换状态,开启时可以同步手机状态到页面上,关闭后不能同步
分析图:支持线图、柱图、饼图
指标
触发用户数uv:该按钮点击的触发用户数
总次数PV:元素点击的总次数
点击率:该按钮的点击次数 / 当前页面的访问次数
点击比:该按钮的点击次数 / 该页面下所有按钮点击总次数
FAQ:热力图与图表数据不能完全匹配?
APP 点击热力图上的元素是按照 $element_selector 来唯一标记的,所以可能会出现热力图与图表数据不能完全匹配的情况
归因分析
功能用途:分析某个广告位、推广位对目标事件的转化贡献
相关概念:
「待归因事件」:在归因分析模型中,广告位的点击、推广位的点击
「目标转化事件」:支付订单等目标类事件
组成
归因事件与模型选择区
目标转化事件
一般为与收益相关的事件;支持全部元事件;
高级设置:(提升精度)
前向关键事件:一般选择与目标事件有强关联的事件,类似商品曝光;
关联属性:将目标转化事件和前向关键事件进行关联的属性
待归因事件:一般为与广告曝光、推荐曝光等运营相关事件;支持全部元事件
归因模型
首次触点模型:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为第一个「待归因事件」功劳为 100%
末次触点归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为最后一个「待归因事件」功劳为 100%
线性归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为每个「待归因事件」平均分配此次功劳
位置归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为第一个和最后一个「待归因事件」各占 40% 功劳,其余「待归因事件」平分剩余的 20% 功劳
时间衰减归因:多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为越靠近「目标转化事件」做出的贡献越大
因结果表格展示区
支持「目标转化事件」的指标切换
指标解释
总点击数:在选择的时间范围内(额外增加上窗口期),该广告位的总点击数量
有效转化点击率:在选择的时间范围内(额外增加上窗口期),与本次的目标转化有关联的广告点击。
比如:设置目标为支付订单,回溯时长为 1 天,若 3 日前点击了广告,则不会被判定为有效转化。
概念:以一个行为的完成为目标,按照某种计算规则向前回溯前序行为对此目标的功劳分配
间隔分析
功能:通过计算用户行为序列中两个事件的时间间隔,得到业务转化环节的转化时长分布,进一步衡量转化
界面功能说明
初始行为和后续行为
不同事件
示例:
互金产品:注册成功->投资成功
电商产品:添加购物车->提交订单
功能:用于分析业务流程中用户转化花费的时长,侧面反应转化意愿,从而针对性的优化产品体验及运营策略
相同事件
功能:分析用户两个时间间隔时长,作为运营策略指定的参考
示例:
在线教育类产品:用户 2 次上课之间的时间间隔->对学习的积极性
电商类产品:用户重复购买日用品的时间间隔->预测下一次购买的时间点,精准推荐
筛选条件:根据用户属性,筛选出想要的分析对象
按属性分组
按初始行为属性分组
按后续行为属性分组
按用户属性分组
聚合时间单位:按天、按周、按月,无按小时
设置关联属性
不同事件关联的属性可以是相同属性,也可以是不同属性,但是要求属性的类型必须一致
示例:某电商开展了一个营销活动,除了监测用户从商品详情页到完成商品购买的行为流向,还需要精确定位该用户的行为是和本次营销活动相关。因此需要在浏览商品详情页和支付完成事件中添加营销活动 ID 的属性,此时就可以将该属性作为关联 ID ,以保证用户严格按照该模式配对
分析结果指标
箱型图
最小值:间隔转化时长的最小值
中位数:将间隔转化时长按从大到小排期,取中间值
上四分位:将间隔转化时长按从大到小排期,取 1/4 处的值
下四分位:将间隔转化时长按从大到小排期,取 3/4 处的值
平均值:间隔转化时长的总和 / 转化用户数,
不同于人均转化时间,一人可能有多次间隔转化,平均值把这些都加总,所以稍大
最大值:间隔转化时长的最大值
人均转化时间:每个人的平均间隔时长总和 / 转化用户数。
间隔数:选定时间范围内,完成间隔转化的配对数(下载数据中的字段)
转化用户数:在选定的时间内完成了间隔转化人数,一个人可能会完成多次间隔转化
人均间隔数:间隔数 / 转化用户数(下载数据中的字段)。
间隔转化时长:选定时间范围内,完成间隔转化的每个配对的时间差
配对算法
不考虑时间
分析用户做了 A 事件和 B 事件的时间间隔,
间隔配对结果是:
A
→ C → A →
B
→ B →
A
→
B
→ B →
A
→ A → D →
B
考虑聚合时间
按天聚合,
用户发生A 事件 的时间是 23:50 ,发生 B 事件的时间是次日 00:10 。这两个事件无法完成配对
应用场景
互金产品:注册成功->投资成功
电商产品:添加购物车->提交订单,复购
短视频行业:启动 App->完成播放
FAQ:时间间隔和页面停留时长有什么区别?为什么不能用间隔分析的功能分析页面停留时长?
假设注册流程包括手机号注册,填写基本信息,实名认证 3 个事件。 填写基本信息 与 实名认证的时间间隔并不是用户在基本信息页的停留时长。因为用户在发生填写基本信息和实名认证 2 个行为之间,可能含有其他操作。而一旦触发了填写基本信息和实名认证,即可利用「间隔分析」来计算
用户路径分析
功能:用于分析用户在使用产品时的路径分布情况
设置查询条件
添加分析事件
优先分流计算策略
若虚拟事件和其包含的元事件都在参与事件中,则该元事件按照(起止事件、虚拟事件、元事件)优先级进行归属。
若多个虚拟事件包含相同的元事件,则该元事件按照事件筛选列表顺序归属于第一个虚拟事件。
若参与事件选择了虚拟事件,则会直接展示为虚拟事件。
支持多事件分组
设置起始或者结束事件
设置session间隔
设置时间区间:支持相对时间和绝对时间
可视化分析结果
以桑基图形式展现,以目标事件为起点/终点,详细查看后续/前置路径,可以详细查看某个节点事件的流向,基于性能考虑,
初始只最大展示四级路径,点击右下角可以逐层添加展示层数。
同时支持一键导出「桑基图分析结果图片」
高亮显示路径:单击需要高亮路径>突出节点路径
查看节点详情:单击需要高亮路径>查看节点详情
网页热力分析
功能:主要用来分析用户在网页上的点击、触达深度等情况
点击图说明
显示内容
原始页面:用来分析单个页面的点击情况
页面组
功能:用来分析一系列界面结构相似的网页整体的浏览和点击情况
新建步骤:新建页面组>定义页面组名称>背景页面>添加背景页面中嵌套的页面url>保存
筛选条件
事件筛选:注意点击分析的筛选条件是事件 Web元素点击 和 Web浏览 的公共属性
用户符合
指标
浏览量PV,即事件 Web浏览页面 的总次数
用户数,页面的上各个交互元素的点击 UV,即事件Web元素点击 的触发用户数。
点击次数,页面上各个交互元素的被点击次数,即事件 Web元素点击 的总次数。
点击率:点击次数 / PV
点击占比:点击次数/页面内所有可见元素的总点击次数
历史内容:表示取这个按钮历史最常出现的值
点击用户列表:查看点击过这个按钮的具体用户是哪些人
切换方案:查看不同版本的点击图的数据差别
触达率图说明
有效停留:关注网页区域不滚动,期间鼠标可以移动,可以点击等操作
有效停留时间:停留时间超过规定的时间,javascript sdk默认为4 秒
触达率
用途:用于分析如详情页、着陆页等类型页面中用户的浏览深度,帮助优化页面的内容、结构的设计
概念:在当前筛选条件下,最终到达网页中某个位置的用户的比例
高级功能
切换时区分析
相关概念
显示时间:日常看到的时间,是根据所处时区,通过某个规则进行定义,方便日常生活使用的时间
客户端(显示)时间:以用户当时客户端的时区作为依据,将物理时间转化成显示时间
服务端(显示)时间:以服务端人工配置一个固定的时区为依据,将物理时间转化成显示时间(将各时区收集到的数据转化为服务端所在时区的时间,统一管理)
物理时间:unix 时间戳,从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数,不考虑闰秒
配置方法
总设置:基本设置>分析模型设置>时区设置
分析模型中,时间设置处多出时区设置按钮,直接切换
局限性
非默认时区时,运算速度都会变慢
查询条件中涉及到日期类型的用户属性计算结果可能会不准确
切换主体分析
概念:神策的分析模型是【Event-User】模型,其中的 User(用户)就是分析的主体,用于串联起一连串的 Event(事件),形成用户的行为序列
使用场景与客户
1、工具——除了按照用户(人)的角度去分析业务数据,也想要按照设备的维度,去看产品的使用与留存
2、证券——同一用户名下有多个资金账号,只能通过上报公共属性的方式进行账号筛选,但在神策系统中无法按照资金账号进行计数与分析;如果能够切换分析主体,就能实现想要的分析效果
3、电商/电视购物——同一个用户,在集团视角和业务视角身份不同,意味着同一个人在环境中具备不同的身份
4、游戏——这个与证券用户相近,同一个游戏用户的账号下,存在创建多个游戏角色的场景
配置方法
总设置:基本设置>分析主体设置>新建,把事件属性设置为可分析的主体,支持 string 和 number 类型的属性
配置思路:通过实名认证id作为分析主体,把账号id当做事件属性在埋点的时候上报即可
分析模型中:模型右上角会出现分析主体选择,选择经过 ID-mapping 之后的用户 ID(默认)
应用场景
分布分析
金融行业:根据开户的账户维度查看同一个自然人的不同账户的交易金额分布
游戏行业:根据设备/角色维度查看角色的等级、充值金额的属性分布
留存分析
游戏行业:同一用户,可能会创建多个角色,每个角色的留存情况是怎么样的?是否有的留存了,有的不玩了
漏斗分析
电商行业:分析一个商品的流转情况,把商品作为主体,看商品从进库存、展示、销售、然后物流再到最后的售后的漏斗情况
局限性
当选择自定义的分析主体,并且按照用户属性/用户分群/用户标签查看分布数据时,可能会导致计算不准确的情况
使用默认的分析主体时,支持查看用户画像,添加用户分群;
使用自定义的分析主体时,无法查看用户画像,也不支持添加用户分群
自定义查询
数据表
事件表
包含了所有事件的详细信息(不包括虚拟事件),该表的每一行代表一个 track 的 Event
字段分为特殊字段和 Event 本身的 Property 两大类
特殊字段
event,事件的名称
user_id,神策分析为该用户分配的内部 ID,与 user 表的 id 字段相关联
distinct_id,用户的原始 ID,track 时传入,可能是一个匿名 ID 或 登录 ID
date,事件发生的日期,属于特殊字段,上传数据时无需上传 date字段
time,事件发生的具体时间,时分秒
$receive_time,服务器接收到事件时的具体时间戳。该字段可以在自定义查询中显示,
在前端的分析模块中,所有事件都无法使用该字段分析数据,因为 $receive_time 默认不会与任何事件绑定。
用户表
每一行代表一个 User,类似于事件表
字段分为特殊字段和 User 的其它 Profile 两大类
特殊字段
id,神策分析为该用户分配的内部 ID,与 events 表的 user_id 相关联
first_id,该用户的匿名 ID,与 events 表登录前行为的 distinct_id 相关联。
特别注意,用户 first_id 等于 second_id,说明该用户没有成功关联到匿名 ID,相当于未知
second_id,该用户的登录 ID,与 events 表登录后行为的 distinct_id 相关联
$update_time,该用户最近一次更新用户表信息的时间戳
$device_id_list,开启多对一关联机制时,会记录与登录 ID 关联的匿名 ID 列表,以及关联时的时间戳
Session表
每张 Session 表都对应一个 Session 的配置,
命名规则为:sessions_${session_name}
除了包含 events 表包含的字段,还包含 session 属性和 session 相关的特殊字段
命名规则是原始的属性名加上后缀 $session
特殊字段
$session_id,标示一个 session 的唯一 id
$session_position,标示一个 session 中事件的索引,从 0 开始,依次递增。
$session_event_duration,session内事件时长,表示session相邻两个事件发生的时间间隔,单位是秒,最后一个事件的事件时长是 null
$session_duration,session内最后一个事件触发的时间减去 session 内第一个事件触发的时间,单位是秒
$session_depth session 深度,表示 session 内触发事件的次数 4
$event_id$session,Session 内第一次触发的事件
局限性
计算量较大,使用时必须加上时间注解
SELECT event, user_id, distinct_id, date FROM sessions_default /
SESSION_TABLE_DATE_RANGE=[2018-01-01,2018-01-05]
/
暂不支持使用 select * 查询 SESSION 表,查询需加具体的字段名
用户分群/标签表
命名规则(≥1.14版)
分群:user
group
${user_group_name}
标签:user
tag
${user_tag_name}
具体字段
user_id,用户 id
distinct_id,与事件表中的 distinct_id 相关联
values,用户分群/标签值
base_time,用户分群/标签计算的基准时间,以毫秒形式进行的存储,1.14 版本之后新增
可以使用以下语法将日期转化成毫秒数Timestamp进行查询
SELECT * FROM user_group_fenqun9 WHERE base_time=unix_timestamp_ms('2019-01-17 00:00:00')
Items表
$item_type,item 表的类型
$item_id,表示 item 的 id
$is_valid,该 item 是否有效,不传入默认为 true
$receive_time,该item到达时间
$update_time,该item的更新时间,不传入默认为写入时间
数据类型
数值Number
不区分浮点数与整数,输出时根据是否有小数位自动转换输出格式
字符串String
日期Date
注意:time 字段特殊,不需要经过转换即可直接使用
在自定义查询中表现为 毫秒级的 Timestamp,可使用EPOCH_TO_TIMESTAMP($signup_time / 1000)转换为为 Timestamp 类型
条件过滤:SELECT COUNT(*) AS cnt FROM users WHERE EPOCH_TO_TIMESTAMP($signup_time / 1000) > '2017-01-01';
日期时间Datetime
也可使用EPOCH_TO_TIMESTAMP转换
布尔Bool
使用0/1表示False/True
列表List
支持在 Where 条件里使用 CONTAINS 函数或者 LIKE 函数来进行过滤操作
SELECT FavoriteFruits from users where CONTAINS('橘子', FavoriteFruits);
可以使用 /
EXPLODE_LIST_COLUMN=${table.columnName}
/ 注解来将 List 类型数据打散成多行 string 类型数据
SELECT list_property FROM events /
EXPLODE_LIST_COLUMN=events.list_property
/
功能使用
基本功能
查询每天的事件总数
SELECT date, COUNT(*) from events GROUP BY 1 ORDER BY 1
前端展示的结果最大只有 1k 条,而 CSV 下载的结果最大是 100w 条
日期过滤
注意,任何时候应当尽量使用date字段进行过滤,而不是time字段
CURRENT_DATE() 函数,返回当天
CURRENT_WEEK() 函数,返回当周的周一
CURRENT_MONTH() 函数,返回当月的1号
INTERVAL 表达式,
CURRENT_DATE() - INTERVAL '1' DAY 表示昨天
CURRENT_MONTH() - INTERVAL '1' MONTH 表示上月1号
CURRENT_MONTH() - INTERVAL '1' DAY 表示上个月最后一天
常用函数
Impala函数
https://docs.cloudera.com/documentation/enterprise/latest/topics/impala_functions.html
时间日期函数
adddate()
adddate(timestamp startdate, int days)
adddate(timestamp startdate, bigint days)
用途:在一个TIMESTAMP(时间戳)值上加一个给定的天数
参数:
startdate:timestamp类型的开始时间戳
days:需要加上的天数,正数表示几天之后,负数表示几天之前
返回值:加上天数之后的时间戳,timestamp类型
datediff()
datediff(timestamp enddate, timestamp startdate)
用途:返回两个时间戳间隔天数
参数:
enddate:结束时间
startdate:开始时间
返回值:结束时间减去开始时间的天数,int类型。
开始时间>结束时间->负数;
开始时间<结束时间->正数
extract()
extract(unit FROM timestamp)
extract(timestamp, string unit)
用途:从TIMESTAMP值中截取数值型的时间域,例如年度,月份,日期,小时,分钟,秒/微秒
参数:
unit:时间单位unit字符串可取的值有:year,month,day,hour,minute,second,millisecond。
返回值:时间域的整型值
trunc()
trunc(timestamp, string unit)
用途:从给定的timestamp时间戳截取时间域
参数:unit:时间单位
年度:SYYYY, YYYY, YEAR, SYEAR, YYY, YY, Y
季度:Q
月份:MONTH, MON, MM, RM
周一:WW, W
日期:DDD, DD, J
周一:DAY, DY, D
小时:HH, HH12, HH24
分钟:MI
返回值:截取时间域之后的日期
字符串函数
concat()
concat(string a, string b…)
用途:把所有string类型的参数连接成一个string类型
参数:
string(不限个数):要连接的字符串
返回值:一个整体的字符串
regexp_like()
regexp_like(string source, string pattern[, string options])
用途:判断source字符串中是否包含以pattern为正则表达式的内容
参数:
source:要检查的字符串
pattern:正则表达式
option(选填):选项
c:区分大小写
i:不区分大小写
m:匹配多行,^和$操作符对于每一行都会匹配,而不是对多行为整体的开头和结束
n:新行匹配,点(.)操作符会匹配新行。
返回值:匹配与否,boolean类型
parse_url()
parse_url(string urlString, string partToExtract [, string keyToExtract])
用途:通过指定URL中的特定部分返回截取值
参数:
urlString:URL
partToExtract:要截取的部分。可指定的值为'PROTOCOL', 'HOST', 'PATH', 'REF', 'AUTHORITY', 'FILE', ‘USERINFO', ‘QUERY'
PROTOCOL:协议,如HTTP,HTTPS,FTP等
HOST:主机名
PATH:路径
REF:锚点(“又称引用”),即URL中#后面的字符串
AUTHORITY:授权
FILE:文件名
USERINFO:用户信息
QUERY:查询参数,即URL中?后面的字符串
keyToExtract(选填):当partToExtract为’QUERY’时,可以指定query键值对中的key,获取指定参数值
返回值:URL中指定部分的截取值
数学函数
pow()、power()、dpow()、fpow()
参数:a:底数 b:指数
用途:取幂
pow(double a, double p)
power(double a, double p)
dpow(double a, double p)
fpow(double a, double p)
返回值:a的b次幂
round()、dround()
参数:
a:要四舍五入的数值
d(可选):小数保留位数,若无此参数,保留到整数部分
用途:返回四舍五入值
round(double a)
round(double a, int d)
round(decimal a, int_type d)
dround(double a)
dround(double a, int d)
返回值:四舍五入值
truncate()、dtrunc()
truncate(double_or_decimal a[, digits_to_leave])
dtrunc(double_or_decimal a[, digits_to_leave])
用途:去除小数部分的数值
参数:
a:被截取的数值
digits_to_leave(可选):小数点保留位数,若无此参数,保留到整数部分
返回值:被截取的值
高级选项
开启快速 Distinct 算法
SELECT COUNT(DISTINCT user_id) FROM events
WHERE date = CURRENT_DATE() /
ENABLE_APPROX_DISTINCT
/
开启维度字典映射和维度表关联,默认关闭
SELECT $model FROM events
WHERE date = CURRENT_DATE() /
ENABLE_DIMENSION_DICT_MAPPING
/
查询某个指定 Distinct Id
SELECT event, time FROM events
WHERE date = CURRENT_DATE() AND distinct_id='abcdef' /
DISTINCT_ID_FILTER=abcdef
/
SQL 默认在执行 10 分钟之后会被系统强制杀死,修改时间
SELECT
FROM events WHERE date = CURRENT_DATE() LIMIT 1000 /
MAX_QUERY_EXECUTION_TIME=1800*/
使用Join Hint指定Join的执行方式:SHUFFLE或BROADCAST
SELECT COUNT(
) AS cnt FROM events
JOIN /
+SHUFFLE */ users ON events.user_id = users.id
WHERE date = CURRENT_DATE()
常见案例
https://manual.sensorsdata.cn/sa/latest/guide_analytics_query-7543929.html#id-.自定义查询v1.17-常见案例