统计埋点的那些事

144
作者 chenkai
2016.04.14 19:29 字数 3273

早上来跟Li无意中聊到国内的一家基于用户行为进行产品数据分析工具Growing IO时,在其首页的产品feature说明中,首先提到通过“无埋点”方案实现用户行为的数据采集。我当时看到不需要前端在代码中进行任何埋点,就能拿到用户行为的统计数据,很是疑惑这种所谓的“无埋点”方式是通过什么原理进行实现的? 如是便有了下面的这篇文章.


Data Analysis [Via 500Px]

去年9月份时在初见Keen Io这篇文章中,曾经简单的提到了国内一些数据平台在数据采集、分析、可视化上的一些弊端(主要对比了Umeng和Keen IO两个平台之间的差异,现在看来二者其实没有太大的可比性)。一个数据平台,在对数据处理步骤大致可分为五个步骤:


数据处理步骤[Via chenkai]

而“无埋点”方式正是从属于数据采集的范畴内。对于一个平台而言数据采集是否丰富,采集的数据是否准确,是否及时,都直接影响整个数据平台的在应用层面的效果。而数据采集则是一个数据平台首先面对的核心问题。平台更多承载的是解决问题的一种solution,也就是解决问题的场景。数据采集方式的多与寡,则也直接决定其是否能够适应和解决多个场景下、多种不同的角色、多个不同的行业的对数据采集的需求。

前端埋点

从移动端角度来说,我相信在同一家公司中,不同团队对于前端埋点需求都是不一样的。简单来说产品角度更加注重的是埋点所带来的大量用户行为数据,能否通过一定数据漏斗分析挖掘找到当前产品的问题,并能对当下产品模型制定一定改善计划或策略。指标当然也是完全迥异的,挖掘潜在需求、分解不同用户群日常习惯、提高用户留存、减少页面间流失率、分析当前用户群画像等。而从运营角度来说,找到与产品调性较为匹配的投放渠道、估算不同渠道之间拉取新增的实际成本、运营创意方向的选择与取舍,热点事件借势营销策略等。这些都是我们随时要面临的问题,都需要不断的判断与决策。而决策的依据是什么-数据

有人会说没有提到开发这个角色,并不是这个角色不重要,其实从影响面大小这个角度来说。开发对数据平台依赖主要集中在反馈应用程序质量一些指标上,比如版本之间的错误率、堆栈错误信息的收集、定位异常或崩溃代码位置、基于用户行为路径日志问题的复现等。这些以结果为导向的指标,是短期内就可量化的,且对不确定因素预估能够投射到用户层面影响是可控的,而并非是轻视。

那前端埋点有哪几种形式?简单来说分为:代码埋点、可视化埋点、无埋点三种.


App Dg Point [Via 500px]

代码埋点

代码埋点应该是目前业内最为熟悉且被广泛采用的一种数据接入手段。在 Google Analytics 年代,就已经出现了类似的方案。目前,国内的主要第三方数据分析服务商,如百度统计、友盟、TalkingData 等都提供了这一方案。相信各位看到各个平台对接的SDK入口,应该不会陌生。

以熟悉的Umeng平台为例,要统计A页面一个Button点击事件次数。首先在APP或者界面初始化的时候,初始化Umeng的SDK,然后在这个Button事件发生时就调用SDK里面相应的方法,发送接口发送数据,极为简单。Umeng平台就像我去年在初见Keen Io这篇文章提到一样,说到底它只是一个统计工具,并没有提供完整的多维分析功能。而要做到多维分析就意味这,数据采集的多样化。可惜的是它目前还做不到,例如仅仅是为了统计某个数值,友盟还要单独区分出“计数事件”和“计算事件”,这样设置因为其失去了灵活性,在复杂场景上基本就难以胜任了。

我相信很多产品都在使用代码埋点上都面临一个问题-成本高。首先埋点地方过多,因为不同的版本验证问题不同不易于管理。每一个控件的埋点都需要添加相应的手工代码,不仅工作量大,而且限定了必须是技术人员才能完成。这大大掣肘了其他团队参与、临时调整的可能。其次是版本更新的代价比较大,每一次更新埋点方案,就意味着必须要修改代码,然后通过各个渠道进行分发,一旦有相当多数量的用户对新版的更新不感冒时,导致埋点代码能够采集到的数据也就得不到更新,前功尽弃。而对于运营团队来说,代码埋点方案无意于把所有资源和方案都要前置到发版前,很难在实际日常运营中能够及时依赖实时数据捕获焦点做出应变。

当然代码埋点还是有优势的,它最大优势是控制精准。精准主要体现在,我们可以选择何时发送什么样数据到后台。极强自主性完全把控了数据内容和发送的时机,对于上线后影响因素较小数据埋点它无疑是最适用的,但问题在于不可控因素出现后快速应变响应上,就显得不够灵活且难以补救。


Data Graph [Via 500px]

可视化埋点

可视化埋点其实应运而生的。代码埋点本身因为成本过高,且每次都需要手工修改代码,更新版本,难以灵活应变。那既然有这么多不便,为何没有一种方式,可以给那些不懂代码不同团队的成员使用,实时设置一些需要统计锚点到客户端,而不需要大费周章频繁更新客户端版本。就像手游把核心代码和配置、资源进行分离,在用户启动APP时通过网络加载动态的配置和资源。

而正是出于这种需求,在国外,以Mixpanel为首的数据分析服务商,都相继提供了可视化埋点的方案,Mixpanel将之称作为 codeless。而国内的 TalkingData诸葛IOSensors Analytics 等也都提供了类似的解决方案。MixPanle在去年初见Keen Io这篇文章也提到过,如下以MixPanel为例演示.


Data Point [Via Mixpanel]

在Mixpanel官方事例中,从如上界面截图可以看到,当你点击底部电影选项右上角分享按钮时,在弹出的增加锚点窗口中,设置点击这个按钮将发送的是 “Shared movie clip” 事件。然后点击 Deploy 按钮,把这个配置下发到客户端。那么在嵌入了 Mixpanel 的 SDK 的这个 APP中 ,则自动会在 APP 启动时或者客户端定时获取的方式,更新后台设置的锚点统计配置。当配置完成在真实的用户使用时,点击这个分享按钮就会真正地发送 “Shared movie clip” 事件到后台,且实时可见。

那这种方式是如何实现的呢?

简单来说在客户端集成了Mixpanel Sdk之后,Sdk会定时(例如每秒)做一次截图。在截图的同时,Mixpanel会从 keyWindow 对象开始进行遍历它的所有subviews()集合,得到当前视图下所有 UIView、UIResponder 对象的层级关系。Mixpanel会根据截图和UI元素的可视化信息来重新进行页面渲染,并且根据控件的类型,来识别哪些控件是可以增加可埋点的,并且可以在后台操作。当使用者在后台的截屏画面上点击了某个可埋点的控件时,后台会根据使用者做一些事件关联方面的配置,并且将配置信息进行保存和部署到客户端。客户端在开启或定时获取后台锚点配置之后,则会根据新的锚点配置采集数据。整个过程部署都是实时的。

为何要采用可视化的方式?

主要解决两个问题。第一不懂代码的人也可以通过Mixpanel后台配置统计锚点并实时下发到客户端生效。第二这种方式直接避免手工修改代码,需要更新版本成本才能生效的笨拙方式。变得更为主动。

当然有利也有弊,可视化埋点能够覆盖的功能有限的,目前并不是所有的控件操作都可以通过这种方案进行定制;同时,Mixpanel 为首的可视化埋点方案是不能自己设置属性的,例如,一个界面上有一个文本框和一个按钮,通过可视化埋点设置点击按钮为一个“提交”事件时,并不能将文本框的内容作为事件的属性进行上传的,因此,对于可视化埋点这种方案,在上传事件时,就只能上传 SDK 自动收集的设备、地域、网络等默认属性,以及一些通过代码设置的全局公共属性了;作为前端埋点的一种方案,可视化埋点这种方式也依然没有解决传输时效性和数据可靠性的问题。


Mixpanel DashBoard 

无埋点

其实无埋点方案出来也比较早。Heap Analytics 作为最早提出这种方案提供商,早在2013年就已经推出了“无埋点”这个技术方案。后续的用户行为分析的大佬Mixpanel也在去年中期推出同样的服务,诸葛IO也借鉴了两者,在国内最早正式推出了三大平台的无埋点分析方案,同时,国内也还有TalkingData的灵动分析和Growing IO提供了无埋点分析解决方案。

如下已Heap为例:


Heap Example [Via Heap Analytics]

界面上看感觉和可视化埋点很像。但从实际的实现角度上看,二者的区别是可视化埋点先通过界面配置哪些控件的操作数据需要收集;而“无埋点”则是先尽可能收集所有的控件的操作数据,然后再通过后台操作界面,选择哪些数据需要在系统里面进行量化分析。

“无埋点”相比可视化埋点的优点在于,一方面是解决了数据“回溯”的问题,例如,在某一天,突然想增加某个控件的点击的分析,如果是可视化埋点方案,则只能从这一时刻望后收集数据,而如果是“无埋点”,则从部署 SDK 的时候数据就一直都在收集了;只需要在后台筛选出来即可。

另一方面,“无埋点”方案也可以自动获取很多启发性的信息,例如,“无埋点”可以告诉使用者这个界面上每个控件分别被点击的概率是多大,哪些控件值得做更进一步的分析等等。当然,与可视化埋点一样,“无埋点”依然没有解决覆盖的功能优先,不能灵活地自定义属性,传输时效性和数据可靠性欠佳这几个缺点。甚至由于所有的控件事件都全部搜集,反而会给服务器和网络传输带来更大的负载。


Heap DashBoard [Via Google]

小结

可能写到这,文章的篇幅已经很长了。

三种不同埋点方式,也均各有利弊。并不存在一个可以完美解决所有场景的数据接入方案,而是应该根据不同的产品,不同的分析需求,不同的使用场景,选择最合适的一种接入方案。而将来的数据精细化运营,离不开精细、高效的数据统计和分析。这必然会成为一种趋势。

lastedited:2016年04月14日19:32:10

iOS