【DTalk精华】滴滴出行谯洪敏:前端数据采集与分析的那些事第二弹:企业如何选择自动埋点和可视化埋点

4月14日晚,DTalk邀请到了谯洪敏老师,他是滴滴上海前端团队负责人,前陆金所移动前端团队负责人,进行了一次关于《前端数据采集与分析的那些事第二弹:前端篇》的微信群线上主题分享。
分享活动分享了手动埋点、可视化埋点与无埋点的基本原理,重点讲了前端手动埋点的几种常用方法,最后说了企业什么阶段选择自动埋点和可视化埋点。

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

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

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

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

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

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

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); });



senddata就是发埋点数据。

2、声明式:

<button data-mydata="{key:'uber_comt_share_ck', act: 'click',msg:{}}">打车</button>

3、前端框架式:

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

4、css埋点:

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

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

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

上图是talkingdata的接入代码。

上图是TD的上报内容。

上图是GA的接入。

上图是GA的上报。

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

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

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

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

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

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

本文作者:

谯洪敏老师,DTalk核心专家组成员,滴滴上海海浪前端团队负责人,前陆金所移动前端团队负责人,主要专注与前端工程化、前端Web安全及前端性能优化,有丰富的前端埋点技术工程、数据处理和数据质量的经验。

干货专访和文章
【DTalk分享】黄一能:互联网产品运营决策中用户画像的核心作用直播回顾
【DTalk分享】陈抒:产品设计中的用户画像直播回顾
【DTalk分享】吆喝科技王晔:A/B测试最佳实践直播回顾
【DTalk精华】网易郑栋:前端数据采集与分析的那些事第一弹: 从数据埋点到AB测试
【DTalk精华】滴滴出行谯洪敏:前端数据采集与分析的那些事第二弹:企业如何选择自动埋点和可视化埋点
【DTalk精华】滴滴出行谯洪敏:前端数据采集与分析的那些事第三弹:埋点需求整理原则于埋点流程规范
【DTalk专访】滴滴谯洪敏:百家争鸣的前端技术时代
【DTalk思考】顾青:互联网团队的数据驱动能力从哪里来?
【DTalk专访】彭圣才:AI超越人类大脑,是一场「別有用心者」的骗局吗?
【DTalk专访】翁嘉颀:AI行业现阶段最需要什么样的人才?
【DTalk专访】赵华:携程怎么把机器学习与实际业务相结合?
【DTalk专访】网易郑栋:BI、可视化数据产品和大数据的几个核心问题
【DTalk回顾】美团点评沈国阳:我们在谈用户画像的时候到底在谈什么?
【DTalk专访】王晔:谷歌数据如何用于决策?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,847评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,208评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,587评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,942评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,332评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,587评论 1 218
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,853评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,568评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,273评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,373评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,031评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2 269

推荐阅读更多精彩内容