【埋点体系】(二)-埋点设计、管理与应用

2024-06-09 16:58

本文主要是介绍【埋点体系】(二)-埋点设计、管理与应用,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、埋点的管理

1.1 新增埋点设计

1.1.1 埋点指标定义-事件表

一款互联网产品每天产生的数据是庞大杂乱的,全部都存下来会占据硬盘空间,而且,不加定义和标记的数据也很难使用。因此,在初期的数据建设阶段,先要做的是定义想要的数据,告诉前端开发和后台的同事,你想要的数据有哪些,定义这些数据的字段包括但不限于以下字段:

埋点位置:平台覆盖了APP、Web和小程序平台,其中有部分核心功能、页面在三个平台都有涉及(类似于电商平台的商品详情页),分开管理会造成指标冗余,因此对于多平台存在的核心指标,采用的是统一事件名定义,不同平台触发时,数据上报到同一个事件名上,通过平台类型(platform_type)进行拆分;

功能模块:对应埋点所属的大功能板块,如【电子书】功能模块,会尽可能把属于电子书的埋点事件放到该模块进行管理。这里解释下没有向下拆解子功能模块的原因:对于我司业务,区分度比较高,功能模块+具体事件名就能够快速定位到想要的指标了。这点因公司而异;

埋点事件:这个文档我是同时要给开发和运营的同事看的(分开维护的成本太高),对于运营同事来说,他们要关注的字段是下面这些:

 而开发同事关注的是下面这些字段:

 因此针对同一个埋点,至少要考虑的是以上这些字段,更大平台的埋点字段会更多。

其中,比较难处理的是【触发时机】的准确定义和描述,举个例子,某页面的pv数据,触发时机定义成加载和加载成功,会是完全不同的数据;又比如,首页模块(也有叫楼层)浏览,模块长短不一,到何种深度会触发对应模块的浏览,需要定义时想清楚,与开发沟通实现细节,避免后期踩坑;

事件变量定义:用来定义事件的参数,也可以理解为事件维度(也有一些实践是把事件表和维度表分别进行管理,我司实践是把二表合二为一)。该字段决定了事件的颗粒度,直接影响到事件下钻的颗粒度,对于数据PM来说,平台不同位置的事件抽象后,尽可能提取出公用事件,然后通过事件变量进行区分,能减少:指标冗余、指标管理工作、培训成本,以及使用者的学习成本。

当然这里也并不完全执着于抽象公用性,对于数据PM和开发来说,指标约精简越好,便于理解和管理,但可能对于运营同事来说,学习和使用成本高企,数据产生了但无法最大化应用侧价值,那就得不偿失,所以需要平衡。

举一例,电商产品,商品详情页的事件变量怎么设计,见下图:

这里你可能会有疑问,如果是传一个【商品id】,其实也就可以通过【商品信息表】,把【商品名称】、【品牌】、【一二级类目】给查出来了,为什么还需要传?

这里就涉及到指标管理与数据使用便捷性的权衡:如果不传,在使用的时候免不了要跨表联查,是比较影响使用效率的。在指标管理时常需要通过用空间换时间的方式,来保证数据能比较高效使用,最大化数据的价值。

其他说明:变量值类型,比较常见的有:int、float、boole、string、timestamp;埋点形式,对于自己研发的数据采集系统,一般前端埋点和服务端埋点可以了,如果外采第三方数据采集服务,可能还会有全埋点(详细见上篇文章);埋点版本和日志,则是帮助你和开发快速回忆这个点的前世今生。

牢记:好好记录指标备注及变更日志。这个工作能让你后面少踩太多坑了。

以上,综合下来,以电商商详页举例,一个埋点事件最后的字段如下:

 1.1.2 埋点指标定义-用户表

用户表,记录用户信息、用户属性的表,通过用户的唯一标识(user_id)能够将事件表和用户表两张表进行关联。事件与用户实现关联,事件表里一条条的数据记录,就不会再是孤立的统计数字,而是能够与具体的用户产生关联进行分析,或者用行为来圈定用户,给用户设定分群和标签。

用户表的自定义维度设计与业务关联度最高,除了常规的用户id、用户昵称、注册时间、首次登陆APP时间等字段外,其他偏业务属性字段需要一个比较全局的视角,不仅要与数据运营方沟通,而是要与公司每一个有分析诉求的部门进行沟通,采集他们的数据分析诉求,来提炼抽象出比较通用的用户表。

如上面提到的,如果只是从事件表里把上报的数据聚合成统计数字或者图标,是没有很大意义的,还要能够下钻进行分析。事件表中变量字段的设计是为了从事件反映的用户行为侧进行下钻,而用户表的属性字段则是基于从产生行为的用户本身进行下钻。

举简单一例:当日商品详情页的总浏览数据是上升的,但是总GMV确没有明显提高,从事件侧分析,发现某类异业合作主推的单品商详页浏览数据上升,其他品类商详页没有明确上升;从用户侧分析,该类单品新增流量主要来自于渠道A。

从此得出的初步判断是:1)单本对渠道A的用户拉新效果明显;2)但是该类用户被吸引来了,却没有下单,很奇怪,需要确认投放落地页与站内商品信息是否一致,尤其是价格;3)该类用户对平台其他商品的兴趣不高。

说回用户表的属性字段设计,回到那句核心:采集共性诉求,提炼出通用、容易理解的用户表。这个工作其实并不难,考验的是数据PM沟通、提炼真实诉求,并整合成具体的需求的能力。以我司做内容服务的平台举例,用户属性表如下,基本覆盖了通用的用户群的分析:

1.1.3 埋点指标定义-默认属性

除了前面提到的自定义事件和用户属性外,一般客户端或者第三方数据采集SDK还会采集一些默认的属性信息,这些可能不需要你单独去定义,但数据PM需要去了解平台获取的默认字段有哪些。

 

 

 1.2 通用埋点设计

在自定义埋点设计中,有一些通用的事件往往是比较复杂的,而且随着业务发展,会变得越来越复杂。比如,APP平台的分享事件,如果按功能模块,每个功能模块都设计了自己的分享事件,则这个事件会越来越分散,且想聚合做复合指标时,如通过分享/日活来衡量内容质量,分享事件要先聚合平台各功能模块的分享事件,太分散会产生应用上的问题。

所以,我的建议仍然是将通用类型的埋点统一进行管理,通过变量字段进行拓展,来满足多功能模块的埋点需求。还是以分享事件举例,可以通过多个变量来进行区分。

对于通用埋点,有更新时(上新功能,或者下旧功能),就将对应type字段的埋点和值进行更新即可。(另:写上指标变更记录)

1.3 数据指标地图

数据能力推广的第一个难点,是让平台上有哪些数据让大家知道。一个是在各平台埋设的指标,我曾经采用的是excel的方式进行管理,问题是指标一多起来,找起来不太方便,对于定义者(我)来说自然很容易找到,但是对于使用者来说则不太友好。即使搜中文名称,也会存在同一个地方,大家用不同的关键词去搜索,比如:模块、版块、板块。

因此在数据指标表的第一个sheet,设计了一个数据指标地图,将不同功能模块的数据指标进行了拆解和说明,运营同事找数据指标之前,先打开指标地图大概定位,然后再去对应的sheet表中寻找对应指标的细节定义和可下钻的维度信息。

 另一块就是数据仓库的各种表的定义。从数仓里自助取数时,会有以下的问题:有哪些表、表格对应的是哪块业务的数据、有哪些字段,字段的含义是什么?这个需要和大数据组一起来明确具体内容了,这个工作并不复杂,就是需要开个小会进行确认,并且约定好,新增表格时,及时更新对表格的解释。

1.4 版本迭代功能埋点管理

随着版本迭代有新功能的埋点,或者针对之前功能的优化,所以需要对之前埋点进行调整。从埋点管理的角度,新增/修改的埋点,需要整合到之前的埋点系统里,这样能够方便使用者查阅整体的埋点明细。

下面是我基于使用Excel来管理APP版本迭代中埋点更新时的解决方案,我并不认为是最优解,所以仅做参考。

背景:APP迭代周期为两周一个版本,有3位功能产品经理,他们负责具体功能的设计和产品跟进,在设计产品功能时,也会提交与功能相关的埋点需求,在经过功能评审后,会和我就功能埋点进行一次沟通,然后将确定的埋点需求梳理出来。

处理流程:功能在经过需求评审(=技术评审)后,基本确定了这一次要做的功能点,因此也可以梳理出要做的埋点有哪些。所以从这个节点的处理流程是:

1)功能产品经理(后称功能PM)梳理相应的埋点清单(按照符合总表设计逻辑的字段进行梳理);

2)功能PM与数据产品经理(后称数据PM)做内部评审,评审目标是针对功能点梳理出与总埋点文档保持兼容、同时又可以拎出来后给到开发看的埋点清单;

3)功能PM与开发进行埋点需求评审,数据PM可旁听。

举一例:功能产品对签到功能进行优化,涉及到新增一些页面的分享功能,其最初提交的埋点需求如下图,标红的是分享相关的埋点需求:

(数据PM需要要求功能PM按照统一的字段进行埋点的设计,初期的事件定义或者变量定义或许不规范,没关系,这个能力可以随着做几个版本逐步提高,但是字段规范一定要先定义好

图11:功能产品提交的相关埋点清单

在评审这期埋点前,数据PM查看在总表里,有分享相关的埋点:

图12:查阅总表,分享事件之前已经有签到功能的埋点 

根据我们前面提到的原则,类似【分享】这类通用的功能组件,不要重复造轮子,而是要统一到一个事件上,通过类型来处理,因此,针对例子中的功能点,也将其提出的分享埋点,合并到总表中,如下图:

图13:通过新增类型解决埋点需求 

然后,功能PM将仅该版本所涉及到的埋点拎出来,单独整理一份埋点文档,这份文档是单独给开发来看的,这样做的好处是:让开发同事只关注这个功能点相关的埋点就可以(我习惯通过颜色标记来进行区分):

 图14:给开发看的埋点文档

如果是第一次这样做,需要跟开发说清楚:这份文档里标颜色的,是这个功能迭代中需要新增/修改的点,没有在文档里看到的type类型的埋点,不是删掉,而是不要动(曾经有位憨厚的小哥,因为没沟通清楚,认为不在表格文档里的,都是要删了的,删了一半了,才找我沟通......)。

关于版本迭代中的埋点管理,相比于excel一定要更好的工具化的管理办法,之前跟一个同行聊过,他们采用的方案是,做一个web端平台,可以看到所有的埋点。同时,功能PM可以在该平台上按照字段要求提交自己的埋点需求,然后走审批流程,能够进入开发的埋点,会打上版本标记,待上线后,对应的埋点会出现在平台总表里,供使用者查看。这个方案就很不错,本来计划推这套平台,后来我因个人原因离开了这家公司,就没有再继续。

上面这个方案适用于有一定体量的公司,个人认为在C轮之前的公司,大多都是没有精力去做这样一套数据指标管理平台的。

1.5 埋点实践中可能会遇到的问题和解决方案

1.埋点设计过程中不注意事件和属性的命名规范,导致埋点无法使用或难以理解

这个问题在很多企业中都有出现,一开始的时候随便起一个事件名或属性名,也没有标准的规则去限制。这种做法在埋点比较少的时候还勉强适用,但是一旦业务线增加,埋点数量成倍上升的时候,就会出现混乱:比如有同事离职,下一个同事交接项目时,根本无法理解前一位同事是如何设计埋点的;还有就是如果埋点设计工作是由不同业务线的同事完成的,没有命名规范的话就会出现混乱,开发同事和分析数据的业务同事都会相当痛苦。这些问题会导致之前辛辛苦苦开发出来的埋点无法被使用,进而需要额外花很大的力气去做数据治理。

与其在后面亡羊补牢,不如在前期就定好规则让所有同事去遵守,减少后续不必要的治理成本。埋点事件的命名规则没有标准答案,只需要结合企业目前的发展现状,比如拥有产品线(app、小程序等)的个数、业务线个数等进行制定即可。一般来说,可以依照“产品线_业务线_页面名称(按钮名称)_动作”这个规则,比如说“app_ShengXian_BuyNowIcon_Click”(app中生鲜业务线内“立即购买”按钮点击),企业也可以根据部门和业务线划分去自定义规则。

2.埋点可解释性差,需要花费时间进行理解

如果第一个问题说的是埋点命名不规范,那么第二个问题就是使用埋点的人不知道某个埋点是埋在了哪里,以及该埋点的确切含义,想要使用某个埋点也是胆战心惊,需要不断询问埋点开发的同事或者靠自己的理解瞎猜,这极有可能会导致数据结果偏差,进而得出错误的业务决策,而且需要额外花费时间进行理解,降低工作效率。

解决这个问题可以通过“埋点地图”的方式实现,方法也很简单,就是每次在设计埋点的时候,顺手把该埋点涉及的页面或者按钮截图并圈选,放在埋点需求文档的第一列或者最后一列,如果有必要的话可以在备注列进行补充说明。这样可以方便开发同事理解需求,避免埋错点,也可以让使用埋点的业务同事快速了解点位埋在了哪里,减少无效的沟通成本。如果有余力的企业还可以开发一套属于自己的埋点管理平台,业务同事将要埋的点位截图上传并做简单说明,开发同事依照平台上的需求进行埋点,验收上线后即可便捷使用,这样就可以减少维护文档带来的不便,尤其适用于业务线多,场景复杂的企业。

3.埋点冗余,浪费开发资源

即使解决了问题(1)和(2),还是不可避免会出现埋点事件或属性的冗余,因为每位同事的埋点设计习惯不同。比如同样都是页面浏览这个行为,有的同事会用page_name(页面名称)这个属性,有的同事会用page_title(页面标题),但是这两个属性都代表用户浏览的是哪个页面,很明显可以统一这两个属性。从这个例子可以看出,如果不加以限制,就会出现事件或属性冗余的情况,浪费开发资源和服务器资源。

为了能让各个事件和属性名称重复利用最大化,在前面埋点规则和埋点地图的基础上,我们可以设计一个“埋点资源库”,内含所有之前已经被使用过的埋点事件名和属性名,如果在后续设计过程中发现有的名称可以被重复使用,则可以直接利用而不是重新设计。但是,如果某个企业是通过文档去迭代埋点的话,该方法会比较麻烦,因为检索之前用过的名称需要时间和精力,如果有能力且有资金和资源的话,最好是设计在第(2)个问题中所述的埋点管理平台,直接通过系统管理埋点资源池,方便又高效。

二、埋点应用

埋点有了,能采集到之前获取不到的数据了,下一步该如何使用,下面是从我的经验总结的,数据从浅层应用,向深层应用传递的应用场景。

2.1 可视化

结合业务日志,以及埋点采集上来数据,如何让数据立刻产生价值?我建议先去做可视化。建议原因:前期的数据采集、录入、清洗耗时耗力,对于领导来说,铺人力做一件看不到产出的事情,时间久了自然有点质疑。

而对于数据本身来说,完成清洗后的数据能最快应用的方面就是做可视化,对于每天要看excel数据的领导来说,可视化的东西也是能让ta感到明确不同的产品,取得上层认可,对于后期推进数据项目绝对有利。

在做可视化这个阶段,建议使用已经成熟的产品框架,不要花精力去自研。说白了,这个阶段的主要目的是让数据采集的产出最快体现出价值来,得到相关部门认可,给自己项目团队成员以信心的,所以拿来主义,一切从简。

2.1.1 数据大屏

数据大屏的视觉冲击力强,对于关注整体指标的领导层来说,大屏解决了他们快速掌握全局数据的需求,另外,如果贵司常要接待其他单位或者到外面汇报、参展,动态数据大屏绝对是曝光度最高的产品。

 2.1.2 开源数据展示工具

数据大屏满足了展示类需求,但是定制化一点的、操作类需求,数据大屏满足不了。这时可以考虑使用别的工具,其核心就是通过该工具平台,连接数据库,读取数据后进行展现,并且可以按照一定的维度,如日期、周期、item名称等维度聚合数据,形成一个个看板。看板里的单图支持源数据下载、和简单的SQL取数。能够解决略进一层的数据展示和分析诉求。

工具推荐:Superset、Grafana

2.2 数据应用平台

数据终究要产生业务价值的,上面提到的数据展示工具,无法以可视化形态做业务分析。数据需要结合具体的业务场景,然后选择成熟的分析场景,如:事件分析、漏斗分析、留存分析、归因分析等,以及更深度的用户画像、精准营销,才能真正赋能业务。

这类数据应用工具,目前已经有成熟厂商提供了标准化产品,如果公司规模没有达到自研数据平台时,建议采购。推荐平台:GrowingIO、神策、TalkingData

2.3 数据仓库

数据采集、录入,最终会落入到数据仓库中,成为数据仓库中的“弹药”。从19年大火的“数据中台”,去掉面子,里子就是一个数据仓库。数据仓库汇聚各业务端的原始数据,和主题数据,其建设过程是一个随着业务发展不断更新的过程。只是做数据的ETL本身并不是数据仓库的价值,其核心是能够收录好业务侧需要使用的数据,或者在业务侧提出新的数据需求时,能够快速响应。

按照数据仓库设计的经典三层结构:ODS层、EDW层、DM层,数据产品经理在数据仓库建设中的工作职责,是:

1)约定进入ODS层的原始数据的维度、周期;

2)定义EDW层主题宽表的字段、周期;

3)设计DM层应用表的字段、周期(需要结合具体业务,设计尽可能通用的主题表、应用表);

4)设计监控方案,ETL过程中异常需告警,并及时告知数据应用侧有污染数据。

参考资料:

1.微信公众号(大数据学习与分享)-《数仓埋点体系 | 埋点设计、管理与应用》

这篇关于【埋点体系】(二)-埋点设计、管理与应用的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1045763

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

中文分词jieba库的使用与实景应用(一)

知识星球:https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义: 精确模式(默认模式): 全模式: 搜索引擎模式: paddle 模式(基于深度学习的分词模式): 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

csu 1446 Problem J Modified LCS (扩展欧几里得算法的简单应用)

这是一道扩展欧几里得算法的简单应用题,这题是在湖南多校训练赛中队友ac的一道题,在比赛之后请教了队友,然后自己把它a掉 这也是自己独自做扩展欧几里得算法的题目 题意:把题意转变下就变成了:求d1*x - d2*y = f2 - f1的解,很明显用exgcd来解 下面介绍一下exgcd的一些知识点:求ax + by = c的解 一、首先求ax + by = gcd(a,b)的解 这个

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动,这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升:减少抖动,提高图像的清晰度和细节表现力,使得监控画面更加真实可信。 - 细节增强:在低光条件下,抖

hdu1394(线段树点更新的应用)

题意:求一个序列经过一定的操作得到的序列的最小逆序数 这题会用到逆序数的一个性质,在0到n-1这些数字组成的乱序排列,将第一个数字A移到最后一位,得到的逆序数为res-a+(n-a-1) 知道上面的知识点后,可以用暴力来解 代码如下: #include<iostream>#include<algorithm>#include<cstring>#include<stack>#in

zoj3820(树的直径的应用)

题意:在一颗树上找两个点,使得所有点到选择与其更近的一个点的距离的最大值最小。 思路:如果是选择一个点的话,那么点就是直径的中点。现在考虑两个点的情况,先求树的直径,再把直径最中间的边去掉,再求剩下的两个子树中直径的中点。 代码如下: #include <stdio.h>#include <string.h>#include <algorithm>#include <map>#

【区块链 + 人才服务】可信教育区块链治理系统 | FISCO BCOS应用案例

伴随着区块链技术的不断完善,其在教育信息化中的应用也在持续发展。利用区块链数据共识、不可篡改的特性, 将与教育相关的数据要素在区块链上进行存证确权,在确保数据可信的前提下,促进教育的公平、透明、开放,为教育教学质量提升赋能,实现教育数据的安全共享、高等教育体系的智慧治理。 可信教育区块链治理系统的顶层治理架构由教育部、高校、企业、学生等多方角色共同参与建设、维护,支撑教育资源共享、教学质量评估、

AI行业应用(不定期更新)

ChatPDF 可以让你上传一个 PDF 文件,然后针对这个 PDF 进行小结和提问。你可以把各种各样你要研究的分析报告交给它,快速获取到想要知道的信息。https://www.chatpdf.com/