当前位置:主页 > 产品中心 >

产品经理该如何做好数据埋点?

18-10-06 作者:admin 来源:未知 点击:59

本文根据笔者的心得体会,跟大家分享,产品经理工作中做数据埋点的一些经验和看法。

作为一名产品经理,你必然知道数据分析对于产品的生命周期的重要性。

解决用户需求,解决痛点是产品的立足之根本;运营是传递产品价值的重要手段;而数据,则给产品和运营提供了指向的重要意义。

数据,既是产品分析的基础,同样,数据的采集和来源也是每个产品经理头疼的地方。

好的数据收集和分析,可以辅助产品经理更好的了解用户,让团队少做一些无用需求,或者在错误的需求方向上停止脚步,遏制一些异想天开的想法。

一、需求收集和分析

1.1 梳理产品,清晰产品的脉络和架构

梳理产品的产品结构

首先,先别急着马上就去建立埋点,此处应该是优先复盘当前的产品或者模块,整理出产品结构和页面结构。梳理出产品完整的结构、页面逻辑,这些都是决定了用户在使用产品时的任务路径,所以需要做一次完整的复盘。

梳理产品页面流程

有了基础的梳理后,我们需要再将业务或页面流程梳理出来。将用户与系统的交互故事完整的梳理出来。借助它,你更容易知道流程中的潜在地雷是什么,哪里的效率比较低,有助于系统化、全局化、周全性的思考。我们后续可以在每个流程步骤,考虑好用户的目的、场景,提炼出重要指标。

1.2 收集统计,明确统计目的和意义

如果是产品经理做埋点收集,也可以从以下的几点思路出发:

功能流程转化率:关键业务的留存转化指标尤为重要,用户在哪个关键节点发生了流失,

改版调整:如果产品做了改版,肯定会在一些关键入口进行了布局上的优化,那么埋点统计有利于收集变化前后的不同。产品是否更加聚焦的解决了用户的痛点,还是

用户轨迹:用户来到了你的产品,第一件事情是做什么,然后还会做什么。如果你的产品,满足了用户的需求,那么主要路径我们是可以猜测得到的。但唯独那么一小块路径,是否会挖掘出更深层次的需求。

面向运营方面的,一次完整的活动运营,在工作的前中后阶段,对数据的需求都不太一样:

活动前,需要了解面向的用户、兴趣、标签、来源,入口的引导和布局,有了这些,才可以更好地评估面向对象、渠道。而这些,在产品早期建立数据的时候,需要第一时间就考虑的问题。

活动中:对数据的时效性要求更高,落地页或者活动页面的PV/UV、活动参与数、页面登陆数、中奖数、兑奖数、活动转化人数/金额以及用户信息等。必要的时候根据数据反馈及时调整问题和优化。

活动后:更加注重反馈和总结,对活动的复盘;本次活动的带来了多少的访问流量,转化率如何,不同渠道过来的用户表现如何,最终这些用户转化成活跃用户的又有多少?

其他:

Boss:“小李啊,这个活动上了,但是效果不怎么样,你觉得哪里可以再优化优化?”

小李:“伟大的老板,是这样的,关于这次活动的,我整理了一份报表,通过分析这些数据后,有一个方案,请看看….”

不管来自哪个方面的需求,收集数据必然是来源于分析目的,基于目的,才会有分析指标,才会有数据的收集。

1.3 根据产品流程设计指标

在前面做了一系列的功课之后,我们就开始要根据产品的功能流程或者页面结构,定义好分析的目的,剥离关键流程,提炼关键指标。

购物环节:宝贝详情页>加入购物车>订单确定>订单提交>支付>支付结果

在这个过程中,你可能需要采集到从详情页到购物车的转化,从详情页到订单确认的转化,订单从确认到支付成功之间的漏斗模型。

那么对应的可以为详情页UV、购物车添加事件、订单确认事件、订单提交事件、支付事件、支付成功反馈事件。

注册流程:进入注册>注册信息填写>获取验证>注册成功

对应的可能想要了解到注册流程的转化,那么可以主要采集注册按钮点击事件、提交信息事件、获取验证事件、注册成功事件,再加上能够统计到渠道包信息,那么也就可以分析出,不同渠道下的用户转化效果。

二、提出需求

可能前面的内容,大部分的干货可能会讲的比这个更清楚了,那么笔者在这里更多的是想要跟大家分享一下,如何提出埋点的需求。

有些公司可能会有自己独立的数据系统,用于收集用户数据。但是大部分公司而言,更多的是专注业务本身,所以埋点也是用了第三方。

目前有很多做埋点和数据支持的公司,例如友盟、诸葛IO、GrowingIO、神策等等,也有埋入移动端、H5、Web等,在进行选择的时候,不妨多进行对比,没有哪家最好,只有哪家最合适。

在这里,笔者用的是友盟统计。

2.1 收集事件

首先先理解什么是“事件”,可以理解为触发一个动作、行为或者到达某个条件,都是一个事件(Event)。

例如:在登录中,填写完信息后,点击一下“登录”按钮,或者点视频的“播放”按钮,页面流程的“下一步”按钮,获取到“登录成功”,访问某个页面,这些触发的行为都可以理解为一个事件。

因此,沿着流程和产品结构,会得到这么一个表格:

(可能会存在iOS跟Android的event ID不同,所以这里分开记录)

2.2 设置事件的参数和参数值

除了统计事件的触发次数外,还可以收集触发这个动作时,其他的附带信息。利用这类信息,有助于对事件有更加精准的统计,又称为参数(Key)和参数值(Value)。

事件、参数、参数值的关系如下:

举个简单的例子,电影播放平台上,当用户点击“播放”电影时,这里可以为一个事件。出了统计这个事件发生的次数之外,我们还可以收集到这一次播放的电影类型、地区;

其中,参数就是类型、地区。类型下对应的参数值就有:喜剧、爱情片、科幻片等等;地区下对应的参数值就有:欧美、日本、韩国、大陆等。

这样,就可以统计到,点击播放按钮到次数中,点击频次最高的是什么类型的电影、出自哪个国家的。

(事件-参数-参数值)

当然,还有另外一种情况,那就是所统计参数的参数值,是一串连续的数值,我们无法使用参数值=1,2,3,4这样去统计。

例如说付款页面,点击“确定付款”时,参数为“付款金额”,因为这个时候,我们可能会想到参数值可以=1、2、3、4等一直排列下去。但是实际操作上,参数的值会有很多,可能从1元到1万元都会有。

这个时候,采用的是计算统计,只需定义好统计值的类型(整数型int还是float)和范围,例如统计金额的,那么就是统计付款金额,类型为float,范围0-10000.00。

根据以上的步骤,可以定期维护这么一份表格:

3.3 维护表格,定期沟通

在整理完以上的表格之后,别忘了和其他产品、运营、开发对一下这份文档,看看是否有其他遗漏,同时,再进对应的事件参数等,对应到产品结构和流程中,看是否跑得通。

以后在维护需求文档的时候,当产品发生变化的时候,可以增删改这份表格的内容,这样一来,开发人员就会知道了。

但是记得最重要的一点,还是得跟开发沟通,正确地描述我们埋点的意义和背景。有时候开发人员也会补充和完善你的埋点需求。

四、测试和校验

接下来就是测试和校验的环节,如果是接入第三方的,可以根据帮助文档,将新加入的埋点,进行一轮测试。

因为有时候可能开发大哥对需求的理解有所偏差,或者沟通不到位,导致埋错了位置或者定义错了。

而在最终验收的环节中,需要做一个校验,避免辛辛苦苦埋下的点,等到上线后,产生了一堆无效的数据,甚至会影响后续对产品的判断。

五、写在最后

其实埋点也只是整个产品规划中,关于数据分析的一小块。

除了埋点分析外,还需要和后台的日志数据做整合分析,善于发现每个异常,善于调研趋势背后的原因。产品经理跟运营工作相互配合,才能够是产品走得更快更远。

以上就是做埋点需求时,总结出的一些心得,如果对您有帮助,那是最好不过,如果您有其他的意见或者看法,也欢迎随时沟通。

作者:猫小白

来源:人人都是产品经理