数据要埋点
浅谈数据埋点
|0x00 如何理解埋点
埋点是数据采集的专用术语,在数据驱动型业务中,如营销策略、产品迭代、业务分析、用户画像等,都依赖于数据提供决策支持,希望通过数据来捕捉特定的用户行为,如按钮点击量、阅读时长等统计信息。因此,数据埋点可以简单理解为:针对特定业务场景进行数据采集和上报的技术方案。
数据埋点非常看重两件事,一个是数据记录的准确性,另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程,因为参数的规范与合法,将直接影响到数据分析的准确性,如果准确性得不到保障,那么所有基于埋点得出的结论,都是不可信的。辛辛苦苦做了很久的方案,一旦因为一个疏忽的小问题,导致下游集中投诉,其实非常划不来。
道理每个人都懂,但现实情况中,数据埋点所面对的客观环境,其实非常复杂,例如:
产品在移动场景下,既有原生的IOS和安卓端,也有H5和小程序端,每种场景的技术栈不同,出现问题的排查成本很高; 埋点准确性的验证,需要人肉参与,不能保证完全正确,且一旦出现问题,只能随着下次发版来修复,修复问题的时间成本很高。
因此本文有非常长的篇幅来写流程问题,其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用,对用户而言是个额外的功能,因此埋点的业务侵入性很强,很容易对用户体验造成影响。别的不说,仅仅是流量的消耗,就很容被用户喷。因此,要提前想清楚,我们要采集哪些东西,因为修改方案的成本,是伤不起的。
通常情况下,我们需要记录用户在使用产品过程中的操作行为,通过4W1H模型可以比较好的保障信息是完备的。4W1H包括:
Who(谁); When(在什么时间); Where(在什么位置); What(看到了什么); How(做了哪些操作)。
规定好记录信息的基本方法之后,按照固定的频率,如每小时、每天,或者是固定的数量,比如多少条日志,或者是网络环境,比如在Wifi下上传,我们就可以开心的把埋点数据用起来了。
当然,数据记录的时效性也比较重要,但因为埋点数据通常量级会比较大,且各个端数据回传的时间不同,因此想做到实时统计,还是需要分场景来展开。在Flink技术日渐成熟的今天,全链路的实时采集与统计,已经不是什么难题。
|0x01 埋点的技术方案
在埋点的技术方案中,首先要重视的,是用户唯一标识的建设。如果做不到对用户的唯一识别,那么基础的UV统计,都将是错误的。
因此,在数据埋点方案中,有两个信息是一定要记录的,即设备ID+用户ID。设备ID代表用户使用哪个设备,如安卓的ANDROID_ID/IMEI,IOS中的IDFA/UDID,浏览器的Cookie,小程序的OpenID等。用户ID,代表用户在产品中所注册的账号,通常是手机号,也可以是邮箱等其他格式。
当这两个信息能够获得时,不论是用户更换设备,或者是同一台设备不同账号登录,我们都能够根据这两个ID,来识别出谁在对设备做操作。
其次,我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现:服务器日志、URL解析及JS回传。
服务器日志:指Web服务器软件,例如Httpd、Nginx、Tomcat等自带的日志,例如Nginx的access.log日志等; URL解析:指访问服务器时,将URL信息及携带的参数进行解析后,上传服务器,例如访问百度首页:https://www.baidu.com/s?ie=utf-8&wd=你好,我们可以获得本次访问的word为“你好”; JS回传:指在Web页面上添加的各类统计插件,通过在页面嵌入自定义的Javascript代码来获取用户的访问行为(比如鼠标悬停的位置,点击的页面组件等),然后通过Ajax请求到后台记录日志。
浏览器的日志采集种类又可以分为两大类:页面浏览日志和页面交互日志。
页面浏览日志:别名为“展现日志”;指当一个页面被浏览器加载时所采集的日志,该类型为最基础的互联网日志,也是PV及UV统计的基础。 页面交互日志:别名为“点击日志”;指当页面加载和渲染完成后,用户可以在页面上执行的各类操作,以便量化感知用户的兴趣点。
除此之外,还有一些针对特定场合统计的日志,例如页面曝光时长日志、用户在线操作监控等,但原理都基于上述两类日志,只是在统计上有所区分。
再次,我们来看下客户端的数据采集。与网页日志对应的,是手机应用为基础的客户端日志,由于早期手机网络通讯能力较差,因而SDK往往采用延迟发送日志的方式,也就是先将日志统计在本地,然后选择在Wifi环境下上传,因而往往会出现统计数据延迟的情况。现如今网络环境好了很多,4G、5G流量充足,尤其是视频类APP基本上都是一直联网,因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成,根据不同的用户行为分成不同的事件,“事件”是客户端日志行为的最小单位,根据类型的不同,可以分为页面事件(类比页面浏览)和控件点击事件(类比页面交互)。对于页面事件,不同的SDK有不同的方式,主要区别为是在页面创建时发送日志,还是在页面浏览结束后发送日志,区别在于业务统计是否需要采集用户的页面停留时长。
页面事件的统计主要统计如下三类信息:
设备及用户的基本信息,例如IMEI、用户账号等; 被访问页面的信息,例如商品ID、浏览店铺等; 访问的路径信息,例如上一个页面来源等。
最后,我们还需要考虑小程序等场景的埋点方案,小程序通常情况下,开发者会声明好相应的方法,按照需求调用即可,例如微信提供了API上报和填写配置两种方案。
埋点其实还需要考虑数据上传的方案,批量的数据可以通过Flume直接上报,流式的可以写到Kafka,或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点,有兴趣的可以自行查阅资料。
|0x02 埋点的流程规范
有了指导思路和技术方案后,我们就可以着手制定相应的数据埋点流程规范了。
笼统上,流程规范会分成五个步骤,即需求评审、埋点申请、技术开发、埋点验证、发布上线。
第一步,需求评审。
前文提到过,数据埋点的方案一旦确定,返工和排查问题的成本都很高,但数据埋点之后的分析工作,又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要,将需求内容和数据口径统一收口,所有人在一套口径下,将需求定义出来,随后业务侧再介入,进行埋点方案的设计和开发。
以前文提到的4W1H模型为例,常见的记录内容如下:
Who:设备ID、用户ID、手机号、微信识别码等; Where:在Web、移动端还是小程序下,如果是移动端,GPS地址在哪,使用的是哪个APP; When:记录日志的时间戳、日志上报的时间戳; What:操作系统、设备型号、网络环境、APP版本、当前页面、展示内容等信息; How:如果是搜索行为,则记录关联词;如果是内容点击,则记录内容ID、内容类型、列表位置;如果是交易动作,记录交易的商品ID、类型、数量;如果是支付过程,记录付款的方式与付款金额。
最后我们统计时,按照上述约定,统计用户在某个时间和地点中,看到了哪些信息,并完成了怎样的动作。上下游的相关人员,在使用这份数据时,产生的歧义或者是分歧,会小很多。
第二步,埋点申请。
当下的热门应用,大多是以超级APP的形式出现,比如微信、淘宝、支付宝、抖音,超级APP会承载非常多的业务,因此技术方案上会十分统一。
因此,当我们的技术方案确定后,通常要在相应的埋点平台上,进行埋点申请。申请的内容包括分配的SPM、SCM码是什么,涉及到的平台是哪些,等等。SPM、SCM是什么,有什么用,同样可以自行查阅。
第三步,技术开发。
当需求确定、申请通过后,我们就可以开始开发动作了,这里基本上是对研发同学进行约束。埋点的开发,简单讲,是分成行为埋点和事件埋点两个大类,每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
详细的设计规范,是需要留文档的,因为代码不能反应业务的真实意图,而不论是事后复盘与业务交接,都需要完整的文档来阐述设计思路。
第四步,埋点验证。
埋点的验证很关键,如果上线后才发现问题,那么历史数据是无法追溯的。
验证有两种方式,一种是实时的功能验证,一种是离线的日志验证。
实时功能验证,指功能开发好后,在灰度环境上测试相应的埋点功能是否正常,比如点击相应的业务模块,日志是否会正确的打印出来。通常而言,我们需要验证如下三个类型的问题:
记录正确:APP发生相应的动作,检查日志是否打印正确,如:打开页面(行为埋点)、点击按钮(事件埋点)时,是否日志会记录; 位置正确:查看SPM、SCM码与平台申请的是否一致; 内容正确:设备ID、用户ID等必须记录的内容是否正确,行为、事件记录内容是否与页面实际发生的一致。
除去实时验证,我们也需要把日志写到测试环境中,查看数据上报的过程是否正确,以及对上报后的数据进行统计,侧面验证记录的准确性,如统计基本的PV、UV,行为、事件的发生数量。
很多时候,数据是需要多方验证的,存在一定的上下游信息不同步问题,比如对某个默认值的定义有歧义,日志统计会有效的发现这类问题。
第五步,发布上线。
应用的发布上线通常会有不同的周期,例如移动端会有统一的发版时间,而网页版只需要根据自己的节奏走,因此数据开始统计的时间是不同的。最后,应用应当对所有已发布的埋点数据,有统一的管理方法。
大多数时候,数据埋点的技术方案,只需要设计一次,但数据准确性的验证,却需要随着产品的生命周期持续下去,因此仅仅依靠人肉来准确性验证是不够的,我们需要平台来支持自动化的工作。埋点的准确性,大体有两种方法保障:一种是灰度环境下验证真实用户数据的准确性;另一种则是在线上环境中,验证全量数据的准确性。因此,发布上线之后,后续的管理动作,应该是对现有流程的自动化管理,因为团队大了,需要埋点的东西多种多样,让平台自己测试、自动化测试,就是很多测试团队必须走的路。
|0xFF 行业现状
目前行业中,已经有很多比较成熟的数据统计平台,大家对于数据埋点也都有自己的方案。常见的有:GrowingIO、神策数据、百度统计、谷歌分析、友盟等。官网都有比较详细的介绍,这里不再赘述。
数据埋点只是技能的一种,通过埋点的数据,如何去做分析,其实也很重要。做过互联网的同学,基本都会有自己的宝藏库,来看看业界的同行都是如何分析问题的,著名的如艾瑞咨询的数据报告。其实再高大上的报告,归根结底,也是通过数据+模型来分析得到的结论。
最后说说自己做数据埋点方案的利弊。一些流量型的业务模式,使用第三方是没有问题的,因为第三方通常提供了很强大、很完备的功能,稳定性也有保障,但缺点是,无法做平台规则之外的数据埋点。但如果业务数据是非常敏感的,比如金融相关,那么还是建议自己做技术方案,且现有的数据埋点方法,都是基于流量分析平台来做的,对于一些偏传统的业务场景,其实并不是非常适用。
最后,数据埋点,只是一种技术或者是工具,想要得出有价值的分析成果,需要有有科学的分析模型做指导,也需要有正确的学习路线来坚持。