产品经理给开发提埋点需求的正确姿势

2017-11-07 09:39:00

本文作者将以某社交 APP 为例，阐述产品经理给开发提埋点需求的正确姿势。enjoy~

作为一枚产品经理，对埋点一定不陌生，每一款产品多少都会有数据统计的需求，互联网发展到今天，互联网公司对数据的需求也不仅仅限于 PV、UV，对产品经理也提出了更高的要求。做一枚既懂产品又懂数据的产品经理，好难。

因为工作的性质，这一两年来，接触的产品经理和运营大概有1百来个，和他们聊数据分析需求时，总是找不到一个很好的节奏，感觉好像就是那些常规的分析指标，让具体说一下就说不出来了，最终导致的只能是这三种结果：

最开始进行需求梳理时，没有从整体进行考虑，给出的需求偏浅层或者给不出具体需求，等到开发埋好指标结果出来时却不是自己想要的，需要重新埋点。另外，后续产品版本更新迭代了，原有埋点不可用，也需要重新埋点。
数据统计口径没确定清楚，且没有保持和开发的一个良好沟通，没有将埋点的具体采集时机正确传达给开发，导致最终埋点实现的不是自己想要定义的指标。
数据采集方案没有想清楚，哪些应该在前端埋点，哪些应该在后端埋点，埋点采集SDK如何正确使用在还没了解清楚时就急于上手。

那么，对一款产品进行数据分析的最佳过程是什么样呢？详见下图：

梳理数据分析业务需求和埋点采集是数据分析的第一步，埋点需求梳理和埋点采集的好坏直接决定了后续的实施成本和效果呈现。所以，今天我们就来聊一聊，产品经理给开发提埋点需求的正确姿势。

一、梳理产品逻辑

以下以某社交类 APP 为例来进行说明，一个话题交友兴趣聊天的平台。

1. 产品信息结构图

通过产品信息图，我们能了解到产品承载了哪些信息和功能，我们可以借此思考下，这些信息和功能的目的是什么，想要用户干什么？

2. 产品功能结构图

通过产品功能结构图，我们能够将产品的功能模块梳理出来，功能之间怎样跳转，功能的上游入口和下游出口是什么都要想清楚，并标记出来。

3. 核心业务流程图

一个产品总会有那么几条核心业务流程，比如注册流程，新手完成任务流程等等，我们需要清楚梳理出我们产品的核心业务流程，密切观察用户在核心业务流程运转的整个过程。下面以发布话题的流程为例。

二、梳理产品需求

进行需求梳理首先要明确我们要分析什么样的场景，解决什么业务问题，要解决这个业务问题，要看什么样的数据，要衡量什么样的指标。不同的角色会关心不同的问题，一般会按照业务线进行需求梳理。当然，这些指标是和我们目前产品要解决的核心业务目标密切相关的。所以我们首先要弄清楚产品的目标以及对目前产品阶段来说最重要的问题。比如，我们要增加销售额，销售额等于活动流量乘以付费转化率乘以客单价，然后我们就需要把这个指标需求进行再一步细化，分给不同的角色各有侧重点的去执行。

这个指标需求和梳理产品逻辑有什么关系？为什么第一步要梳理产品逻辑？你可能会发现，这些需求点和产品的信息架构和功能架构密切相关，举个例子，拿我们常说的活跃用户数这个指标，一般是以启动App的用户数来定义活跃的，实际上，每一款产品的核心功能不同，只有完成核心功能的用户数才算活跃，通过以上产品功能架构的分解，我们就知道了我们优先衡量哪个功能的使用情况。再有功能转化率的衡量，功能转化的过程你有没有想清楚，完整梳理出该功能使用的完整业务流程后，我们要怎么衡量转化也就有了眉目，也更能定义出问题所在。总之，我们经过一番梳理，对产品的信息架构、功能点、核心业务流程有了一个清晰的了解。有经验的产品经理可能也发现了，这些产品逻辑其实已经在产品需求文档PRD里面已经有了，只是没想到它还可以用于需求梳理，而且有助于数据模型的设计和避免埋点的反复。

下面我们来看下，有了这些准备工作，我们如何进一步设计数据埋点方案。

三、进行事件设计和数据采集埋点方案设计

说起埋点，很多产品经理习惯用页面或点击来定义埋点，比如手机号码填写页面、播放视频页面、成功发布话题页面或者点击分享按钮的次数等等，我们常说的功能，即用户在使用这些功能时产生的使用行为数据，从用户使用行为分析的角度去分析自然顺理成章。这里举个例子，上面提到的发布话题的业务流程，其实是由用户一系列行为组成的：

这里给出了用户行为和事件的对应关系，用用户的真实操作行为去定义事件名称就可以了。除了要埋点的行为功能以外，每一个功能我们都需要从不同属性维度去衡量。比如我想看不同话题分类被成功发布的次数这个指标，就可以将话题分类做为发布话题这个事件的属性，这个话题分类的值可能有图片、文字、音频、视频，这样我们就能分别看到发布图文的话题个数、发布音频或视频的话题个数了。通过维度的层层细分，我们一定能定位到业务问题，就怕缺少某个关键维度的信息。

最后，我们会形成一张事件设计埋点表：