关于可视化:可视化全埋点系列文章之功能介绍篇

7次阅读

共计 3629 个字符,预计需要花费 10 分钟才能阅读完成。

1. 什么是可视化全埋点

1.1. 全埋点

在介绍可视化全埋点之前,先理解一下全埋点。

全埋点,也叫无埋点、无码埋点、无痕埋点、主动埋点。全埋点是指无需利用程序开发工程师写代码或者只写大量的代码,即可事后主动收集用户的所有或者绝大部分的行为数据,而后就能够依据理论的业务剖析需要从中筛选出所需行为数据并进行剖析 [1]。

神策剖析 iOS SDK 目前反对的全埋点事件有:App 启动、App 退出、元素点击、页面浏览。只须要客户开发人员依照正确的形式集成,而后初始化 SDK 并开启相干配置,即可在对应的事件触发时,主动采集事件和相干属性。

1.2. 可视化全埋点

1.2.1. 可视化全埋点事件

可视化全埋点事件,即通过可视化的形式把某些全埋点事件,创立成一个重新命名的虚构事件 [2],从而咱们能够从已采集的数量宏大的全埋点事件中疾速筛选到咱们所关怀的事件。

思考到理论的利用场景,目前神策剖析的可视化全埋点,反对元素点击和页面浏览事件。例如:App 的增加购物车按钮,在点击的时候会触发一个名为 “$AppClick” 的全埋点事件,并采集按钮元素和以后页面的相干信息。尽管“增加购物车”按钮点击触发了 “$AppClick” 事件,然而这个事件实际上蕴含了以后 App 内的所有元素点击触发的事件。因而,很难独自剖析“增加购物车”按钮在某一段时间内的点击次数或地区散布等信息。

1.2.2. 自定义属性

可视化全埋点的自定义属性,其实就是通过可视化的形式将以后事件相干的属性信息增加下来。例如点击“增加购物车”按钮,触发 “$AppClick” 全埋点事件的时候,将以后商品名称、价格、配置信息等,作为事件属性进行采集。

思考实在商业我的项目中,商品详情等信息是通过网络申请到数据,而后异步进行渲染的,因而在触发页面浏览事件的时候,可能页面数据信息尚未渲染实现或者显示缺省值,也就是说无奈采集页面最终的显示信息,所以页面浏览事件如果反对自定义属性,可能很多场景下采集不准。因而目前可视化全埋点自定义属性,只反对元素点击事件。

另外,目前自定义属性,采集元素内容的同时,还反对规定解决。例如能够将内容取整、取前几个字符、只取数值等,同时也反对写正则表达式,满足更多的理论利用场景。

1.2.3. 整体流程

可视化全埋点的整体流程如图 1-1 所示:

图 1-1 可视化全埋点整体流程图

2. 为什么须要可视化全埋点

上一节简略介绍了可视化全埋点的含意和整体流程,可能大家依然会有疑难:既然有了全埋点,为何还须要可视化全埋点?

2.1. 晋升埋点效率

其实,可视化全埋点的实质就是依据一系列的筛选条件创立虚构事件。

如果不应用可视化全埋点去剖析特定的全埋点事件,就须要依据全埋点事件名称以及相干属性的特色,针对性地创立虚构事件或者组合筛选条件进行查问。从过程可想而知十分消耗工夫,对于想要查看后果的剖析人员而言,这种繁琐的工作重大影响工作效率。

如果应用可视化全埋点(通过可视化的形式在前端页面简略地进行抉择和命名)即可剖析特定的事件或属性,这样极大地提高了埋点效率。使得剖析人员不用将太多的工夫消耗在埋点上,能够更多地专一于产品剖析和前期决策。

2.2. 升高埋点门槛

应用可视化全埋点,可能在没有开发人员参加的状况下,剖析特定的用户行为和相干属性信息。使得不相熟技术实现的剖析人员,也能疾速高效地埋点,从而极大地升高了埋点门槛。

2.3. 不便迭代

在设计埋点事件时,难免会脱漏某些重要场景的事件采集。在传统的采集计划下,咱们只能在 App 中从新埋点并发版。上线一段时间后,能力失去咱们须要剖析的数据。

可视化全埋点是基于全埋点创立的虚构事件,因而咱们不须要这些简单的过程,就能够在神策剖析平台进行事件定义,并且反对回溯剖析。使得剖析人员不依赖某些特定版本即可分析线上所有全埋点事件的数据,即可在版本迭代的过程中,也能采集到版本前后的残缺数据,从而满足剖析需要。

因为可视化全埋点是通过虚构事件创立的“埋点事件”,如果咱们不小心删除了,能够再次创立这个“埋点事件”。另外,历史数据不会删除。这样大大降低了设计脱漏带来的工夫老本和“事件失落”的影响。

2.4. 实用场景

在埋点自身品质上,代码埋点是要远优于可视化全埋点的,然而可视化全埋点在埋点老本和回溯历史方面有着无可比拟的劣势。对于满足如下情景的客户来说,可视化全埋点能够在晚期更好地实现数据驱动:

没有研发资源或研发资源很少;

我的项目较为晚期,以交互剖析为主,业务剖析为辅;

须要剖析的大部分是流动类页面,剖析诉求次要是挪动端。

代码埋点和可视化全埋点,是神策剖析提供给不同阶段的客户的两种埋点办法。从建设更松软的数据根基的角度来说,首推代码埋点,然而如果面向一些短平快的剖析诉求,能够思考应用可视化全埋点。

3. 如何应用可视化全埋点

3.1. 进入可视化全埋点

3.1.1. 集成 SDK

在开始可视化全埋点之前,须要正确集成并初始化神策剖析 iOS SDK,而后开启可视化全埋点,详见文档阐明:开启可视化全埋点 [3]。

3.1.2. 进入埋点页面

登录神策剖析的后盾环境,进入元数据管理模块,开始进行可视化全埋点。如图 3-1 所示:

图 3-1 可视化全埋点的入口

3.1.3. 扫码连贯

在神策剖析页面抉择扫码连贯,进入扫描二维码的页面。如果应用 iPhone 倡议间接应用零碎自带的二维码扫描性能进行扫码,而后跳转到 Safari 关上页面;Android 手机能够应用浏览器的扫一扫性能或者是微信扫一扫的性能进行扫码,依据浏览器弹窗提醒的操作关上对应的 H5 页面;
手机扫码后点击 H5 页面中的「开启 App 可视化全埋点」按钮,再点击「关上」按钮后胜利关上所要剖析的 App;
连贯 App 胜利后可进行可视化全埋点。
扫码连贯的过程如图 3-2 所示:

图 3-2 扫码连贯示意图

3.2. 定义事件

3.2.1. 定义元素点击事件

进入可视化全埋点后,能够定义元素点击事件。选中某个可点击元素后,如图 3-3 所示:

图 3-3 选中可点击元素

能够看到限定条件如下:

不限定内容(文本);
限定程序为第「3」位。
下面两个条件意味着:产生在「以后页面」下,同类元素内,在列表中程序地位为第「3」位的元素点击事件。若元素的内容(文本)变动,埋点依然无效。

相应的,限定特定内容的元素点击事件如图 3-4 所示:

图 3-4 限定特定内容的元素点击事件

变换一下条件,能够看到限定条件如下:

限定内容(文本);
不限定程序地位。
下面两个条件意味着:产生在「以后页面」下,同类元素内,内容(文本)为「生存旅行」的元素点击事件。元素程序变动,埋点依然无效。元素内容(文本)变动,埋点生效。

此外,依据是否限定元素内容和元素地位进行组合。还能够满足下述场景:

定义某个特定内容、特定地位的元素;
定义整个列表按钮(不限内容、不限地位即可)。
须要留神的是:限定地位性能,只反对列表元素,或列表内嵌子元素。

3.2.2. 定义页面浏览事件

点击「创立页面浏览事件」按钮,在弹窗页面中,确认事件名称并点击保留即可。如图 3-5 所示:

图 3-5 创立页面浏览事件

3.3. 自定义属性

除了定义事件,还能够在页面中抉择元素内容定义为该事件的属性信息,具体步骤如下:

  1. 在创立元素点击事件页面中点击「增加属性」按钮,如图 3-6 所示:

图 3-6「增加属性」按钮

2. 点击页面中的元素,并保留属性信息,如图 3-7 所示:

图 3-7 保留属性信息

3. 保留后进行确认创立事件,如图 3-8 所示:

图 3-8 创立事件

增加属性后,点击「立刻购买」按钮触发 “$AppClick” 全埋点事件时,也会依照内容解决规定,采集 “product_price”(商品价格)这个属性。

4. 可视化全埋点局限性

尽管可视化全埋点有很多长处,然而也不是万能的,可视化全埋点也有其本身的局限性。

4.1. 局部事件和属性暂不反对

一些特定的元素点击事件,因为目前全埋点暂不反对采集,所以可视化全埋点也无奈反对。例如:零碎键盘上的切换输入法等按键的点击。

此外,某些业务相干的信息,可能不在页面中显示,目前自定义属性也无奈反对。例如:商品的库存信息、商品 ID、历史价格等。

4.2. 自定义属性不反对回溯

尽管元素点击和页面浏览的可视化全埋点事件反对回溯,然而可视化全埋点自定义属性并不反对。这是因为在创立属性后才开始采集,即创立自定义属性之前的可视化全埋点事件是不蕴含该属性的。

5. 总结

本文是可视化全埋点系列文章的第一篇,次要介绍了可视化全埋点的相干概念和应用形式,旨在帮忙大家对于可视化全埋点有一个整体的理解,后续会对可视化全埋点的具体实现进行逐渐地介绍。

最初,欢送大家退出开源社区一起探讨。

6. 参考文献

[1] 王灼洲.iOS 全埋点解决方案 [M]. 北京: 机械工业出版社,2020:162-197.

[2]https://manual.sensorsdata.cn… 虚构事件 -22253779.html

[3]https://manual.sensorsdata.cn…

正文完
 0