代码逻辑分析_【DTalk实践】说说前端数据采集与分析的那些事

e0fa3ef686a416a6b06d041c95ac7d78.png

说说“手工”、“可视化”、“无”埋点基本原理

  ● 手动埋点(代码埋点):手动写代码,调用埋点SDK的函数,在需要埋点的业务逻辑功能位置调用接口上报埋点数据,友盟、百度统计等第三方数据统计服务商大都采用这种方案;需要深入下钻,并精细化自定义分析时,比较适合。此类埋点需要产品和开发反复沟通,埋点容易出现手动差错,如果错误,重新埋点的成本很高。这会导致整个数据收集周期很长,收集成本很高,而且效率很低。

  ● 可视化埋点(框架式埋点、无痕埋点),解决了纯手动埋点的开发成本和更新成本,通过可视化工具快速配置采集节点(圈点),在前端自动解析配置,并根据配置上传埋点数据,比起手动埋点看起来更“无痕”,这里的配置数据可以设置过滤条件,避免针对所有元素(比如全埋点),可以在调用开启自动监控api时通过设置一些特征属性,来过滤不符合条件的元素,实现只针对某些元素进行自动上报数据的需求; 比如Mixpanel;

  ● 无埋点(自动埋点、全埋点):它并不是没有任何埋点,只是不需要工程师在业务代码里面插入代码. 只需要加载了一段定义好的SDK代码。技术门槛更低,使用与部署也简单,避免了需求变更,埋点错误导致的重新埋点。通过这个SDK代码,前端会自动全量采集全部事件并上报埋点数据,能够呈现用户行为的每一次点击、每一次跳转、每一次登录等全量、实时用户行为数据,这些数据传到后端后,可通过用户分群、漏斗对比等功能,分析不同访问来源、不同城市、不同广告来源等多维度的不同转化细节,细而全。问题是自定义属性不灵活,传输时效性差,数据可靠性欠佳,耗费网络流量,并增加服务器负载,而且兼容性也不佳。比如Heap analytics、GrowingIO、神策。

f5a95aa91ed83c27b68af9f3c4da45c6.png

f6a2c324293935b862201acc5f8e4fd2.png

https://www.threejs.online/ 这个站点,我就装了很多SDK。

52dd613d7f430c7d97968859e709dfab.png

可视化和无埋点,因为我没有开发过,只有使用过,不敢班门弄斧。作为一个手动埋点的深度用户和开发者,可以谈谈常见的痛点:

1、埋点混乱

2、常常埋错,漏埋

3、业务变化后,老埋点数据失去意义

4、埋点数据无人使用,浪费资源

5、数据团队、研发团队、产品团队协作配合难度大

6、很多时候不太重视数据,而是重视业务的快速上线

自动埋点与手工埋点的区别?

根据工作中对埋点的对比和整理,我们汇集一下相关的对比:

1、对于语义明确的UI事件,自动埋点的数据一般会比手动埋点更加准确,更贴近用户行为,也更节省开发成本,侵入性更低。

主要是因为自动埋点语义简单明确,不像手动埋点由于开发习惯、代码风格、人的理解误差、分支处理等各种不确定因素变得没那么清晰明了。

比如:“下单”事件,自动埋点的PV肯定是>=手动埋点的,UV差别可能不大。分析开发代码发现在onClick Listener中包含其他未覆盖到的分支,差别很可能就在代码分支当中。如果更进一步分析下代码可以发现,为什么开发不在分支当中埋点?可能这个分支会认为用户的这一次点击是“无效”的,但这只是程序逻辑的看法,用户可能不这么认为,用户很可能会觉得很奇怪没反应,然后再点一次。这些手动埋点不易察觉的细节,自动埋点都能记录,所以说,自动埋点在这些情况下会更贴近真正的用户行为。

2、自动埋点可降低原来手动埋点的个数和复杂性,使之更简化

比如:进入“商品详情页面”(展现),目前包括5个手动埋点,实际上用自动埋点只需要一个就够了,而且自动埋点不会遗漏。从数据来看,一个自动埋点的PV已经超过5个手动埋点之和。

3、自动埋点可采集界面环境数据,但是数据不够纯,需要进一步去噪

自动埋点能采集到大部分用户“看到的而且有用数据”。比如:“价格”这一属性,手动埋点可直接定义“amout: 5.2“来轻松获取数据,而自动埋点获取的是一串文本: “价格预估5.2元”,若要获取精确的5.2这个数值,就需要进一步解析。

4、自动埋点无法替代手动埋点,但可大大减少手动埋点工作量

可预想的是,在用户行为分析上,自动埋点可以满足很大一部分需求

函数级的埋点无法用自动埋点代替,后台非UI的事件也无法用自动埋点代替,自动埋点无法携带当时的业务场景数据,这些都表明了自动埋点无法完全替代手动埋点。

但单就用户行为分析来讲,自动埋点是可以覆盖用户的一些基本行为路径的,并能做一些较浅层次的分析。如果需要探究用户行为背后的原因、或需要进一步深入分析行为的时候,就是需要更多的后台逻辑事件、需要携带更多属性值的时候,就需要通过手动埋点来完成。所以,但是深层次的分析是你的重点,就需要使用手动埋点来解决。

前端手动埋点的常用方法

埋点技术除了刚才的方式划分,还可以划分为前端埋点后端埋点,后端埋点数据更可靠、更集中(无需多端)、更实时,前端可以离线运行,因为我们是FE团队,今天也主要是和大家聊聊前端埋点。

前端埋点中的代码手动埋点一般有以下几种:

1、命令式:

$(document).ready(()=>{   // ... 业务逻辑   sendData(params); }); // 按钮点击时发送埋点请求 $('button').click(()=>{   // ... 业务逻辑   sendData(params); });

a60e2eb363ffb603c42f3f6765f49255.png

senddata就是发埋点数据。

2、声明式:

打车

96cb3939eb57275a1797e2f7cca5dff0.png

3、前端框架式:

如果我们使用Vue或者React等前端框架,是可以在各个生命周期位置进行你所需的埋点。这里不展开。

4、css埋点:

.link:active::after{        content: url("http://www.example.com?action=yourdata");  }

<a class="link">点击我,会发埋点数据a>

07d6a61f36a71686994fa9d8b892a6be.png

3996130ae76987c3cbb8509eefc71dd8.png

上面的截图是Google Analytics的上报内容。

28e4a48d2ee660cbb85f0eb69a619e9e.png

上图是talkingdata的接入代码。

30392a37445c21166dd5d3ebd2391502.png

上图是TD的上报内容。

30392a37445c21166dd5d3ebd2391502.png

上图是GA的接入。

64738c8af7c17aa070cf16e868cdd1d8.png

上图是GA的上报。

local storage和cookie一样,有生命周期,可以把一些任务队列放里面,也可以把一些用户识别的ID放里面。和Cookie的功效有一些相同

企业什么阶段选择自动埋点和可视化埋点?

某些企业,保守估计,手动埋点的错误率可能会高达50%,比如一些简单页面的进入应该埋在 viewDidAppear(didMount...),按钮点击应该埋在 onClickListener等等都经常被开发弄错。埋点工作本身并不难,是纯粹的体力活,但是要展开一个好的埋点工作,需要BI先梳理,然后再传达给RD,然后RD再去开发实现,最后应该经过测试验收,因为没有统一的标准,每个人的理解不一样,就很容易弄错,后面会和大家在详细聊聊埋点规范的问题。

我们了解的一些大公司,像Facebook等硅谷公司已经将埋点看得与产品设计同等重要,新功能还在设计阶段就先把衡量指标及埋点梳理好,而具体负责埋点的RD也是团队中最资深的RD(如果不是专职的话),RD需要每天不断的与BI沟通确保语义一致

而我负责过的滴滴、陆金所等公司的项目现状是,埋点的RD很多时候都是随机的,甚至经常被安排给实习生,埋点质量难以保证。还有一种情况是产品为了快速上线需求,一味追求上线速度,在需求评审阶段没有梳理和提出埋点需求,上线后临时插入埋点需求,在未经过分析理解和测试验收的情况下匆匆加入埋点代码,而且测试经常也不重视测试(提出免测),导致埋点错误,甚至是业务代码错误等线上问题(后续的埋点规范会更进步一步针对这个问题做分析,并提出方案)。这种情况下自动埋点既能减少沟通开发的工作量,又能降低埋点出错的概率。所以,自动埋点很适合公司在埋点规范没有完全建立,埋点质量普遍不高的阶段。

根据以上的总结,可以看出,手动埋点技术需要在企业的网页或者客户端内写入相应的代码,虽然操作过程会复杂一些,但可以更精准的采集后端模块的数据。例如当用户提交了一个订单,有埋点技术不仅可以采集到“订单提交”这一行为事件,还可以获取到该订单的具体商品类别信息。有埋点的技术的缺点在于,因为目前大多企业在采集数据这一块没有一定的规划,大多都是提出一个需求之后,再写入一定的代码,这样就会容易造成整个埋点铺设混乱,极易出现一些故障。

我在3月17日下午的DTALK线下研讨活动中会和大家交流一下数据采集在大数据和用户画像项目中的经验。

本文作者:

谯洪敏老师,DTalk联合创办人,前滴滴出行上海终端技术负责人,主要专注与前端工程化、前端Web安全及前端性能优化,有丰富的前端埋点技术工程、数据处理和数据质量的经验。

0b6bea8054d9ffd2f1bea76b7844b7a3.png

2019.03.17

技术和数据驱动的互联网增长

上海 虹梅庭

3月17号下午,DTALK会组织专题讨论用户画像、Profile规则系统在大数据驱动业务中的落地

14:10 - 15:00

专题研讨:大数据、标签体系和用户画像的业务价值和如何落地?

无论我们在什么样公司环境里做大数据项目,都会遇到技术挑战和业务价值的问题。

需要解决:

1)如何有效推动数据埋点、线上和线下数据采集及整合?

2)到底如何选择有效的数据产品规划路径,做到在“飞机飞行途中更换引擎”?

3)如何设计合理的核心指标和衍生指标,并通过大数据项目提供有效决策工具?

4)如何设计AB测试试验

5)个性化推荐到底该不该做?做了如何评估价值?

6)如何建立企业Profile规则系统,帮助业务方有效利用用户画像设计产品和运营策略?

这次邀请了5位一线专家一起探讨在互联网金融、新零售电商和行业垂直门户领域经历的0-1的大数据产品项目经验。从战略思考,产品定位,项目安排,到产品落地,赋能运营等等,和大家一起探讨一个个更加完整生动,更加实战落地的故事。

研讨专家组:

黄一能,DTALK联合创办人,前麻袋理财大数据产品和数据分析负责人。

徐晓楠, 网易考拉数据产品负责人。多年从事数据分析和数据产品相关工作,负责过网易旗下多个业务及产品的数据分析体系建设和网易域内包括移动应用分析、营销监测、用户行为分析等多个数据产品平台的构建工作。在互联网产品和电商数据体系建设上具有丰富的经验。

谯洪敏 DTALK联合创办人 前滴滴出行上海终端技术负责人。

吕载怡,永辉集团IT架构合伙人,负责永辉集团的数字化和信息化转型。

朱仁杰,上海有色网产品总监,系统架构师,大宗商品交易、有色金属行业信息化专家。

长按以下二维码,可以了解活动详细内容

46b5a62ced367814719d3af6f9ca1413.png

活动咨询:请加微信号 hzsun910208

f0c01f38ffca8a9e9e842b133c8c16a9.png

点击下方

↓↓↓

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值