客户端埋点的一些分析和体会

最近了解很多的关于埋点的相关文章,感受颇多,在此给大家分享一下。有不正确的地方还望各位指正。这篇文章主要分为3部分:

一、埋点的重要性

追踪用户在平台每个界面上的系列行为,事件之间相互独立(如打开商品详情页——选择商品型号——加入购物车——下订单——购买完成);
联合公司工程、ETL采集分析用户全量行为,建立用户画像,还原用户行为模型,作为产品分析、优化的基础。
无疑,数据埋点是一种良好的私有化部署数据采集方式。数据采集准确,满足了企业去粗取精,实现产品、服务快速优化迭代的需求。
但是,因手动埋点工程量极大,且一不小心容易出错,成为很多工程师的痛。且其开发周期长,耗时费力,很多规模较小的公司并不具备自己埋点的能力。无埋点成为市场新宠。最后埋点、无埋点两种技术谁能成为最后赢家,我们拭目以待。

二、埋点的终极方案

埋点的最终理想状态是:不用修改客户端,通过网络进行配置相关数据,就可以达到修改客户端的埋点数据。
原理如下图:111
具体原理:
服务端通过网络配置json数据表(服务端进行数据表的版本控制)
客户端每次开启数据的时候,都会发请求BIVersion,将获取到的版本号和本地存储的版本号进行比较。如果版本号大于本地保存的版本号,根据网络数据,更新本地数据。
客户端每次发送请求的时候,发送的相关数据,和数据结构配置,都通过读取配置表里面的数据(服务端保存的JSon数据)。这样就可以做到只通过网络端进行配置,就可以实现客户端的埋点上传数据更改了。之后维护全部都是维护网络上的数据表就可以了。不用再修改客户端

三、目前项目现状

目前版本的教师端埋点实现方案:

Android客户端,已经实现抽出一个工具类。埋点的时候只需要调用一下工具类方法,并且将需要上传的参数传过去就可以实现埋点。
优点:抽出一个公共方法,可以避免代码的冗余,如果需要修改某一个公共字段,实现了一定的数据解耦和逻辑解耦。
缺点:手动埋点工程量极大,且一不小心容易出错,成为很多工程师的痛。且其开发周期长,耗时费力。

重构版本的教师端埋点实现方案:

在抽出工具类的基础上,对页面进行封装,抽出一个基类,在基类的生命周期中,调用工具类方法,同时最大的改进是所有的埋点需要上传数据和页面埋点发送数据结构,全部都通过本地保存的数据配置表来动态获取,做到了只需要修改数据表,就可以实现BI埋点的更改。
优点:避免代码荣誉,进一步对代码进行了优化。如果需要修改某一个字段,只需要修改配置表就可以,简化了数据操作,对数据和逻辑进行了进一步的解耦,实现了无埋点的理论
缺点:由于目前服务端不支持网络配置表,所以如果配置表修改了,就需要跟新客户端才能获取到最新的数据据,不能做到动态的数据变更。

理想版本的教师端埋点实现方案:

详情请见第二条
优点:所有埋点数据全部从网络获取,可以远程的进行动态配置,远程进行埋点数据更新,无论客户端是否进行更新,都可以做到全部的客户端同时更新。
缺点:再设计数据结构之前,需要做较多的调研,从而设计出一套比较完善合理的网络配置表。如果数据结构变动比较大的话,可能会出现不兼容问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注