如何从 0 到 1 构建埋点体系

2022年05月14日 阅读数:6
这篇文章主要向大家介绍如何从 0 到 1 构建埋点体系,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

本文根据资深数据产品经理陈家崑《从 0 到 1 埋点体系指南》的分享内容整理。主要内容以下:
· 首次开荒指南
· 埋点体系迭代指南
· 体系落地指南
· 数据埋点实操案例前端

1、开荒

所谓开荒,指的是初次接触埋点或神策的阶段。算法

1.定位:一个容易忽视的仪式小程序

关于埋点系统的定位,须要想清楚三个问题:
第一,有没有清晰的认知,埋点系统所承担的用途是什么?
做为业务埋点对接人,须要想清楚埋点系统所承担的用途是什么?它在整个公司业务体系中的定位是什么?若是没有对这个工具定位好,后续推广使用及跨部门合做时,可能会产生冲突或者与其余工具的定位重复或矛盾。
第二,有没有明确的需求,而不是“为了埋点而埋点”。
在面临具体埋点需求时,须要进一步明确它的使用价值是什么、能为业务解决什么问题。在我过往接触过的业务线中,有的为了埋点而埋点,没有想清楚具体该怎么使用,这样很容易形成大量垃圾数据。
尤为当用户客群较大时,对应的数据量也是很是凶猛的,经常使人措手不及,好比使用若干个月后,发现线上存储空间不足,系统性能不够等,这些问题的治理繁琐又困难。
第三,有没有明确的规划?
在实际调动公司资源去落地构建埋点体系时,须要必定的节奏。由于正常产品开发也须要遵循着这样的原则,要进行必定的规划。
总之,基于这三个问题,咱们要考虑清楚定位。后端

2.把埋点体系做为数据中台或 BI 体系的重要组成部分服务器

埋点系统和数据仓库、分析体系、预警系统等子系统同样,须要放入整个公司的业务体系和数据体系里,方便统一规划。
不得不说,神策的不可替代性很强。由于埋点采集技术难度较大,若是没有经验的话,成本就比较高。
至于成为整个数据体系有什么样的好处呢?
首先,能够把行为数据做为数据体系的一部分进行整合。
行为数据,换一个角度看也是一种业务数据,这种数据在业务系统里没法采集。建议把它做为一个数据源,方便把整个用户行为数据关联到业务或外部数据。
其次,能够把此时此刻的用户数据特征做为属性补充行为数据。
整个数据体系中,有些数据在前端埋点时没法采集。好比在作某些优惠券逻辑时,只会传一个 ID 到前端页面上,实际再去埋点时,也只能拿到这些 ID 信息,其余没法采集。解决这个问题有不少办法,但经过前端业务侧解决的方式,一般风险比较大,由于要考虑接口设计、性能及各类并发问题,若是把这些数据问题放在业务侧,将会受到必定的阻力。
而若是经过数据侧解决会相对容易,好比把 ID 采集回来后,它的优惠价格、历史信息及其所承载的数据含义等信息,在数据侧均可以直接关联。架构

3.以项目视角看产品并发

之因此谈到项目化,由于埋点体系搭建既是一个产品规划问题,也是一个项目管理问题。建议在开荒阶段,就要把这个项目的过程筹备好。
接下来根据本身过往所经历的项目筹建经历,跟你们分享一些实操经验。 如何从 0 到 1 构建埋点体系_埋点 app

第一,树立项目意识,由于它既是一个产品规划问题,也是一个项目管理问题。
第二,制定标准化流程,包括需求收集、讨论、评审,到开发、测试、上线、迭代等,任何在先后端进行开发所须要经历的过程,一个都不能缺乏。
若是缺乏了某个环节就容易产生大的问题,好比若是没有测试,那数据质量就没法保证,一旦产生问题,如何修复大量的数据,如何补充属性纠正问题,都是比较麻烦的事情。
第三,明确项目内外的角色和分工,以我过往项目经历为例,当时把来自不一样的业务线的同事,好比客户端、策略后台算法、分析师等组成虚拟团队,集中明确各自分工,这里特别强调下技术和测试环节。
技术环节,建议项目相关的技术同窗都要去熟悉相关文档,若是不熟悉就直接上手操做,加上不一样技术同事轮流去作,会很难沉淀下来一些方法论。
测试环节也同样,如何使用埋点工具、如何在控制台排查问题,测试同事都须要必定的时间去熟悉。可能只有通过两次版本迭代后,才会对整个流程熟悉,作到内心有数。建议你们重点培养测试同窗对数据问题的敏感性。只有保证整个测试环节的质量没有问题,后续的分析算法的应用才能真正能发挥出价值。
第四,确认技术点,这里须要注意一些细则,好比用户 ID 是一对一的关联,仍是一对多的关联?以电商公司为例,涉及到买手机的场景时,不少用户都是拿着旧手机买新手机,建议作成一对多的关系,由于不少用户拿来的旧手机基本不用了,若是成交,作成一对一关联的话就会被误认为是两个用户。
第五,关于使用边界或项目边界问题,在平常作埋点时,常常会面临不一样的业务线同步进行,这时就须要明确各业务线的边界。涉及到各业务线私有的东西,每条业务线本身负责,而涉及到公共的东西,须要你们一块儿去完善和维护。
第六,关于项目筹划,建议把相关责任人用清单的方式列下来,明确各自责任,而且经过邮件等方式公开留底,后续再去推广业务时会比较顺畅。ide

4.需求整理最好前置微服务

第一,埋点规划。在对埋点需求进行规划时,切忌一次性完成大量需求,最好对需求进行优先级排序处理,这样有助于管理产品文档,若是一次性处理几百个埋点,加上涉及到跨部门协同,撰写时不免会有纰漏,因此埋点规划的节奏很是重要。
第二,用户属性。设计埋点时要考虑用户属性设计。设计用户属性时,须要遵循一个最基本的原则,就是经过事件分析系统、用户标签、用户画像系统计算出来的东西,就不要单独上报埋点。
好比想要获取用户近几日的消费单数,或是确认他是否为 VIP 用户,这些数据需求均可以经过事件计算出来。若是再单独埋点,不但会浪费开发资源,并且上报来的结果远不如整个系统内环计算来的灵活。
须要注意的是,下面两个属性很是值得埋。一个是静态属性,好比说用户年龄、性别等,这些静态属性没法算出来,颇有埋点的必要。另外一个是经过算法和数据挖掘产生的挖掘标签,也值得单独埋点。
第三,了解预制属性。建议你们多多通读了解预制属性,一方面是防止事件所采集的属性,跟预制属性有所重叠。
另外一方面,经过预制属性,能够了解各端的数据特性,好比小程序的特性如何,它在封闭环境里能够返回哪些数据、不返回哪些数据?好比 H5 特性如何,客户端特性如何等等。
第四,肯定节点口径。一般,一个事件会有不少下沉节点,好比某个按钮的点击事件,从用户在 APP 层的点击,到 APP 去请求应用接口,到服务器去肯定接口,接到了请求后,到业务侧后台系统处理这个请求时是否成功,再到最后是否能把结果成功返回给客户端。
所以,整理需求作事件设计时,必定要明确它的节点口径,明确须要在什么样的层级采集。具体来看,一方面须要想清楚在哪一个节点采集,另外一方面也要看具体需求,在什么样的环境采集。一般来讲,越靠近 APP 端,它所采集的事件越大,但可能对比业务端来讲,它的准确性会相对较低。

2、迭代

完成了前面的基础工做后,埋点体系通过 1-2 个版本后初见成效,这时开始面临如何拓展使用,如何管理大量的数据需求的问题。同时,还伴随着以下问题:随着时间的推移埋点文档越写越多、越写越乱;不清楚的埋点定义愈来愈多;相关项目人员离职,未作相关交接等。

1.事件分类

如何从 0 到 1 构建埋点体系_埋点_02 

根据所要埋的事件类型进行分类颇有必要,一方面方便对需求进行优先级确认,另外一方面设计埋点时,不一样类型的事件须要对应各自的方法。
(1)通用事件
对于通用的、泛化性的、活动等次要流程事件,能够进行抽象化处理。 好比,在平常工做中,常常遇到市场或活动运营同事提出某次活动的埋点需求,若是每次活动都单独处理成一个事件,随着时间的推移将会致使同类事件越积越多,不利于管理,所以对于这类相关的事件,须要进行抽象化的通用事件处理。
(2)边缘事件
所谓边缘事件,指的是零散的只查看点击或浏览行为的事件,好比 APP 端诸如设置、客服入口等功能按钮。
处理此类事件,有两种常见方法:
一种是作一个最基本的自定义事件容器,而后把相关按钮名称、所在页面及其余零散东西抽象化后放进去。
另外一种是手动纠正一些全埋点进行上报。之因此要手动纠正,是由于先后端的技术架构不一样,没有办法 100% 地适应全埋点,当全埋点数据出现未知或没法采集时,须要手动调 SDK,纠正所要采集的页面。

2.事件管理方法

当处理的事件数量愈来愈多时,就须要进行相应的管理,具体方法以下 如何从 0 到 1 构建埋点体系_大数据_03 

第一,关于埋点系统的 WIKI 文档必定要放到云端留存,方便项目管理和及时查询;
第二,为了方便跨部门沟通和先后交接,埋点体系项目组成员在撰写 WIKI 文档时,最好明确出一套文档规范,防止以各自形式撰写,致使后续加入的人查看时摸不着头脑;
第三,经过事件描述寻找页面和翻查代码来修补问题事件,方便解决历史遗留问题;
第四,按期进行清点和梳理,具体能够在 admin 帐号里进行系统诊断,按期地导出诊断报告,便于对不合理、低性价比事件及时进行清理。

3.问题排查技巧

问题排查这块,主要讲平常应用中常遇到的三个问题。
第一,数据一致性问题。当埋点系统收集的数据和业务端、BI 等系统数据节点或口径不一致时,该如何处理?
好比,关于新用户与老用户的定义差别,当埋点所定义的概念和市场及运营端同事的口径不一样时,就会形成数据对不上的问题。如何应对这种状况呢?建议先跟运营或是对应的产品同事了解相关指标,它的口径和节点是怎样的,及时去修改属性和描述,好比不要笼统地定义为老用户或新用户,而是定义为注册用户、认证用户或下单用户等。
第二,关于准确性挑战。把埋点系统的数据与业务端、BI 端数据进行校对,基本上三个数据大致一致。固然也不排除三端同时出现数据错误,这须要根据实际状况进行纠正。
第三,关于未知和空数据。出现这种状况的缘由有不少,但有一种状况咱们能够提早避免,就是在事先设计和定义属性时,必定要考虑到这个属性的空状态下该如何上报?是 0 仍是空,具体如何处理须要提早考虑清楚。

4.多项目处理方法

若是同时接到多条业务线的埋点需求时,该如何选择,是在一个项目里埋多个应用,仍是把它们隔离成不一样的项目?若是作项目隔离,又涉及到从头开始作的问题,成本较高,这时又该如何处理?

 如何从 0 到 1 构建埋点体系_埋点_04 

首先,用户是最重要的基准,是否须要区分项目,取决于应用用户的关联性。
若是业务线之间没有任何用户关联,这种状况就须要隔离处理,不只数据和系统须要隔离,事件管理也须要隔离。好比涉及到属性在命名上的冲突,或某些事件的冲突,会致使后面作埋点时,相同命名的属性会报错。 至于在实际处理时,是进行项目合并仍是隔离,须要对数据互通与数据管理问题进行权衡。一方面是要考虑到数据隔离后,后续不便于作关联分析,另外一方面也要考虑到若是项目关联过多,会致使管理难的问题,具体抉择须要具体权衡。

5.巧用数据导入

数据导入做为一个小工具,能够解决老用户标注问题,及时补充老用户数据。
在业务上线以后,一般那些在埋点以前已有的老用户,会被错误地定义成新用户,这时就能够经过数据导入工具,导入存量数据解决老用户标注问题。
其次,经过这个工具,还能够修补由于错误埋点而致使的数据问题。
最后,这个工具能够对数据维度表作有力的补充。好比采集来的订单数据里,有不少 ID、优惠券、活动等信息都没有作关联,这时经过数据导入工具,能够补充维护商品表信息,而再也不须要额外地改造业务侧数据。

3、如何落实应用?

1.推广使用方法

推广使用通常有三种方式:

 如何从 0 到 1 构建埋点体系_大数据_05 

第一,平常培训,即对业务方的产品交付进行培训讲解。
第二,内部资料,编写内部资料、说明手册,有助于持续输出。
第三,保持沟通,项目内外保持沟通,保证埋点的准确及迭代。
首先,这三个推广方法息息相关,最好同时进行。
其次,所讲的文档要跟平常的培训一一对应,考虑到产品相对复杂,加上人员迭代,在编写内部资料时最好写得详细,这样能够减小不少没必要要的重复沟通。
最后,要和业务同事保持沟通,有助于后续更好地优化这套埋点体系。

2.渠道管理指南

说到渠道管理,一般你们都会经过渠道标识、活跃留存、漏斗等工具进行渠道评估。在实际应用过程当中,不夸张的说,神策的渠道管理体系是我见过最好的一套管理体系。

 如何从 0 到 1 构建埋点体系_埋点_06 

过往遇到的其余关于用户渠道管理体系,大多只有一个渠道标识。若是可能,建议你们仍是尽可能经过多维度的渠道标识规则,完善现有体系。好比某用户重新浪微博来,这是一层渠道标识,那它具体从微博的哪一个活动来的呢,就能够再去打一层渠道标识。
另外,经过分析渠道的用户数据表现能够了解重要的用户属性,从而赋能业务。
好比,经过渠道数据能够宏观地看到从微博活动过来的用户有什么特征?同时能够细分微博活动效果,好比某个帐号或某次活动具体效果如何?再好比,从抖音来的用户和从微博来的用户各有哪些不一样的特质,它们的转化率有何差别?根据这些分析结果,不断完善市场投放思路。

3.小工具使用技巧

这部分主要讲一些实用小工具,它们能够帮助咱们更好地使用神策。 第一,廉价存储,当业务积累了大量的事件数据后,一般会发现集群存储线上热数据存储空间满了,这时要及时进行冷数据分离,多历史数据进行归档。由于它的查询频次较低,平常价值也不大。
第二,数据导入工具以前已经作过详细介绍,这里再也不重复赘述。
第三,关于 JDBC,当咱们把 BI 侧的行为数据和用户数据须要进行关联时,能够考虑经过 JDBC 直连把数据拉出来进行分析。
最后,重点分享 MQ 的妙用。在后端埋点时,会遇到一个很大的问题:当在集群上去部署 Log 服务时,若是服务没起来,落到集群上的数据没法上报的,这会致使数据丢失。这种状况对于后端埋点上报能够说是一个灾难性的问题。那须要怎么解决呢?
其实若是企业内部有微服务体系的话,建议把后端埋点作成一个独立的微服务,而后再去总线抓全部的事件,定义注册用户、订阅用户下单等。同时这样作还有一个好处,就是咱们从用户侧收集来的数据订单能够和 BI 侧、数据侧进行更详实的关联,这至关于在入库以前作了进一步的数据处理。
此外,神策系统里的 Kafka 等应用也支持功能迭代。好比订阅用户的启动事件、订阅 VIP 用户的启动事件、订阅用户的下单事件等,均可以经过神策系统导出来。

4、数据埋点实操案例

最后,分享一个我以前作的项目,一个实操案例。

1.什么是 GBDT?

以前业务方有过这样一个需求:点击过哪些事件的用户,比较有可能成为下单用户?中间尝试了不少分析办法,但我最终选择经过数据挖掘,经过 GBDT 来找答案。
什么是 GBDT?简言之就是:Gradient Boosting Decision Tree。这里不详细展开相关定义。本质上,它解决的就是找到那些拥有某些特征的用户,就应该是业务的下单用户,而后再把这个模型套进来,从而找到那些最终没有下单的用户。
选择 GBDT 其实有两个缘由:
第一,特征清晰。这种方式便于特征工程的处理,经过它能够很简易获取清晰的特征。经过埋点系统能够对相关数据进行提取,甚至大概有一些 Python 基础就能够完成。
第二,泛化性强,对新数据的适应性强,适用于较为复杂的行为数据特征做为样本。在埋点上用这个模型,性价比很是高,能够解决不少回归问题。

2.具体实践流程

如何从 0 到 1 构建埋点体系_大数据_07 

首先,进行特征构建。好比对已下单的用户,根据过往的运营经验和策略进行特征构建:好比他是否点击过网点、是否关注过促销活动、在活动页面浏览了时间多长、所在地区、在什么样的地方打开等。
而后,把符合这些特征完成下单的用户拿出来,最终找到模型权重进行训练和评估。
最后,再把这个模型去套入现有线上数据进行相关预测,方便对用户进行召回或进一步分析流失缘由。
好比,经过算法模型能够快速地找到某些彻底符合这些下单特征的用户,好比他浏览的时间足够长、他关注过活动等,他具有概括出的下单特征但却没有下单,就能够进一步分析流失的缘由。同时还能够分析哪些特征对用户下单决策影响最大。