保持”温度感”，产品经理修练之数据篇

前言

最近看到几个群里在讨论“产品经理与运营的关系，是否要参与？”等问题，我想借用黎万强的话， “我们做营销策划的同事，全都是产品经理出身，而且一定要是好的产品经理。如果不懂产品，一定做不好营销。所以，到现在我还坚持在一线做产品和设计，就是为了保持‘温度感’。”

其实这个问题很难回答，虽然产品经理在整个产品的生命周期中，不掌握任何实际的权力（除BOSS级产品经理除外），都需要全程参与整个过程，需要对产品的具体工作组织协调与督促检查，让产品按照正确的航线进行下去。就像需要通过 “经纬度”知道船的航行轨迹，产品经理需要掌握“经纬度”，可能我们不是船长，但我们是“舵手”。

数据分析思路

数据核心“场景”和“用户”

传统互联网对产品的数据分析，核心围绕着“用户”，例如从用户质量分为：狂热用户、核心用户、一般用户及边缘用户；从运营角度分为：活跃用户、留存用户、流失用户、回归用户等，移动互联网也不例外。

然而，移动互联网由于“碎片化”等原因，虽然你已经明确是哪一个用户，如果没有场景支撑，用户也不会来的。例如：我如果最近不看电影，我不会去美团；我在公交车站等30分钟，公交车还没有来，我可能会打开“公交大师”查询公交情况。

所以根据我个人的看法，“用户”的指标体系发展多年应该是相当完备了，但“场景”的指标体系还不太完善，至少我还在学习及摸索中，我的初步解决思路就是尽量在产品中体现“场景元素”，这样便于统计。例如：我会让用户做选择商品内容的时候，能接近场景选择核心内容。

运营三步走：获取游客、激活成员、保留用户

在“前言”中谈到“产品与运营的关系”，如果单从产品角度去分析，个人认为价值不大（运营与产品紧密相关），所以我通常会按照运营三步走“获取游客、激活成员、保留用户”进行数据建模，也便于与运营同事进行沟通。

获取游客

先我先声明一下，我通常把“新用户”称为“游客”，我认为这个称呼更为贴切，运营同事根据前期产品经理整理的用户画像及场景，通过各种手段（活动、软文）在各渠道去获取游客来使用产品。

从数据统计角度，首先最基础的是增长事件是什么、增长的渠道（电子市场、官网等），然后这个时候的“游客”，他们对你这个产品什么都不知道，或者他们抱着很高的希望，所以这个时候要遵循“三秒原则”，快速让用户在3秒内了解产品是什么、能做什么，并且快速上手。

对于“游客”来说，会受内容质量及交互友好方便的影响，我们先要通过排除法把交互流程、信息结构影响用户排除，例如：我会统计新用户访问路径数，与我在产品设计过程中规划的路径是否吻合。

我个人观点，产品经理会放入大部分精力在该阶段，主要是解决交互流程及信息结构对使用者的影响，以下我就举一个我前期在网上收集的例子，让大家更好的理解。

以下这个产品中东的数字音乐流app，设计者的用意很好，通过引导及定制让用户找到真正感兴趣的音乐，从而提高用户使用率和活跃度。设计者需要验证“多少人完整走完了三个步骤的引导页”？数据显示，当用户通过第一页，从第二个引导页到第三个引导页的流失率达到15%，后经过分析原因是在中东，用户听歌认脸多于认音乐的类型！。

另外，第一个引导页，也就是Personalize Anghami，并没有什么用。用作者的比喻就是，你要让用户进门去看里面的房间，还非要把门锁上再给他一把钥匙（Personalize那个按钮），说你用钥匙一开门就可以进去看啦！为什么不直接把门打开呢！

Anghami引导页（改版前）

Anghami引导页（改版后）

激活成员

获取游客就好像“相亲”，在见面之前相互之间不了解对方，通过短时间熟悉后，对双方有一定的好感，这个时候双方之间就会进行“约会”，这个时候需要通过产品让用户从“游客”变为“成员”。

这个阶段采用的手法我称为“激活”，就是让游客做些你事先已经决定，他们应该做的，进一步达到你的目标。这可能是让用户加入一个电子邮件列表、点击广告，或者创建一个帐户，甚至是购买。现在你必须激活游客变为成员，你甚至可以有多个激活，让你更能方便的跟踪，可以通过“埋点”等手段实现。

保留用户

当通过“激活成员”的热恋期后，是解决让“成员”变为真正的“用户”（我称为结婚），说实话把一个“游客”变成“成员”就很难了，把“成员”变成“用户”就更难了。

这个阶段的使用者对产品已经有一个整体的了解，所以交互流程及信息结构可能对用户影响不是特别大，根据我的经验大部分是核心内容能否吸引用户。就像《iOS Human Interface Guidelines》设计基础提到的“以内容为核心，UI能够更好地帮助用户理解内容并与之互动，但却不能分散用户对内容本身的注意力”。所以这就需要运营人员提高产品内容的质量，从而吸引用户。

从数据角度来看，通常有流失用户、留存用户、回归用户数、活跃用户等指标进行分析，但我认为指标都是比较粗的，因为用户许多可能的原因导致用户不想使用该产品，所以这部分我认为应该与具体业务挂钩，在这里我也是一个“学生”也在摸索，不能给大家比较有用的建议。

梳理数据点

产品梳理数据点为后续埋点做准备，最理想状态是在产品的每个功能分分支哪里进行“埋点”，但这个工作量太大，我个人也认没有必要。现在虽然第三方统计也提供“自定义事件布点”，但我认为缺乏灵活性，无法层层追查及分析。