产品经理数据埋点文档指南(入门)

2022年 12月 24日11:30:08 发表评论

最近给团队里新来的小伙伴做了一次数据据埋点的分享。当时基本脱稿口述,讲完后发现还是有不少缺失,然后再回想来公司一年多,其实各团队的埋点的实际情况依旧糟糕,所以决定把去过一年多笔者写埋点文档的心得梳理和记录一下。

在进入正题前,笔者先自问自答几个埋点相关的几个问题,让本文的内容跟大家的认识结合起来。

1.1. 为什么要埋点?

通过有效的埋点,可以收集和观察到用户在产品中的第一手数据资料。最真实的反映了产品的运行情况,是量化工作收益、计算KPI、ROI,通过数据在迭代时说服别人的重要依据,等等。

基本上笔者的产品会定下,不埋点,不上线、不发版的规则,否则事后无法说清收益,没有交待。

1.2. 为什么要产品经理写埋点文档?

如果有专门的数据产品经理或者业务线数据分析师,可能不需要由直接负责的产品经理来写埋点文档。

但大部分情况下,公司可能没有专人负责,笔者建议由产品经理最好亲自来编写埋点文档,而不是运营同学、研发同学。理由如下:

1.3. 什么是点?

这个概念对于初次接触的人理解会比较困难,笔者会有几种说法来进行多个维度的描述:

以上每一种说法都可以,结合着看看,你就可以理解。

1.4. 如何埋点?

埋点的技术有很多种,如:代码埋点、可视化埋点、无埋点等,埋点的位置可以有客户端埋点、服务器埋点。

本文中的埋点文档会采用代码埋点,客户端埋点。即程序员根据我们的埋点文档,对用户在网站或app中的目标行为进行数据上报。

因为服务器并不会直接捕捉到用户在端上的行为。且服务器上一般已经有一由研发开发时所留下的日志系统,再额外的加埋点处理,可能会降低服务器性能。

个人觉得一个点的描述,基本上可以和我们常用的5W2H模型进行匹配,我们从左往右看。

红色部分是我们对一个点描述的思考,根据情况和实际需求,可以适当增加和减少描述的纬度。比如我们不需要知道是具体哪个用户发出的事件,则可以不要who这个维度后面的数据,或者用户都是在产品内部闭环,不需要知道用户来源,则why也可以不用。

这里需要注意几点:

再来看白色部分则是我们的点,或者叫事件模型。虽然是中文,但还是描述清楚了我们需要记录一个什么样类型的事件。即:需要对从抖音广告中跳转到京东商城里商品的用户进行数据统计。目的可以是看抖音这条渠道的带新用户能力,也可以是这个商品爆光后的转能力,等等。

最后到绿色部分则是事件了:2020年4月11号 23点11分00秒,一名北京手机尾号1386的iPhone 6S Plus用户,在刷抖音时通过广告3412链接,访问了京东商城的自热米饭商品。而这样的数据,每分钟程序都会根据我们在白色部分的描述在程序中产生几千条。

理解了这个模型,则要正式开始写我们的埋点文档了。

3.1. 产品原型

笔者这里绘制了一个简单的产品原型,具体逻辑就不细说了,一目了然。

3.2. 埋点文档

根据前面的点描述和产品原型,笔者简单写了一份如下图所求的埋点需求文档。这里会有10个点的描述,即每一行就相当于之前的一个思维导图。

红色区域:只是为了映射前面的思维导图,帮助大家理解和思考的,平时写文档时不用写;
黄色区域:则是事件描述,简单描述埋此点的意义和方法(本表中写得略简单),如果有比较复杂的情况,需要和研发同学进行沟通确认;
绿色区域:为事件模型、点描述,其中每一列,都称之为一个属性,或者叫纬度;
蓝色区域:为传值描述,即相应的属性里会放入哪些值;

通过上面这份文档,研发同学已经可以进行埋点操作。

但不难发现,这个文档却有几个明显的问题:

为了解决以上问题,让我们的埋点文档优雅起来,还需要进行以下几个优化步骤。

4.1. 抽离公共属性

不难观察到,其实TimeAppNameUid 这三个属性每一点都需要进行使用,且传值的规则一致,笔者会将此类属性定义为点的公共属性。

在这种情况下,笔者一般会将一篇文章中的公共属性在正式对各点进行描述前进行总结。这样研发同学也可以根据此对所有的埋点方法(研发意义上的)进行抽象,在每次用户所产生的事件上报时,都会调用这块儿的属性值。

之后文档改起来也会非常方便。如下图所示:

备注:好的埋点工具,会自带默认采集的属性,比如:设备型号,系统型号,地理位置等。

4.2. 根据页面拆分

根据笔者的经验,每个不同的页面,单独做一个表的可读性会更强,在删除之前的公共属性后,整体的事件埋点如下所示:

在表的旁边再配上各页面的截图,将会使整个文档更清晰。即使是新来的同学也会知道各页面上有哪些操作。

4.3. 折叠私有属性

最后我们以小说 主页这个页面来进行一个私有属性的折叠。私有属性则是相对于前面的公共属性来说的,在前面的图中我们会发现两个问题,不是每个事件都需要使用Title,Fav,Like这几个属性,且在不同的点中,FavLike的含义也会有区别(一个表状态,一个表行为,当然差异还可以更大)。

所以就会将私有属性根据点的维度进行单独补充描述,如下图示。这样不仅可以对一些重要的事件进行比较详细的描述,且和别的事件在使用同名属性的时候还不会互相冲突,提高了属性的复用率。

关于如何对产品进行埋点的入门篇,到这里就差不多能够应付绝大多数简单的场景了。这份简单的文档笔者还遗留了很多的优化空间,将会在下一篇进阶技巧中进行补充。相信运用得当,将会秒杀90%以上的产品经理,对于数据埋点方面的理解。

本网页由互联网用户所发,如若侵权请及时联系1936370309@qq.com删除。

原文链接:https://www.cnblogs.com/ministep/p/14924144.html

  • 版权声明:内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请发送邮件至 1936370309@qq.com 举报,一经查实,本站将立刻删除。
  • 转载请注明:产品经理数据埋点文档指南(入门) 紫林博客

发表评论

您必须才能发表评论!