埋点的意义
用户数据的收集一直是持之以恒的话题。在最早的时候,开发商或者开发者没想要那么多数据,他们最想要的是用户诊断日志。因为网络不发达和软件分发的模式,导致用户遇到问题就很难定为和解决。所以要么上门,要么你把日志拷给他。我想最早的用户数据最多是软硬件环境和出错日志。
到了我使用PC的年代,当操作系统遇到问题时,用户已经可以选择发送日志给微软了。当然网络依然不发达,除了一些大型应用外,其它的都不考虑这条用户和开发商之间的通道。而事实上很长很长一段时间,除了操作系统在收集用户信息,其它软件,恶意软件除外,压根都没想到过。
到了互联网web 2.0时代,网页埋点被慢慢应用起来。原因大致有二,一用户已经不再贫穷,他们的网络很好,他们的选择很多。二,开发商也意识到用户体验的重要性,他们需要收集数据来推进体验。那个时候还没有想用数据进行大数据分析,当然有利用用户信息推送广告的广告系统。所以当时的埋点一般都为性能埋点和页面流转埋点。这种思想也催生了GA 这种伟大的产品。网站的线上监控的理念和产品也应运而生。到今天各种APM 公司,传统网站依然是重度用户。
当时互联网广告也很火,这里不得不提一下cookie,网页端用户信息载体。有一天,你在北京上某个网站,突然给你推了条上海的酒店广告。那很多可能你最近查询了上海旅行和住宿信息,这些信息在cookie里,上传后被广告系统处理,然后你就变成了前面出现的广告的target。可以说,如果没有cookie,互联网广告行业估计就不会那么有意思。
时光荏苒,一不小心到了移动时代。我记得我和小伙伴们做的第一款手游集成了友盟来收集用户的手机信息,
游戏的日活,用户的登录登出,打开时长等等。我们当时其实没有把这些数据用起来,一来对用户数据不敏感,二来没有专业BD ,也分析不出个蛋来。
我后来换了个工作,去做移动广告,就是谷歌的admob,苹果的iAd 同种类型的。大家应该都知道移动应用端已经失去了cookie ,开发者无法随心所欲的收集用户信息,要来定位一个用户就异常困难。移动广告讲转化率,用户A 通过点击广告下载了某应用,怎么判断他又安装了该应用呢?这是个大难题。我们那个时候的转化率误差很大,开发每天都在改进算法,增加纬度。而这些算法基于的就是客户端的埋点信息的收集。
后来我加入阿里,又到支付宝,更加体会到埋点的重要性,我们后续会讲。
哪些端需要埋点?
昨天有同事问服务端要埋点吗?我的看法是你想要的信息是否容易获取?我们知道客户端埋点是因为客户端的行为不受控制,信息不易获取,所以大量采用埋点。如果你的服务端也有类似问题,比如大规模集群,那你要看某个特定日志必然困难重重,这个时候就需要服务端埋点或者说服务端监控,不过就不是埋点那么简单粗暴了。这个可以了解下 oneAPM 的技术。
个人觉得,到用户手上的产品,即客户端都需要埋点。在民众生活中露出的无非是三张屏幕:
- 电脑显示屏
- 手机屏幕
- 电视屏幕
所以不要觉得没人关心你,软件开发商无时无刻不在关心你。
哪些场景需要埋点?
我主要讲下我略微了解的客户端埋点,埋点是艺术活,埋的好,可以给你带来漂亮的报表,有钱途的业务模型等等。埋的不好,数据没有用,还占资源。
我们从需求出发,业务人员想要知道哪些业务使用量大,开发人员想了解产品的性能,稳定性,老板想要pv,uv。人人都是产品经理,人人都会提需求。那我们不妨把这些需求归类为:
-
用户行为:记录用户使用过程中的行为,用于产品和运营人员分析PV和点击等产品数据。
-
质量监控:记录客户端闪退、异常、性能等质量数据,用于技术和运营人员监控质量异常。
-
运行跟踪:记录程序运行过程中打印的日志,这部分日志会存在手机上,用于开发人员分析问题。
运行跟踪不适合埋点,从说明也能看出,这个类似于windows的诊断日志,只有用户出问题,主动要求诊断的时候才会用到。
如何埋点?
如何埋点,其实涉及到一个非常庞大的监控系统的设计,这方面我没有任何经验,我从使用者的角度来推敲下。
-
模型设计
对于每种类型的埋点,需要建立好可扩展的模型,大家应该关注到上面图片中的可扩展信息,再最初的时候,可能一下子无法想到所有的信息,所以我们需要自己方便扩容的模型。
-
埋点规范
也许我们有很多客户端,应用A,应用B。如果埋点规范不统一,那么埋点信息上传之后,就可能需要多套系统来解析了。这就非常的不划算了。需要结合设计好的模型,给出基本的埋点规范,当然也要给客户端足够多的发挥空间。
-
自动埋点和主动埋点
无论是网页应用还是移动应用,想要别人遵守规则,最好的办法就是给你一个sdk,集成到你的应用中去就可以了。所以我们可以把一部分埋点行为在sdk中做掉,比如上图中的手机信息。然后开发者需要调用sdk中的接口进行主动埋点,那些业务埋点就需要借助这些接口了。
-
上传机制
我们不可能时时上传埋点信息,如果那样,简直就是流氓软件,流量小偷了。合理的上传策略,比如间隔半小时上传一次,在用户在使用 wifi 情况下上传,压后台时候上传。只有做到用户无法感知的上传,才算是合格的埋点。
-
日志保留时间
如果我们一直没有成功上传,日志越攒越多,那肯定会占用不少空间,这对手机的影响是非常大的。所以制定策略,无论是定时清除,还是定量清除,总之不能让用户在他的手机里发现日志怪兽。
-
展示平台
相信海量埋点上传之后,肯定会用到数据库,针对埋点模型设计好的数据模型,可以更好的帮助数据同学做出多维度的报表。有了数据之后, 怎么做,就是每个公司自己的事情。
埋点之后,测试要干什么?
其实有了这些埋点后,在灰度期间,上线初期就可以关注收集的数据,发现问题就能及时修复。那么测试需要干嘛呢?
- 首先在发布前要保证埋点是正确的。
- 发布之后,要时刻关注监控大盘,无论你是主动去数据库捞数据,还是去已经做好的监控大盘。
- 拉取性能数据和之前版本做比较,拿数据证明质量是否改善。
- 在发布一段时间后,拉取各种数据,去喷开发,pd们!
抛砖引玉
我对这块的理解也就差不多那么多。监控是永恒和未来,而埋点是一切数据的来源。我先抛出这块砖头,看看其他高手或者内家有没有经验分享。
转自:
https://testerhome.com/topics/3762
相关推荐
1. **埋点技术**:Mtrace通过在服务端代码中插入埋点代码,记录服务调用过程中的关键信息,如服务名、方法名、耗时等,并通过ThreadLocal存储同步调用上下文,通过显式调用支持异步调用上下文。 2. **数据传输**:...
【标签】: Android客户端应用开发、参考文献、专业指导 【部分内容】: 该研究背景指出,随着移动互联网技术的快速发展和Android系统的普及,智能手机用户数量剧增。Android系统在全球市场占有率高,尤其在中国市场...
\n\n在系统架构中,鹰眼首先通过中间件进行埋点,利用ThreadLocal存储调用信息,实现异步写入日志,并采用采样的方式减少性能影响。一旦发生问题,可以实时抓取日志,按照Traceld汇总,然后根据不同的存储策略进行...
- **日志数据收集**: 通过 SDK 埋点技术捕获客户端用户的行为数据。 - **日志数据上传**: 日志数据可以采用 Shell 脚本或 Flume 等工具上传至 HDFS。 - **ETL 操作**: 对 HDFS 上的原始日志数据进行清洗、转换和加载...
埋点可以是在客户端,也可以在服务端,它记录了包括traceId、spanId、调用时间、协议、调用方信息、耗时、结果和异常等关键信息。这些信息被记录下来后,通过异步日志采集和采样技术减少对系统性能的影响。 2. 收集...