数据埋点四部曲之——方案设计

在一次痛苦和煎熬的酸爽经历之后,我又来了,带着对知识的敬意和向往,继续~~~

开始正题,本次续上篇《初始数据埋点——需求分析》篇,接下来我们再来聊聊数据埋点四部曲之核心输出篇——埋点方案设计。

埋点方案的目的

埋点是为了满足快捷、高效、丰富的数据应用而做的用户行为过程及结果的记录。埋点方案是也就是埋点的需求分析文档DRD文件,如同产品输出的PRD文档,在业务需求分析的基础上完整的输出埋点方案,明确埋点范围、埋点方式、埋点事件及采集的数据结构和属性特征等详细设计内容,以方便研发、测试等技术人员理解并进行项目开发,同时还可供业务人员查阅参考,理解埋点采集的相关事件及数据指标等情况,方便业务人员尽快熟悉数据结构,提高工作效率。

常见的埋点方式

常见的埋点方式主要分为三种:全埋点、可视化埋点和代码埋点,其中代码埋点又分为前端代码埋点和后端代码埋点。

全埋点

又叫做无埋点、无痕埋点、自动埋点,这种埋点方式想要实现的效果是全自动化埋点,将客户端的用户行为尽可能地全面采集,然后通过界面配置的方式对关键行为进行定义。

优势是操作简单,每次有用户行为分析的需求,不用再走一次完整的埋点流程,只用在产品中嵌入SDK,等于做了一个统一的埋点。劣势是采集到的数据分散,分析需要关联和结构化,只能针对客户端的数据采集,服务端数据是采集不到的。

可视化埋点

可视化埋点也被称为「无码埋点」,它的理念是降低实施埋点的门槛,以此来提升原来的工作流程效率。

优势:

操作简单,即时验证生效。实施埋点时,无需研发人员介入,产品运营可以直接在网站或移动应用的真实界面上操作埋点,而且埋点之后立即可以验证埋点是否正确,并且,埋点部署到所有客户端也是几乎实时生效的。

局限性:

首先,可视化埋点也只是针对点击可见元素的,一些动态页面、不可见的行为是采集不到的;其次,对于点击操作附带的业务属性,比较难实现;第三,为了确保埋点准确性,可视化埋点也逐步整合了更为复杂的高级设置,操作起来也很低效。

代码埋点

代码埋点是最经典埋点方式,实施埋点的研发将埋点代码结合到业务代码中,实现用户行为数据的采集支持任意场景。

代码埋点适合精细化分析的场景,这种埋点方式很低效,需要经历完整的埋点流程,包括业务梳理(产品运营)、埋点设计(产品运营/研发)、实施/测试/上线埋点(研发/测试)。整个过程需要多方协作,且要求产品运营也具备一定的专业水平,如果发生错漏无法快速补救。

代码埋点按照位置的不同,可以分为前端埋点、后端埋点。

前端代码埋点

前端埋点用来记录用户在客户端的操作行为。前端埋点能够收集更全面、精细的用户数据,尤其是不需要请求服务器的行为数据,但缺点在于,前端埋点的上报一般存在 15% 左右的延迟上报和漏报(客户端未联网、数据打包上报、用户删除行为数据等原因)。

后端代码埋点

后端埋点用来记录客户端进行服务器请求的日志,理论上只要客户端向服务器发送过求,服务端埋点能够收集到。相比于前端埋点,能实时采集数据,不存在延时上报,数据很准确;并且,服务端埋点支持与用户身份信息和行为附带属性信息整合;另外,每次上线新的埋点或者更新埋点时,发布后马上生效。

埋点事件触发类型

埋点事件触发类型指的是在埋点时采用什么样的方式触发埋点事件,实现系统自动采集相关数据。每种触发类型都有各自的优劣势,在具体设计触发时机时,选择哪种出发机制特别值得关注以下几点:业务含义、ID识别机制、前端软硬件环境属性获取、业务处理结果获取、数据准确性要求。

前端触发上报

用户在前端进行相应的操作时,即触发采集数据事件。

前端获取后端结果后上报

这种方式-般是由于除了记录用户操作外,连帽要获取用户操作的结果,比如需要收到 后踹结果的返回,以判断用户是否支付成功,以及失败情况下具体的报错原因,那么莫触发机制必须等到前踹拿到后端服务器处理结果后,再造行上报。

后端触发上报

这种方式是指后端处理后直接上报,比如后端处理付款请求出结果时直接后端触发上报。采用这种方式的主要好处是数据不会出现漏报,但也由于是直接后端上报,基本是拿不到用户的设备终端及软硬件环境属性的,比如用户在支付时用的是什么设备、网络环境是什么等信息。

后端获取前端属性后上报

为了解决后端埋点的软硬件环境属性问题,让前端在用户点击 “去 支付” 时,将相应的属性一并传回服务器,服务器发生 “支付成功” 时,带上相应的前端属性上报数据。当然这种方式理论上是数据准确性、完备性最高的,但同时这种方式的采集成本会比较高,会随着所有端的前后端接口做变更,因此,只有在对数据准确性、前端属性获取这两个需求都非常强时采用。

埋点事件与属性设计

事件设计做的不好,往往会给使用者带来麻烦,例如:数据定义不清楚、系统里的事件、属性、属性性值等关键参数没有做对应的中文映射,业务人员就无从下手,看到数据一团乱麻。

事件和属性设计,通常是在业务需求分析之后,确定了具体的数据分析指标之后开展的,将业务分析诉求,转换成面向开发的需求语言,让开发能看懂需要他在什么场景和规则下采集哪些数据。

事件设计

事件设计就是要采集用户行为数据,首先要根据业务分析需求明确采集的目标行为,进一步搞清楚应该在哪些地方埋什么样的点,最终输出的成果就是埋点需求文档。

事件设计可按照4W1H的原则进行事件的设计和定义,即按照“WHO”、“WHEN”、“WHERE”、“WHAT“、”HOW“,即时间、地点、人物、事件、场景,用户在什么时间什么位置在什么样的场景下做什么事情。通过这样的事件分析,对事件进行定义、描述(确定其关键属性)及属性值。

属性设计

属性设计主要是指在事件的产生时需要采集的属性信息,这些属性信息大致可分为以下四种:

①用户属性:主要指的是who触发事件的人的信息,如身份信息、动态属性(如会员等级、角色、活跃度等信息);

②事件属性:通过什么方式触发的事件,主要是具体的操作行为,如来源、操作方式、操作结果、时长等;

③对象属性:操作对象自身的属性信息,对象的特征、对象的标签。常见的如电商中的操作对象,用户点击商品,那么“商品”即对象,这个商品具有的特征及数据标签信息等。

④环境属性:指的就是触发事件时的硬件设备、软件、地理环境等内容。

针对这些属性特征,这些属性往往会有自己的特征值,我们在做属性设计时需要对每一个属性值进行定义,采集时对相关数据进行采集并结构化存储。

通过对以上方案设计要点的分析之后,那么关键事件来了,方案要怎么写那?在研究了一些精品之后,总结到以下几点,希望可以帮到大家

※   确定埋点方式:方案中需做好规划,明确事件的埋点方式。

※   需求内容详情:必须包含以下内容,清晰的标书事件、属性及属性值。

        事件:定义事件

        属性:描述事件

        属性值:具体行为描述,定量定性


~~~以上本次完成第二次作业,这次没有上次那么匆忙,前期看了一些文章,构思了文章的主体结构,按照我的理解开始分类罗列,阐述完了基本思路和概念方法之后,貌似就差我的案例需求文档了,后续补上,也给大家留点念想,看看笔者还有没有余力((*^-^*)(*^-^*)(*^-^*)

推荐阅读更多精彩内容