我做产品经理这一年(1)

要点提示：这是一篇系列文章，回顾我的一年产品经理工作，本篇主要是在闲扯中穿插阐述产品经理在工作中如何使用数据来改进产品。

临近2016年元旦的时候，我们老大把项目组成员叫进会议室，和我们宣布我们的App项目要停止了，团队成员全部转型做第三方平台运营业务，在那一刻我知道我要离开了。临近年底，选择辞职，怎么都不是个太好的事儿。现在我窝在一个图书馆的角落里，黑色的夜已经淹没了窗外一山坡的三角梅，感性的我不由想写很多篇文章总结一下我在过去一年里的成长和错误、经验和教训、进步和思考、对自己过去的一年是交待，也为再找产品经理工作积极做准备。

相比大学毕业就进入互联网行业从事产品经理一职的童鞋来说，我算半路出家，从辞职后开始创业起，算是开始正式从事产品经理这一职，不给力的我自己和创业伙伴没能坚持下来三个月就散伙了，在创业那一阶段对产品能力的提升及其有限，在创业阶段真正激活的是我的独立思考能力，这一点现在想起来还是万分感谢自己的选择，仿佛如从温暖的邮轮上跳入冰冷的海，瞬间被激活。如果没有这一步路，我离独立思考能力还有多远路要走，我也不知。

真正从事产品经理是从2015年3月份来深圳后开始的，在2015年的前两个月我准备了很多知识储备，包括学习Axure的功能，学习标准的流程图画法，学习需求分析方法，阅读关于产品设计的书籍等等。想起坐在西南财经大学寒冷的教室里专心画visio流程图时，不知觉天色已晚的情景，现在都觉得当时自己蛮拼的。

进入新公司以后，发现自己是唯一的产品经理，而周围同事对产品经理是什么都不了解时，我心里想真得靠自己了，而此刻我突然发现所有的产品工作靠自己来主导时，心理确实有点不安。接手的第一个需求就是处理我们公司网站产品详情页面的颜色/数量选择器，是否需要将选择器从下拉列表式改成按钮式。站在现在的角度来看当时的这个问题，我首要要思考的问题应该是：我们网站的用户使用下拉列表选择器不爽吗？使用按钮式选择器会比使用下拉列表选择器体验更好，并且效率更高吗？然后应该去搜集当前下拉菜单被使用的频次数据和观察几个用户使用这个下拉菜单按钮的情境，去搜集下拉菜单和按钮选择器使用效率上的相关用户研究数据（想起来后来我一直纠结于表单标题是应该左对齐还是应该右对齐的问题，直到我发现这个问题早已在用户研究领域的眼动实验证明了的结果：在效率上，标题和输入表单上下结构>左右结构，标题右对齐>标题左对齐）。当时陷入的一个误区是，我这样做的原因是因为其他的网站谁谁谁都这样做了，并且按钮式选择器看起来好看一些，而最本质的问题没有去思考:我这样做是否是还能继续满足用户的使用需求，是否让体验更好一点呢？

根据数据去做产品决策，这一点我在后来的工作中体会的更深。我这一年的产品工作经历可以明显的划分成两个阶段：前2个月负责一个成熟的网站的产品优化工作，后8个月负责一个App（Getone, Google Play & App Store available，欢迎试用）的开发工作。很明显这是两个截然不同的工作经历，从数据的角度来说，针对网站的优化工作是去使用我们已经积累的网站数据去分析存在的问题，我们的网站数据来源有两方面：一是在网站上部署的Google Analytics（以下简称为GA）数据追踪工具统计产生的数据，一是网站的ERP系统统计产生的数据（主要是关于网站订单、营业收入、产品库存动态等方面的数据）；而针对App的统计数据则是需要产品经理先思考好需要哪些指标数据，然后在App里进行埋点获得数据，进而拿着数据进行分析来推动产品的演进。

我们先来谈谈关于一个成熟网站优化问题上如何在产品工作中应用数据。以我接手的这个网站为例(一个跨境电商B2C网站)，GA(web分析工具)基本记录了用户使用行为的全部数据，包含基本行为数据和关键路径转化数据。基本行为数据是部署到网站上的分析工具自动统计的数据，包含会话次数、用户数、平均使用时长、跳出率、流量来源等，各大统计工具基本都大同小异(只接触了GA，但是深深的被GA强大的统计功能震撼)。关键路径转化数据则是由网站的管理人员（一般是产品经理/网站运营和开发工程师一起配合）在统计分析工具提供的管理后台上进行设置，包括完成注册、完成购买等网站核心使用路径和商业目标数据。

对这些数据进行分析使用的主要方法是：对比分析和详细查看关键路径每一步的流量流失情况，结合亲身去使用网站的体验发现问题所在，提出解决方案对网站进行优化后，再次观察改进后的统计数据来验证解决方案是否解决了问题。以上方法也是一个基本的科学研究方法：搜集和分析大量的事实和数据，提出解决问题的假设方案，再通过搜集数据和事实来验证假设方案是否正确。这是一个持续的过程，需要不断进行反复直到问题得到解决。

对关键路径转化数据的逐步分析是一个很有意义的过程，特别是涉及到用户注册和用户支付这两个核心的关键路径，每一步路径转化率一个百分点的提升都会产生直接的收益。一个产品的核心使用路径不需要用户进行思考和判断并且使用顺畅是判定一个产品是否成功的重要标准之一。对产品关键使用路径的优化可以是不改变关键使用路径的步骤只是进行对每一个步骤进行优化，比如用户注册输入注册名称时增加实时校验提示用户输入的用户名是否已经被使用，来代替用户点击“立即注册”按钮时才进行报错，也可以是通过增加或者减少关键使用路径的步骤来进行优化，比如电商网站上用户完成注册并验证后直接登录成功而不需要验证成功后再次进行登录操作。

再来看看在App上数据是怎么驱动产品演进的，同样以我亲自做的Getone App为例。说到这一点，我先花一点笔墨扬一下家丑，每一次想到这一点都是声泪俱下怒捶自己千万遍，因为没有经验，直到这个App被更新了至少10个版本以后，我才意识到只有我们开发团队自主决定嵌入的友盟数据统计工具是远远不足的，一是因为友盟的数据相比我了解到的GA统计数据要简略很多，二是我们的用户均分布在海外地区，使用友盟统计很多数据追踪不到并且追踪到的数据不准确，三是在数据的可视化上友盟相比GA要差很多，四是在设置App内的事件追踪时不如GA设置便捷。

在11月份的时候，我们开始协调开发团队把GA统计工具部署到App里进行App内的使用行为追踪，由于整个团队没有人有在App上部署过GA SDK的经验，再一次我们犯了很大的一个错误：产品经理没有和开发团队确认去追踪哪些用户操作，并且没有去做App关键使用路径的追踪（没经验是小，没意识才可怕）。同时，在开发团队将GA SDK集成到App里时，作为产品经理跟进不利，导致统计结果很不规范。举一个例子讲，加统计代码前没有对App的每一个页面进行命名，导致GA统计数据里出现大量包含com.getone.activity....包名的统计数据，在进行数据分析时很难辨识到底是哪一个页面。说了这么多血泪史和家丑，想说明一点，作为一个产品经理拥有开发一个产品完整的知识体系是非常重要的，这需要我们去广泛涉猎产品管理的书籍、博客，同经验丰富的产品经理进行交流，自己对产品知识勤于思考，长期积累构建起自己的产品知识体系。写到这里，我想起高考时代在复习的最后阶段我们的物理老师和数学老师教给我们的一个方法，坐下来对着教材的目录进行思考和记忆，回想每一个章节里讲授的知识，将知识目录记录到脑海里，在使用到相关知识时通过知识目录去回想那一个知识片区的细节。

回到正文，对一个App进行追踪数据部署时应该注意到哪些方面？同样以我们使用的大GA为例，GA（SDK）分析提供了三方面的数据：基本数据、页面访问数据、事件数据，这三方面的数据对于构建一个App的统计数据模型来说已经绰绰有余。具体来讲，基本数据是指访问用户数、平均使用时长、流量来源、地理位置、设备类型等基础信息；页面访问数据是指App里的每一个页面被访问次数、跳转关系，页面名称最好由产品经理来确定（开发童鞋替你命的名称你是要花时间来理解滴）；事件数据是指在App上用户进行操作的记录数据，例如用户点击了分享按钮，如果你需要统计这个操作，这就是一个事件数据。这三类数据中，基础数据不需要产品经理费心，这是数据统计工具自带的效果，页面访问数据需要产品经理费心对App的每一个页面命好名称，让开发童鞋帮你在代码里添加好，事件数据相对比较费心，需要产品经理思考好要追踪哪些事件的统计数据（一个App里有N多的事件，不需要全部追踪，如果全部追踪可能会导致App的性能下降），并对事件命好名字让开发的童鞋帮你在代码里添加好。看着下面的图例，你可能会问事件类型/事件操作/事件标签都分别是什么意思呢？这个问题请您自行需找答案。

所以这样看来，对一个App进行数据埋点并没有太难的事儿，最大的难处在于对事件数据的埋点。这时细心的你可能注意到了一个问题，难道在App上就不关注关键使用路径的转化数据了吗？对，诚如君语，在App上我们一样需要关注关键使用路径的转化数据，我们只需要在GA的管理后台上进行设置即可，如下图所示，我们选择"目标网址"这种转化路径类型，然后添加每一步关键使用路径对应的页面名称即可（对网站来讲直接使用URL地址即可），当然关键路径有哪些又包含哪些页面又需要产品经理来考虑了。

写到这里，关于App上的追踪数据部署就基本说完了，你就会获得一个反映App使用情况全貌的数据了，关于使用数据来驱动产品演进的方法同前文所讲。

码字这么辛苦，点个赞或者打个赏吧，[调皮][调皮]