阅读 2924

无痕埋点方案,现有方案调研 | 掘金技术征文

版权声明:

本账号发布文章均来自公众号,承香墨影(cxmyDev),版权归承香墨影所有。

未经允许,不得转载。

一、前言

对于一个线上的产品,我们会通过一些数据指标来监控我们的产品的情况。而市面上有各种统计平台,友盟和百度统计,都是比较常用的。我们线上项目现在依然还在使用友盟来做到打点统计。

但是这些统计平台,有一个缺陷就是需要手动以代码的形式预埋点,也就是说在发版之前,就确定要需要的统计点,然后以代码的形式,硬编码到项目对应的位置,在发版之后,才会生效并且上报对应的数据。

这样就带来一个很大的问题,如果发版本之前,无法预见我们需要的统计点,或者有遗漏,我们只能通过发布新版本,或者热更新的方式来补充这个数据统计点。而这,会导致数据的不准确或者调整起来不够灵活。

所以,无埋点方案就孕育而生,有没有办法做到无埋点就解决数据统计的问题?

二、市面上常见的方案

对于市面上常见的统计方案,美团点评的文章已经帮我们总结的很好了。

为了解决前端埋点的准确性、及时性、开发效率等问题,业内各家公司从不同角度,提出了多种技术方案,这些方案大体上可以归为三类:

  1. 第一类是代码埋点,即在需要埋点的节点调用接口直接上传埋点数据,友盟、百度统计等第三方数据统计服务商大都采用这种方案;
  2. 第二类是可视化埋点,即通过可视化工具配置采集节点,在前端自动解析配置并上报埋点数据,从而实现所谓的“无痕埋点”, 代表方案是已经开源的Mixpanel
  3. 第三类是“无埋点”,它并不是真正的不需要埋点,而是前端自动采集全部事件并上报埋点数据,在后端数据计算时过滤出有用数据,代表方案是国内的GrowingIO。

1、代码埋点

代码埋点的最大缺点就是需要有预见性,需要在发布版本之前,就判断出我们需要的数据。这种预见性,只能在流程上人为的把控,有几点建议可以参考一下:

  1. 产品在出产品文档的时候跟随一篇对应产品的统计文档,开发按照这个文档严格执行,将需要的数据都上报。
  2. 在发布灰度升级的时候,检测对应的统计点,是否符合预期。如不符合,及时调整后再发布市场。

但是这样的方案缺陷也很大,可能会引出其他的问题,例如产品功能的迭代,可能一个地方的修改会影响到其他地方的统计之类,或者有突发情况需要了解一些侧面数据。

这就很考验产品经理出的统计需求文档时候的经验和预见性,当然开发人员在开发这个功能的时候,也可以提出改进意见,一句话,意识很重要。

2、可视化埋点

可视化埋点,看了下这个开源项目,维护的还很勤,但是如果按照这个方案修改的话,对于一个现有项目,改动还是挺大的,没太深入研究。

有兴趣的可以看看介绍视频,当然,可能需要科学上网的方式观看:

www.youtube.com/watch?v=Kcp…

3、全量上报,服务解析

第三类这种无埋点的方案,它实际上是采集了所有的事件,并且全部上报,最终在服务端,根据用户需要的统计点,分析出对应的数据进行展示。

上面推荐的 GrowingIO ,大概了解一下,实际上它并不是免费的,接入的时候可以提供一个免费的试用账户给开发者,但是如果真实上架的 App ,是需要付费使用的。

但是官网上并没有报价,可以通过客服咨询问价,我现在了解到的,基础价格是 6W/年,包含起步的 3W 最高日活,高于 3W 日活后,阶梯增长收费,每涨 1W日活,多加 2W 块。不过据说这个价格可以谈,有兴趣的可以继续了解一下。

这种收费的服务,一般而言不会是我们的首选。

三、美团的方案

美团点评对客户端埋点的要求:

  1. 数据的准确性和及时性。
  2. 埋点的效率,要能适应版本迭代做到快速埋点。
  3. 动态部署和修复埋点的能力。

所以他们独立开发了一套自己的无埋点的方案。会将常用的 UI 控件,全部自定义一遍,重写事件的响应方法,在这些事件的响应内填写埋点的代码,在需要上报的时候,动态上报即可。

这样实际上,改动只需要通过一个接口下发我们需要的埋点控件的 id、以及上报的埋点统计的 Key 即可,当然实现起来会比这个跟复杂一些。

这里只需要知道美团点评的方案,就是重写 UI 控件,然后拦截其事件,符合要求的,发送统计数据到统计系统中。

但是这样的一个方案,虽然可以解决问题,但是又需要面临另外一个问题,移植的成本非常的高。

所以美团想到的了两个方案:

  1. 参考 v7 支持库的思路,通过 AppCompatDelegate 代理自动替换 UI 控件。
  2. 编写一个 Gradle 插件,在运行的时候,动态修改其控件的父类,达到移植的效果。

方案一,的问题在于,只能替换你 App 内直接使用的 UI 控件,对于第三方库中重写的 UI 控件,这样的方案是不行的,所以才演变出需要方案二。

而方案二实际上是在编译期间做的改动,所以也不会影响运行效率,只是可能会耽误一点编译的时间,这点效率问题,其实我们是可以接受的。

四、总结

今天就先说到这里,之后会继续详细讲解以上介绍的两种方案的技术实现细节,需要关注的点和会遇到的坑。

那么我们就敬请期待吧!

本文参加掘金技术征文:juejin.im/post/58d8e9…

公众号二维码.jpg

关注下面的标签,发现更多相似文章
评论