当前位置:首页 > 运营 > 正文

系统埋点怎么做的(如何从0到1构建埋点体系)

系统埋点怎么做的(如何从0到1构建埋点体系)  第1张

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

一、开荒

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

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

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

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

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

3.以项目视角看产品

之所以谈到项目化,因为埋点体系搭建既是一个产品规划问题,也是一个项目管理问题。建议在开荒阶段,就要把这个项目的过程筹备好。接下来根据自己过往所经历的项目筹建经历,跟大家分享一些实操经验。

系统埋点怎么做的(如何从0到1构建埋点体系)  第2张

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

3.问题排查技巧

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

4.多项目处理方法

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

系统埋点怎么做的(如何从0到1构建埋点体系)  第3张

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

3.小工具使用技巧

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

四、数据埋点实操案例

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

1.什么是 GBDT?

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

2.具体实践流程系统埋点怎么做的(如何从0到1构建埋点体系)  第4张

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

取消
扫码支持 支付码