我与埋点的爱恨情仇

好久不见。

最近不是在加班就是在加完班回家的路上,很突然的,每天到家都十一点半,一睡觉,一闭眼,满脑子都是埋点校验、报表加载超时、审批不通过,魔怔了您内?追究起来,一切都是埋点惹的祸。

最近一段时间埋点问题出现的频率太高了,频频在埋点上栽跟头。加上对埋点规范不熟悉,与前后端交流不多,埋点制定与检验流程有漏洞等,每次只有在实验观测周期后才会开白,测埋点,取数据。这时候,坑它就来了,各种宕机、hold住、延期也就来了。现在踩过的坑可以讲出丰富多彩、五花八门的故事,在与同事们谈笑间,自己也不禁陷入了沉思(此处很严肃)。

从自己的个人经历来说。

有些公司的埋点规范是既定的,新增埋点是由数据分析师定,由产品提交需求给开发,多方同步,上线后需要数据分析师校验确定埋点的准确性。这其中,有的公司埋点规范做的还不错,有统一的规则,多方之间交流较为顺畅;有的公司埋点规范做的可能不太好,新增埋点显得手足无措;有的公司可能对于数据分析师制定埋点这一方面的能力培训和指导做的不好;有的公司可能要求数据分析师统一学习培训,具备一定的埋点制定技能。

有些公司的埋点规范也是既定的,但是新增埋点是由ETL定,产品提出需求给到ETL,多方交流沟通后,开发完成,上线后ETL校验,此时可能有数据分析师的参与,但也可能没有。这时候就可能存在ETL对多方业务不够熟悉或由于事情太多等原因定错埋点规范,也可能开发埋错埋点但由于校验疏忽导致没有及时发现问题。后来,问题就在实验了好多天之后被发现了,不可避免的,延期它又来了。

还有些公司,甚至都没有统一的埋点规范,用到什么埋什么,现下怎么方便怎么来,至于后续是否会产生问题,那是之后的事。这时候埋点规范的不统一就不可避免的给后续埋了无数的坑,gg,心疼。

关于埋点,不由得想起了之前跟朋友闲聊时提及的内容。哎,上班了就是不一样哎,吃个饭都不能聊点别的,就知道交流工作经验(无限吐槽和吐槽)!不过工作嘛,有愉快的事就有不愉快的事,调整心态,睡醒又是新的一天。

场景一

有次跟一个朋友的对话,背景是他被老大问到了一个问题,他就拿这个问题来“考考”我。

问:支付场景应该在服务端埋点还是在客户端埋点?

答:建议服务端,如果条件和资源允许的话,可以客户端和服务端相结合。之所以建议服务端,是为了避免客户端出现网络不好的情况造成支付数据的漏采,另外支付可能存在多个入口,服务端埋点能够保证各入口数据能够采全。

☞知识点:

服务端埋点的优点:能够确保数据完整上报;能够准确采集业务操作。

服务端埋点的缺点:缺少用户设备标识,无法关联用户行为信息;缺少用户行为上下游信息,采集到的信息有限。

客户端埋点的优点:能够详细采集用户行为数据;能够完整采集用户设备标识。

客户端埋点的缺点:网络不好时会影响数据上报,多个功能入口时可能容易漏埋点。

服务端埋点和客户端埋点分别适应什么业务场景呢?

举个例子,像电商平台,一个用户可能存在如下行为:进入app,点击进入商详页,加入购物车/收藏,提交订单,支付成功。这其中涉及到客户端用户行为的,多建议使用客户端埋点,如点击进入商详页、加入购物车、提交订单。而对于其中的支付成功这种业务结果事件,一般建议使用服务端埋点,有效避免客户端埋点的一些劣势。两种埋点方式相结合,就能产生相互补足的效果,更完整、准确、高效地实现数据上报。

场景二

一次久违且奔赴路上吃罚单的饭局上,两位开发聊天(各种什么架构、系统、上线、联调),我插了一句,补了个埋点问题,学弟就提出了疑问。

问:嗯?埋点是自己埋的吗?不是都有现成的系统进行采集吗?

答:哈哈哈,这个问题不错,有时候确实是直接加载一段SDK代码就能实现数据采集了,但有时候还需要人为写代码进行数据采集,这就是之前我学到的有埋点和无埋点数据采集的方式。

☞知识点:

埋点,就是在应用中收集一些流程信息,用以跟踪记录应用的使用情况,且可通过获取的信息为之后产品迭代、运营活动等提供数据支持,比如常见的点击数、点击用户数、曝光时长、浏览时长等就是通过埋点收集到的数据。

埋点可分为(有)埋点和无埋点两种方式。

埋点采集数据:通过编写代码来详细描述事件和属性的方式,称为埋点。

埋点采集数据的优点:能更详细地描述每一事件的属性,特别是结果型数据。

埋点采集数据的缺点:

  • 依赖于人的经验和直觉,需要提前想好采集哪些指标,哪些维度的数据,而经验有时候会成为一种先入为主的弊端,还需数据进行测试、证明。

  • 沟通成本较高,埋点制定需要多方参与,比如产品、数据分析师、开发等,而由于专业不同在沟通过程中可能产生理解偏差。

  • 需要大量时间进行数据清洗,如果埋点不够规范,或埋点产生变动,增改等,可能会导致代码混乱或数据冗余,需要进行数据清洗。

  • 容易出现埋点埋错导致数据错采漏采。

无埋点采集数据:无需手动写代码埋点,只需要在第一次使用时加载一段SDK(软件开发工具包)代码,即可进行全量实时的用户行为数据的采集。

无埋点采集数据的优点:无需手动埋点,无需多方参与,降低沟通成本,也不会出现埋点埋错的现象,效率更高。

无埋点采集数据的缺点:

  • 不能个性化自定义获取数据,缺乏数据获取的灵活性。

  • 一般不自己开发SDK,直接使用第三方提供的埋点方案,可能会造成数据源丢失,泄密等问题。

  • 由于采集的是全量数据,数据传输压力较大。

  • 仅支持客户端。

上述两种方式是我了解和接触到的埋点数据采集方式,一般可以选择将上述两种方式进行结合,充分发挥各自的优势。

  • 无埋点方式效率高,采集成本低,一些产品的发版、上线等都不会影响到数据的自动采集。

  • 埋点方式能更详细地描述事件属性。

  • 行为数据(浏览、点击)可采用无埋点方式,结果型数据(交易)可以有埋点方式。

除此之外,最近还有看到一种叫做可视化埋点的方式。大概意思是也不需要手写代码,直接采用SDK,但可以通过可视化平台使用圈选功能选出要对用户行为进行捕捉的控件,给出事件命名。圈选规则会同步配置到各用户终端,SDK会按照圈选的配置自动进行用户行为数据的采集和发送。

哦了,自己能复习的就这些了,也已经尽力想办法避免再遇到此类问题,这之后一系列的反应真的是不想再经历一次了。推推推,各种延期,各种工作堆积,十一点多下班就成了日常,精神紧张,来不及调节,脸上疯狂爆痘。

啧啧啧,不说了,周五晚上不宜加班太晚,我要去吃火锅了,周末愉快。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值